Multiple Sites - One Application

[eluser]Kemik[/eluser]
Hello,

I'm creating a CMS where users sign up and they're given a subdomain with my CMS installed. They can then edit at will, users sign up, etc. I'm looking in to two options for managing the files for the CMS.

1. Store each CMS copy in it's own folder, database, etc. (Basically a whole cPanel account per CMS).
2. Store the files centrally. Possibly create seperate databases or do something else using one.

Option one will be harder to maintain and update. As if I make one update with the files I have to manually do each CMS. Option two is easier to maintain, however managing how the CMS gets it's site title, content, etc is harder as each user may have their own theme, logo, etc.

How would you advise I could do this? I'm not thinking about thousands of CMS installs, but possibly hundreds (100 - 300) if it takes off.

Thanks for your opinion.

[eluser]Crafter[/eluser]
Look at the index.php in your Code Igniter installation. there are some notes in there, as well as a link to the manual page where you can get more information.

[eluser]Kemik[/eluser]
I was thinking more of something along the lines of creating an app which pulls from different databases depending on which subdomain the user is visiting, or put it all on one database and try to distinguish between the different subdomains.

I don't have much experience with centralised apps.

[eluser]Crafter[/eluser]
The method of relocating your system and application directories described in index.php will accommodate different databases scenario.

The single database scenario is slightly more complex and must be handled by your application. Look at the user manual under the database config file.

[eluser]obiron2[/eluser]
you basically have three choices.

1) Add an account ID to every table and use it in your select queries. This is fine if you have built it in from the start but can be a right pain if you are trying to retro-fit it. Also, if you are allowing external applications (e.g. report writers such as Crystal Reports) access to the data it is obviously not secure.

2) use a separate database for each account, but this will require some PITA maintenance to run patches and upgrades. The advantage is that each database can have different user accounts and is therefore secure

3) a halfway house where you prefix the data tables with the account ID but keep it all within one database. E.g.

XX_Thread and YY_Thread are both the same data structure but for different users. To generate queries you would need to convert queries from looking at _Thread to their relevant account ID, probably using something along the lines of

"SELECT * from ".$accountID."_Thread"

You can then run upgrades on all the tables with similar names using a script and the data is (relatively) secure because you only get one accounts data in any tables (plus you don't overuse your database allowance on your ISP...)

Obiron