Centralized CMS system
I'm starting to project a CMS, but it's a little bit different, my theory is to build:
Centralized cms system, with single administration panel, all customers sign in to that panel, and see the data relevant to their site.
The cms should have a super-admin login (for me) with built in function for create new site easily (basically it just creates new web root and points apache/nginx to it), and to assign required modules/plugins for that customer.
Any customer site will have it's own database with their data in it, and a 'main' cms database. Approximate directory structure:
I have a dedicated server for development, just need to choose what *nix version to use.
As far as i think, the pros:
1) One centralized cms, any bug fixes affect all customers so new version of cms deploys to customers instantly
2) Easy managing of sites
1) Scalability - what if need a second server? Should i copy that main cms there also - but from that minute, it's not centralized anymore (you solutions?)
Do you see anymore pros and cons?
This is ideal to installing a unique copy on each machine and I don't see how it would affect scaling any, the same techniques owuld apply whether you had 100 copies running a hundred sites or one copy running 100 sites.
What you do have to worry about is the design challenges you will face when serving virtual individual web sites off a single application installation.
It's not as easy as you may think, otherwise all CMS would be doing it, which very few do, at least not without hacking or extensions, etc.
you would need to separate your application tier from your data tier which would mean all your php code sits on one server and your database sits on another. As you need more resources you add to your app tier by putting a new server with the same php code on it, and adding a load balancer app to be able to distrubute the load across your app machines. If you find your database is running full steam, you can make that one the master and add a slave DB for reads. Your app code would just need to know if it's a select read from a slave, otherwise writes, updates and deletes go to the master DB server.