Is there the way for upgrade-safe customization of files in the root folder of Suite CRM? I know how to customize files in "include" folder, for example (place them in the "custom/include"), but i cannot understand how i can change the file (i need to edit /download.php) in the root directory of the project in upgrade save manner.
I've came to the conclusion its not possible to integrate S3 buckets in a non upgrade safe manner, the following files need integrated with your S3 code.
include/upload_file.php
modules/Documents/Document.php
modules/Emails/Email.php
modules/InboundEmail/InboundEmail.php
modules/Notes/Note.php
Related
We have an internal discussion going here and we are somewhat torn on the best practice for using .gitignore on projects that contain a lot of files (like a CMS).
Method 1
Method 1 would be to purposefully .gitignore all files that come standard with your build. That would generally start like:
# ignore everything in the root except the "wp-content" directory.
!wp-content/
# ignore everything in the "wp-content" directory, except:
# "mu-plugins", "plugins", "themes" directory
wp-content/*
!wp-content/mu-plugins/
!wp-content/plugins/
!wp-content/themes/
# ignore these plugins
wp-content/plugins/hello.php
# ignore specific themes
wp-content/themes/twenty*/
# ignore node dependency directories
node_modules/
# ignore log files and databases
*.log
*.sql
*.sqlite
Some staff members like this approach since if you create something outside of the standard files, for example like a /build folder, then it would automatically be detected for inclusion. However, writing custom theming and plugins require you to add a few layers to this file to "step in" to the folders you want to keep, and generally, the file is a bit messier to read.
Method 2
Method 2 ignores everything, and then you whitelist what you want in the repo. That would look like
# Ignore everything, but all to descend into subdirectories
*
!*/
# root files
!/.gitignore
!/.htaccess.live
!/favicon.ico
!/robots.txt
# theme
!/wp-content/themes/mytheme/**
/wp-content/themes/mytheme/style.css # Ignore Compiled CSS
/wp-content/themes/mytheme/js # Ignore Compiled JS
# plugins
!/wp-content/plugins/my-plugin/**
# deployment resources
!/build/**
Some staff like this since it's cleaner, you have to purposefully add something (which makes accidental adds harder), and it also in effect shows you your .git folder structure.
What is the best practice? Which method do you enjoy and would you recommend doing one over the other?
The second method is the best practice, when it comes to exlude some folder contents of gitignore rules.
It better reflect the following rule:
It is not possible to re-include a file if a parent directory of that file is excluded.
To exclude files (or all files) from a subfolder of an ignored folder f, you would do:
f/**
!f/**/
!f/a/sub/folder/someFile.txt
Meaning: you need to whitelist folders first, before being able to exclude from gitignore files.
It is clearer, shorter (unless you have a large number of folder to whitelist)
What if it is a Joomla install with a large amount of directories and files?
Or what if a core upgrade adds new files or folders
Don't forget you can have multiple gitignore files, one per folder.
That means you can mix and match both approaches.
And you have:
http://gitignore.io/ (which does blacklist when it comes to Joomla application)
github/gitignore (same approach for Joomla)
The ideal .gitignore file, is the one that does not exist.
For some reason, you're deeply intermingling files you want to track via source control, with files you DON'T want to track.
This, I think, is the source of your sadness.
You are mixing git's intended purpose, which is versioning of programmer-edited files, with deployment, which is intended to get the files where they belong in the correct directories.
Your question is not clear, as to whether you think the Wordpress core files should be versioned. I'm assuming not, since that's how you've set up your .gitignore.
Your question is also not clear, as to whether you are deploying a web site, or shipping plugins as a product. Those are both different use cases, and they require different types of versioning. If this is a deployed web site, you SHOULD be versioning Wordpress along with everything else. If you are shipping a plugin or a theme, then you should have a test suite of plenty of different Wordpress versions to test against.
I think your source control system should be set up, solely to track just the plugins/* and/or themes/* files that go into your distribution. Zipping that folder should give you the plugin asset that your customers download.
To debug your plugins, there should be a deploy step in your IDE that copies each of those tracked files, into a Wordpress install at a location you choose. This permits you to more easily test against different Wordpress versions.
You're reducing workflow problems, to trying to choose a .gitignore. Fix the problem at the root by getting the workflow right.
I am building an app for windows store and I need some default and example data to be in the localstate folder (Windows.Storage.ApplicationData.current.localFolder) when the app run the first time.
The folder and files structure is a bit complex and I tryed to copy the files at the start of the application, but I can't manage that way.
Is it possible to have files being copied automatically from the installation folder to the localstate folder during the store app installation?
Unfortunately, customization of the app install process isn't currently supported. You have to do this as part of your first run processing.
One possibility is that you include the data in your package as a .ZIP or other compressed file and use an appropriate library to expand that file into a folder structure on startup. That could simplify your logic considerably. (I don't have a library to recommend; it's just an idea.)
I have setup the basic LAMP server on Ubuntu 11.10 and had a few questions about directory structure with web hosting. My "requirements" are that I would like to host two websites (ie: www.site1.com and www.site2.com) and also that I would like to use the Zend framework.
Currently, the public folder is /var/www/. Is it common to have a "Projects" folder somewhere containing all of the web application code which generally will consist of the Zend project folders (public, tests, library, etc)?
Where do you "normally" store the Zend framework folder? I was thinking of just storing in in my ~/ directory and creating a symlink from each project's library folder to the Zend library folder. Is this recommended/frowned upon?
I'm new to this and just getting setup, but here is what I had in mind so far:
Create a projects folder in your home directory (~/). Under there, have your different web apps (~/Projects/site1 and ~/Projects/site2). Create a symlink from /var/www/site1 that points to ~/Projects/site1/Public and the same for site2. Setup the virtual hosts file with DocumentRoot set to /var/www/site1 and the same for site2.
Can anyone shed any light on the possible pitfalls of this? Would this be alright to do? Any recommendations? I know there are many versions of how you should setup directories here on SO, but couldn't find any answers that addressed these things specifically, so I apologize if this is a repeat.
Any help is appreciated.
Yes, there are lots of ways to do it, just keep in mind a few things:
The user that owns the HTML/PHP files should not be the same as the user that runs the web server process.
The ZF project files should be outside the web server's document root.
If you make a setup now that's conducive to having multiple developers, you won't have to make big changes later.
I usually do something like make a "site" user with a regular /home/site directory. This keeps the site files separate from your personal files and makes it easier to support multiple admins/devs that might need to login. You can also put this in /opt/site or /usr/local/site or wherever. I like /home because the shell skeleton files are already there and I can easily add SSH keys of the people I want to have access. I'll have something like:
/home/site/
library/
fuel/
geshi/
sencha-touch-2.0.0-gpl/
ZendFramework/
ZendFramework-1.11.10/
ZendFramework-1.11.11/
latest -> ZendFramework-1.11.11
site/
domain1.com/
application/
library/
MyApp/
Zend -> /home/site/library/ZendFramework/latest/library/Zend
public/
scripts/
domain2.com/
application/
library/
MyApp/
Zend -> /home/site/library/ZendFramework/latest/library/Zend
public/
scripts/
Then, your vhost document root settings would point to /home/site/site/domain1.com/public and /home/site/site/domain2.com/public
Directory structures aren't something that there is a right or wrong way to do, lots of people do it in different ways, here is mine with Ubuntu and some CakePHP apps
/srv
/site1/
/app
/webroot
/cache
/tmp
/site2/
/app
/webroot
/cache
/tmp
/share/
/CakePHP
/1.3/
/2.0/
The two main parts of the configuration are done in apache, I set the Document Root of the vhost to the exact location of the webroot to /srv/site1/webroot/, then I put CakePHP in the include path (you could do the same with Zend) by using the php_value include_path ".:/share/cakephp/2.0/lib" in the vhost config.
I do this because it allows me to upgrade CakePHP with maintenance releases easily to all sites, (ie ones that shouldn't break anything) and a new release will warrant a new folder (ie 2.1), and upgrading a site to use it is simply a case of editing the apache config (or .htaccess) and restarting the server.
This also keeps me from having to include any sort of include path in my app (and therefore version control) so it's as portable as possible across different dev/staging setups.
Of course as I said, there isn't one "right" way.
I am trying to automate deployments of a particular project and a bit lost as to who to handle config file as well as user assets.
(Application is based on Zend Framework based btw).
Main application folder is structured as follows:
./app
./config.ini <----- config file
./modules
./controllers
./models
./views
./libs
./public
That config file is where all the configs are stored.
So 'app' folder contains whole bunch of code in PHP and 'public' contains whole bunch of code in JavaScript, HTML/CSS and stuff like that(web accessible basically).
If I follow Capistrano's model, where each package is expanded into it's own folder that is then symlinked to, how do I handle that config.ini file?
What about all the user content that is uploaded into ./public folder?
Thanks!
The Capistrano approach to this is to have a structure like this on your remote server:
releases/
20100901172311/
20101001101232/
[...]
current/ (symlink to current release)
shared/
in the shared directory you include your config file and any user generated content (e.g. shared/files). Then on each deployment, once you've checked out the code you automatically create symlinks from the checkout into your relevant shared directories. E.g.:
releases/20101001101232/public/files -> shared/files
releases/20101001101232/application/configs/config.ini -> shared/config.ini
that way, when a user uploads a file to public/files it is actually being stored in shared/files.
I have created a web part using VSeWSS 1.3. It creates a wsp file and my web part gets installed, everything works great.
I would like to also create a folder in the LAYOUTS directory of the 12 hive and place a couple files in there. How do I go about doing this? I know that I can manually place the files there, but I would prefer to have it all done in one fell swoop when I uses stsadm to install my solution.
Is there a best practices guide out there for using VSeWSS 1.3 to do this? They changed a bunch of stuff with this new version and I want to make sure I don't mess anything up.
You can create a new folder structure in your webpart project, like:
Templates/Layouts/CustomFolder and put your files in the CustomFolder directory and include them in your project.
When you go to the WSP View in Visual Studio, you can see in the manifest.xml that your files are being included in the deployment.
I have done this successfully on multiple projects now.
In case anyone is wondering, the VSeWSS 1.3 user guide is incredibly helpful. It is installed to the same directory as the tool itself, default in C:\Program Files\Microsoft SharePoint Developer Tools 9.0\VSeWSS13.CHM
You can see a working example with screenshots Here
A simple step-by-step tutorial for the above, along with deploy/retract scripts is here at Add New Files To 12-Hive Through A SharePoint Solution. Just follow the steps and in a few minutes you'll be able to add whatever you want to the 12-Hive!