I have created a custom, specialized CMS with a number of clients on it, each with their own domain name, website, admin area and database, but all residing on the same server.
Whenever I get a new client, I simply copy all of the code over, change 3 lines in a config file, and then all of their styles/data is taken out of the database or from uploads they post to the server from their own admin area.
Sounds great so far right?
Well when I recently decided to update all of the clients sites, this became a major pain. Obviously i had to change the code on each install. For a major update this is fine, but for frequent tweaks or the like, duplicating the effort of uploading becomes very annoying....I hope to someday have dozens or hundreds of clients, so the code will eventually have to be centralized so that changing it in one place updates it everywhere...how does one do that?
Firstly, you need to be careful of the pitfalls of sharing code between sites. Updating many sites at once multiplies the danger of your updates causing a problem -- if the shared code has a bug, it's better to find out on one site than on a hundred at once!
A deployment management solution may be better than directly sharing the code. (if you're using Drupal, for example, you could use Aegir to manage all your site deployments and updates)
That said, it can be helpful to share code in some cases. I did something like this at a previous job, where they wanted several sites using a single shared code base. What we did was to put the shared libraries into a folder on the server, and each site was then given a symbolic link to that folder, so it treated it as a local folder. Quite easy to do, and quite easy to manage.
An alternative approach is using stubs. Simply move the shared code, like a library into a shared directory. Then for each individual site, create hollow .php scripts which just include the shared code:
You'll had to repeat that for each application entry point. So you have almost empty scripts in each site, and all changes in the shared codebase automatically apply to all setups. Just let the config.php differ between installations.
For static files (images, css, etc.) I'd also use a symlink approach or a RewriteRule.
A easy solution would be to put the source code in a subdirectory, except the files, which should be altered for each client (for example, the config file).
You can then put this source code directory somewhere out and just create symlinks to it.
For example, your directory structure might look like:
If you choose this structure, the only thing you would need to change, would be the include for settings.php (e.g. from
require "settings.php"
torequire "../settings.php"
).When I do something like this, I have each client's folder on the web server be an SVN working copy (I use SVN as my version control system, obviously). Then when I've made some updates, tested, and tagged the release, I just switch the client folder to the new release. SVN automatically pulls down all the changes for me. There is one caveat: make sure you set up your web server to not allow serving of the contents of the .svn folders in each directory (or the equivalent for your VCS of choice, if there is one). I believe I first read of this technique in the official SVN docs, so I think it's sanctioned by their developers, but I am unable to find a reference to it in the docs right now.
If you place your code into version control, then each client website can be a separate checkout. You can check in your changes, and roll them into each client (or test site) by doing a version control update (or using export) at the root. Then you can update and test each client one at a time to make sure the patch applied properly.
Just to let you know I've had this problem before. It's easy to get caught by some phantom .htaccess irregularities or open exploits up to other clients if you decide to configure through this.
I recommend keeping everything separate between clients.
Therefore, give them their own FTP, database and codebase. Don't pile it all into one folder and think configuration is going to help. It seems sexy to do it that way, but when you have one little problem then you have the same problem on all client sites, but if you have one problem on a customer and everything is kept separate, then the other customers don't feel it necessarily.
You can run your main codebase on a separate test server for doing updates and then simply patch your customer FTP files and database SQL.
But Keep it simple and separate!