Central Application System

[leon_nerd]

Hello,

 

I am in the process of developing a PHP application/system. As per the client requirement this application should be supplied a logo, color scheme and few other information and it should output a website with those settings. He wants to create website everyday using this system. One of the main requirements of the client is that in future whenever there is a change (additions, appending, removal) of feature(s) in this system then it should reflect the changes in all the websites that have been created from this system.

 

Now, the first idea that hit my mind was to create websites and upload them on their respective ftp server. In future whenever there was a change in the parent Application/system, then we will manually transfer the files to every ftp server. This of course becomes a tedious job when the site number increases.

 

Today another architecture hit my mind and this one seems to be more logical in terms of meeting the client requirements, specially the updating part. I am thinking of developing one application and host it on a server. Now, whenever we want to create a site then we will create a website profile table in a the database with every setting necessary to run the application like name, logo, colors, database information etc. Now this way I will have only one application running with several website profiles existing in the database. Whenever a user wants to open a site www.abc.com then it will redirect it to my main application with user entered URL as POST and then using this value I will fetch the website profile information from the database, substitute the values in the application and show it to the user. So if another user types www.xyz.com then it will take it to the main application with xyz as the site name. I will then pull out the website profile from the database, fetch the values, substitute them in the main application and show it to the user.

 

So this way I will have to maintain only one application and the variations will actually take place using the various website profile info that exists in the database. Now, I have few queries with this:

1.) Do you think this will work?

2.) When the user is directed to the main application then the browser addess bar URL will change. Is there any way through which I can display the user entered URL in the browser so as to make the user feel that he/she is browsing (say) www.abc.com and not www.parentapplication.com?

3.) What do you think about its performance? Will the performance get affected? I mean the load time and query running times?

4.) What are the downsides of this approach? One of them which I can think right now is the overhead of fetching the database info on every page. But, I think I can solve this problem by using the session variables.

 

Please let the thoughts flow in. I really believe in this second approach and I would want honest suggests, advices and criticism for this approach.

 

Thanks.

[Daniel0]

If you really want to do this then I would still stick with one database, and in that database create a table called e.g. sites with the following fields:

 

site_id - unsigned int, auto increment, primary key

domain - varchar

 

Now, assuming you're using Apache, have a virtual host setup like this:

<VirtualHost *:80>
ServerAdmin someone@foo.com
ServerName base.yoursite.com
ServerAlias www.example.com example.com www.somethingelse.com somethingelse.com # all your domains
DocumentRoot /var/www/htdocs

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* index.php [L]

<Directory /var/www/htdocs>
	Order allow,deny
	Allow from all
	Options -Indexes
</Directory>

# [...]
</VirtualHost>

 

Now use $_SERVER['HTTP_HOST'] to determine which site it is, and the request you can get the request through $_SERVER['REQUEST_URI'].

 

So if we make the request http://www.example.com/user/login then you'll have:

HTTP_HOST = www.example.com

REQUEST_URI = /user/login

 

Now, also have a field called site_id in your settings, users, etc. tables - where ever it is relevant to distinguish between the different sites.

 

1.) Do you think this will work?

Yes, but I don't think it's the best solution (see below).

 

2.) When the user is directed to the main application then the browser addess bar URL will change. Is there any way through which I can display the user entered URL in the browser so as to make the user feel that he/she is browsing (say) www.abc.com and not www.parentapplication.com?

The above should accomplish that. It should be entirely transparent to the user.

 

3.) What do you think about its performance? Will the performance get affected? I mean the load time and query running times?

I'm not sure, but seeing as they all run on the same server, if one site takes a lot of resources then it'll negatively effect the other sites. Doing a setup like this will make it difficult to move one server to another place seeing as they're all tied together.

 

4.) What are the downsides of this approach? One of them which I can think right now is the overhead of fetching the database info on every page. But, I think I can solve this problem by using the session variables.

Querying the database on each request isn't a problem. Most dynamic sites, including this one, have several queries on every single page.

 

 

Another solution could be using version control like SVN, git, or Mercurial (in fact, I'd recommend it regardless). Then you can simply do a checkout on the individual setups, and you could write a shell script that will run the update command on each setup. In relation to this you could also use something like Phing to automatically handle database schema changes. Here you would want to have a separate database for each site. This setup is more advanced and requires some sysadmin skills, but I think this would be better in the long run seeing as it is much more scalable. Using this setup it would require minimal effort to move sites to different servers should that be necessary. You could even create a shell script that would make it easy to deploy an entirely new site (or of course, use Phing to this as well).