Multi-site using single codebase & multiple DBs / site directories? (Evo1.0.0)

Hello everyone,

I’m really impressed with how well-designed MODx is - as a total newbie, it took me only about a half hour to install it on my server yesterday, and everything went without a hitch. Now I want to figure out how to set up separate sites for separate customers, using multiple databases but using a single MODx codebase.

After googling and looking in the forums, I’ve seen many "multi-site" solutions, but many of them are for Revolution, or they’re for running multiple sites from the same MODx Manager. I’ll be using Evolution, and each site will maintained by a different customer, so there’s no need to access all the sites from the same MODx Manager. So I hope it’s okay if I post "yet another question about multi-site" here.

What I’m looking for is this: a simple and secure multi-site, multi-database solution using a single codebase / installation of MODx Evolution 1.0.0 - where each site has its own separate directory on the server to hold only those files which are unique for that site (e.g., index.php, uploaded image files, etc.)

I don’t need to be able to access all the sites from a single MODx Manager, and it’s fine to use a separate MySQL database for each site - so the discussions at the links below for example don’t seem to be applicable:
http://www.modxcms.de/multiple-domains-with-modx.html
http://modxcms.com/forums/index.php/topic,38542.0.html

But what I would like to do is use a single codebase / installation for MODx on my server’s hard drive, to allow installing updates or additional snippets for all sites simultaneously.

So I’m thinking that the only thing that needs to be "separate" for each site (aside from the separate MySQL databases) would be a separate directory on the server containing only those files which are specific to that site (eg, index.php, uploaded image files, etc.).

The idea here is that the multi-site capability would be handled by using separate MySQL databases, a carefully planned directory layout on the server’s hard drive, and name-based virtual hosting on the web server - without having to write any PHP snippets for MODx. So MODx doesn’t have to do any work to figure out where each HTTP request is coming from - it’s handled by the web server and the directory structure.


I have used this multi-site, multi-database, single-codebase, directory-layout approach successfully for Drupal, following the instructions here:
http://justinhileman.info/articles/a-more-secure-drupal-multisite-install
and it’s very simple and secure. I’m hoping that someone can point me to a similar solution for MODx Evolution 1.0.0.


I should also mention that instead of using lighttpd, I’m using nginx, which has about the same performance, and uses less memory. The configuration file for nginx is shown here:
http://modxcms.com/forums/index.php/topic,35708.0.html

To set up name-based virtual hosts in nginx, you just create additional ’server’ sections in the nginx.conf file, using a different value for the ’server_name’ variable in each ’server’ section. I believe that something similar is done in lighttpd:
http://www.google.com/search?hl=en&num=100&q=lighttpd+"virtual+hosts"&aq=f&oq=&aqi=


So the main question I have is:

Which files/directories are "site-specific" - and which ones are part of the MODx codebase?

Once that’s answered, I think it should be easy to create additional directories for those files separate from the single, centralized MODx codebase, set up some Linux symlinks (or "aliases" if it’s a Windows server), and configure virtual hosts on the web server - and this would give a simple multi-site, multi-database, single-codebase solution for MODx Evo with little or no modifications to any PHP files.

Can’t be done with Evolution; that’s one of the reasons the Revolution was started.

Quote from: sottwell at Aug 11, 2009, 09:49 PM

Can’t be done with Evolution; that’s one of the reasons the Revolution was started.

OK, thanks for the quick reply.

If that’s the case then... would it would if I create an entirely seperate MODx installation for each site on my server’s hard drive? Are there any disadvantages to this approach (beyond having redundant copies of MODx on my server’s hard drive)?

That works fine. I have several on my VPS, each in its own virtual host.

Quote from: sottwell at Aug 11, 2009, 10:03 PM

That works fine. I have several on my VPS, each in its own virtual host.

OK, thanks.

I see the zipfile for MODx only takes up about 3 megs... I’m not sure how much space it takes up when it’s unzipped (I don’t know the Linux command off-hand to get the size of a directory!)

But say it’s around 6 megs per MODx install. That doesn’t seem too bad.

Out of curiosity, I may later run a couple of sites, each with their own MODx installation - then do a ’diff’ command to see exactly if any files are different between different installations.

I wouldn’t be surprised if most of the files between different MODs installations remained the same. If that were the case, maybe I could use symlinks to redirect the unchanged directories to a centralized MODx install. This would save a bit of space, and could make it easier to simultaneously upgrade or add new snippets to multiple installations.

Just an idea.

The only files that will differ initially will be the manager/includes/config.inc.php file, since that’s where the database access stuff is kept. But as you develop the sites, some of the stuff in the assets directories will change, such as templates, snippets, images.

Of course, one of the biggest hard drive real estate eaters will be images; if you have a lot of images and are worried about drive space, you might want to consider storing your images elsewhere. You can simplify the creation of the links to images using a chunk that has most of the URL to the image, and just using the actual image name in your TV or however you set image links:


Everything that you edit in the manager, such as documents, chunks and snippets, is stored in the database, which of course itself resides on the hard drive in its own location, so if you’re concerned with total hard drive space you’ll need to keep track of that as well.

Quote from: sottwell at Aug 11, 2009, 10:42 PM

The only files that will differ initially will be the manager/includes/config.inc.php file, since that’s where the database access stuff is kept. But as you develop the sites, some of the stuff in the assets directories will change, such as templates, snippets, images.

Of course, one of the biggest hard drive real estate eaters will be images; if you have a lot of images and are worried about drive space, you might want to consider storing your images elsewhere. You can simplify the creation of the links to images using a chunk that has most of the URL to the image, and just using the actual image name in your TV or however you set image links:

<img src="{{imagePath}}image.jpg" alt="" />

Everything that you edit in the manager, such as documents, chunks and snippets, is stored in the database, which of course itself resides on the hard drive in its own location, so if you’re concerned with total hard drive space you’ll need to keep track of that as well.

OK, thanks. I guess total hard drive space won’t be too much of an issue. I just kinda thought that having a single codebase would be "cool"

As far as images ... I imagine that each site would have its own images, so I guess there’s not much point in trying to consolidate them into one central place.

So I’ll just create a separate MODx installation for each site, and then set up virtual hosts in my webserver.

Thanks.

Revolution is the epitome of "cool"

Quote from: sottwell at Aug 11, 2009, 11:07 PM

Revolution is the epitome of "cool"

Yes, Revolution sounds great.

But, it’s not recommended for production use yet is it? I heard it doesn’t work with some versions of IE yet.

I am looking forward to using it though, once it’s out of beta!

The front-end will work on any browser; it’s the fancy Javascript/AJAX backend that IE (surprise, surprise) chokes on.

It all depends on your development time frame, your add-on needs, and your patience. The help here and on the newsgroups (#xpdo and #modx) is great.