Reusing code is definitely desirable. It is hard to imagine from your posts how different the sites will be from each other. Are we talking about logos, and color schemes or different functionality?

I ll start with the different look & feel. I ll also assume that this is the only application on the server.

I recommend planning your directory structure carefully. Something like:

www-root/  
   / lib  
   / themes
        / domain1  
        / domain2  


index.php:

<?php
$host = $_SERVER[ HTTP_HOST ];
$include_theme = "themes/" . $host . "/configuration.php";
//make sure the file exists
require_once($include_theme);

This is a simplistic approach but something to thing about.

It s very simple actually.

Your code base can and should be single. You upload it to hosting1 and hosting2. When maintaining, as soon as you updated the code, upload it to both hosting spaces.

I suppose it s how this site works as well. Look at the footer of the page. You have there stackoverflow, meta, superuser and serverfault. If you look what the comment on bottom-right says right now, it would be "svn revision: 5404". The same thing. One code base published to four sites. The databases of course are different and contain completely different content.

So the variable parts are:

1. Configuration

2. Settings

3. Data

Those ones you need to copy.

You need to code it this way that configuration and settings are not hardcoded but either stores in some database table or at least in some external configuration files. These do not make part of code (or implementation if you wish) so they do not need to be in code. If you have them in, take them out.

I suppose you could have two different domains pointing at the same server, and set different configurations based on the host name. I wouldn t recommend this though. You may encounter issues with stability and performance, especially if you have a large user base or a large number of domains pointing to the code base.

Generally, if you are running multiple sites, you should have a different server for each.

Edit:

After reading comments on the other answer, I understand your use-case a little better.

If you have a large number of sites that you want to use this set up for, if you design the architecture correctly, and implement a load-balancing scheme of some sort to handle large user loads, you could make this work.

To recap:

• get multiple servers, and balance the load across them.
• design the application to handle a large user load.
• use the host name to determine which configuration to use.

We do this with about 15,000 unique domains right now. It s not difficult, but it does take some design considerations to implement properly.

You can do it off a single codebase & server, and essentially just build your code to depend entirely upon the incoming request s HTTP_HOST value. Then everything in your DB keys off of that value as a means of segregating data properly and answering the request with the appropriate data/html.

For security reasons, you might consider:

A) set a separate open_basedir restriction for each host so that user uploaded files cannot be accessed by other websites, for example: /shared_library /host1/user_images /host2/user_images

You can include shared and domain specific directories in the allowed paths.

B) connect to a different database for each host, to prevent any errors in your database queries from accidentally grabbing another website s data, and to allow easier scaling of database servers (e.g. Move busy domains onto a different database server)

If you have an extremely simple application, You might get away with one database.

In any case, you should have a roll out strategy so that none of the sites break when you make changes.