Multiple Sites Sharing Code

If you are setting up multiple web sites then you may possibly need to set up several sites that all use the same script on the server to control the site. If you only have two or three such sites then repeating the entire script for each site is not going to be a huge problem. If you have dozens or even hundreds of such sites then the situation is very different. Some script providers such as WordPress cater for this with their script - if you turn on a multisite option within WordPress then you can host as many WordPress sites as you need using just one copy of their script.

So what do you do where the script you want to use doesn't make provision for this or where you are writing your own script that needs to be used for many sites? In just about every case there are going to be some files that need to be different for each site even if it is just a config file and a logo.

The solution to at least most of this problem if your sites are running on Apache web server is to set up some redirects in the .htaccess file.

We'll start by pointing all of the domains to the one folder that contains the script we want all of the sites to use. Next we set up a sub-folder for each domain using the domain name as the folder name - so if the domain is we set up a folder called "". All of the files that need to be different for each domain need to be moved to the corresponding location within that folder to where they would be in the main folder if that was the only site we were setting up. We also need to make sure that the files we move like that do not have a copy of the file in their original location.

For all of the files retrieved by the web page via HTTP we can now set up a redirect in the .htaccess file so that when those files are not found in their original locations that it redirects into the appropriate sub-folder for the domain and looks for it there. By using the domain name we greatly simplify the code for these sub-folders since both the domain that is being used and the sub-folder we want to redirect into can both be references using %{HTTP_HOST}. The only other thing we need to include in this test is to make sure that it doesn't apply a second time if for some reason the file isn't in the right place in the either the original folder or the site specific sub-folder.

The code to include in our .htaccess file to do this is as follows:

Options +FollowSymlinks
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REQUEST_URI} !^/%{HTTP_HOST}/
RewriteRule ^(.*)$ /%{HTTP_HOST}/$1 [L]

This takes care of all the files that need to be downloaded with the web page. What it doesn't handle is any include files that your pages need to reference as they get included into the page on the server and not in the browser. The only way to fix this is to amend the script itself.

Where we know exactly which include files are shared and which need to be specific to each domain we can fix the problem by simply adding include files back into the original location in place of each of the files that needs to be retrieved from the specific domain folder. Each of these files will have the same content that simply specifies another include pointing to where the moved include file can be found.

include $_SERVER['HTTP_HOST'].'/restOfPathToMoved/';

If you want a bit more flexibility and can make modifications to the script that will not be overwritten if you upgrade the script then you can override the include_path at the top of all the script pages so that it looks in both places for the includes. You just need to ensure that if you do this that all of the includes use the path setting to decide where to look rather than having the path hard coded in the script.

If the script allows users to upload files then another thing you will need to consider is getting the user files to upload to the right place within the specific sub-folder for the appropriate domain. Just how you should fix this will depend on the particular script.


This article written by Stephen Chapman, Felgall Pty Ltd.

go to top

FaceBook Follow
Twitter Follow