How do I run multiple websites on the same server

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

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 2

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 [e-mail]
    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 3

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.