CMS Made Simple Forums

Hello,

One of my client has a CMSMS Website with information about all the countries of the world. It is growing now into a HUUUUge system, making that the admin section is getting very very slow (a lot of pages, sections, sub-sections, sub-sub-sections etc...) and practically impossible to handle because of memory limit.

To solve this, we will propose to divide this website in 5 cmsms (according to the various continents): One CMSMS for Europe, another for Africa, another for Asia, one for America ... This way the load will be divided.

In this optic, we will have several directories each with its own CMSMS adressing a different database and having different admin, which is perfectly OK.

The question is, Do we really need to copy every time the entire CMSMS ? or is there a way by which we could just adapt a few files in order, for each continent (directory) to have its own admin section, its own database and own config file ?

This would greatly facilitate the upgrade as well as the management of components, plug-ins and add-ons.

Thanks for your suggestions on this matter.

Henris

Theoretically, you should be able to have different databases with one install. You could put code around the database connection info in the config.php to present different database information (different /uploads as well) depending on the current URL. You would have to have your images for your templates and other collateral to be in separate directories.

I don't think it would facilitate upgrading, however... Instead of upgrading one at a time, and spending time to make sure its working before moving to the next.. You would be in effect upgrading all at once, and would have to validate them all, debug them all at the same time.

Some modules might not play nice with this scheme.

It is possible to do this kind of thing (I've done it before) and make it work. It does mean modifying the core files though so any official support goes out of the window (you would need to be completely comfortable with php and have a good understanding of how CMSMS works).

As wishbone points out, you also have to be careful when upgrading, once you upload the new files you've already half upgraded all the sites, you would then need to go through each one and run the database upgrade separately - not too bad for a few small sites but with lots of big ones it can be difficult to track problems.

In your case, if one site is too slow splitting them is probably the best way to go but I don't think it's any less work to do it this way. Whichever way you look at it you still have 5 websites to manage.

If you're still interested you can PM me and I'll let you know how I did it (it's against forum rules to post the necessary modifications here).

Why would you have to modify the core?

Each website needs it's own "cache" and "templates_c" folders. It isn't enough to just dynamically change these in the config file based on the url. Fileloc.php has some hardcoded defines which also need to be dynamically set based on the requested site.

Also, I think I'm right in saying that the config.php file should be considered a core file. Some upgrades in the past have automatically updated it so if you add code in there to select different databases you might have problems.

Many thanks to you both,

Still I think that in order to solve the memory problem, it is necessary to have more than one cache and more than one admin. In fact, the slowing down occurs mainly in the admin (back office) where it takes ages, when section are expanded (or to expand sections) in order to edit pages. From your replies, for the moment, I'll be inclined to have several complete CMSMs.... but maybe something else will come up

Henris

tomgsd wrote:Some upgrades in the past have automatically updated it so if you add code in there to select different databases you might have problems.

I would think that these upgrades would just append a new definition to the file.. I don't think it would modify the existing information.

I would think that these upgrades would just append a new definition to the file.. I don't think it would modify the existing information.

That may well be the case but the point I was making is that you don't know what future changes will be made and that you cannot expect support from the dev team if you modify it yourself.