How do I run multiple websites on the same server with the same code base in PHP?

Question

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?

Answer 1

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:

/var/www/src/index.php
/var/www/src/more_source.php
/var/www/clients/client_a/settings.php
/var/www/clients/client_a/src -> ../../src/
/var/www/clients/client_b/settings.php
/var/www/clients/client_b/src -> ../../src/

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" to require "../settings.php").

Answer 2

I'd split into the library (your working code) and the config (the three lines for each user, probably database connections and the like).

Split the library out to a universal location eg /home/library (in *nix) and allow read attribute to the other user accounts.

Now for each site there's a config file which first includes the library and second sets the site-specific config. Updating the library updates all versions. A word of caution though - you'll want to have some unit tests in place such that an update of the library doesn't break anyone of the single sites.

eg config: (one per site)

<?php
require_once('/home/library/include.php');
//Line 1 config
//Line 2 config
//Line 3 config
?>

If your library of code is also used to render the content (index.php etc) then you have two options: (1) create symlinks between each site's web folders and the library source, or (2) separate your code into core functionality and rendering code.

A symlink creates a system link between two points on the drive (it's like a pointer). A properly created link allows you to access a folder by a different name so you can create /home/user1/library, /home/user2/library /home/user3/library, and they all point and contain the content of /home/library (they're not copies of the data).

I'd be included to go with #2 although it'll take more work up front. Your library does the work, but the site rendering is performed by the the second piece of code which is supplied on a per-site bases (likely including the afore mentioned config), this allows more flexibility on a site by site basis (even if you don't foresee yourself needing this yet). As a side effect you're on the way to a multi-tiered application.

Answer 3

Personally, I have a client table on the database that holds the current version number of the code that they're running. When a user logs in, it sets a cookie called CodeVersion indicating the code version for that client (e.g. "v5-09-00"). In the Apache .htaccess, I have:

RewriteEngine on

RewriteCond %{HTTP_COOKIE} CodeVersion=([^;]+) [NC]
RewriteRule ^(.*)$ http://v%1.%{HTTP_HOST}/${escape:$1} [R=302,P,L]

and within the local hosts file, I have:

127.0.0.1    myservername       myservername.myserverdomain.com

127.0.0.1    v5-08-00.myservername  v5-08-00.myservername.myserverdomain.com
127.0.0.1    v5-09-00.myservername  v5-09-00.myservername.myserverdomain.com
127.0.0.1    v5-10-00.myservername  v5-10-00.myservername.myserverdomain.com

which handles local redirection within Apache to an entry in vhosts

The vhosts file sets the environment for each version of the code:

<VirtualHost *:80>
    ServerAdmin [email protected]
    DocumentRoot /usr/local/apache/htdocs_5-09-00
    ServerName v5-09-00.myservername.myserverdomain.com
    ServerAlias v5-09-00.myservername
    ErrorLog logs/myservername-error_log_5-09-00
    CustomLog logs/myservername-access_log_5-09-00 common
    php_value include_path ".:/php/includes:/usr/local/include/5-09-00/API:/usr/local/include/5-09-00/library:/usr/local/include/5-09-00/businesslogic:/usr/local/include/5-09-00/configuration:/usr/local/include/5-09-00/library/PHPExcel/Classes"
</VirtualHost>

<Directory "/usr/local/apache/htdocs_5-09-00">
    Options Indexes FollowSymLinks ExecCGI
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

Within each set of directories, I can have symbolic links pointing to common code, and actual php/ini files for client-specific code or configuration.

Answer 4

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!

Answer 5

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:

  // file: index.php
  include(".../shared/index.php");

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.

Answer 6

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.

Answer 7

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.

Answer 8

How about something that uses the same code, but each has own mysql.
Like, http://mycms.com/myuser/ brings the prefix myuser_ to the tables, thus, allowing 1 src structure, and multiple site. You will need .htaccess though

Answer 9

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.