Best practice for managing multiple domains?

There are several documented methods for using a single Revo manager installation to manage multiple domains. The one I originally chose (adding a switch statement to index.php) breaks on upgrade because index.php gets overwritten by default. Another common method - making copies of index.php in separate directories for each domain/context - wouldn’t break on upgrade, but seems like bad form because presumably the structure of index.php will (or at least could) be modified in a future version upgrade, and the copies would be out of sync.

The one method I’ve seen that doesn’t seem problematic re: upgrades is the "One Gateway Plugin" method mentioned in the Revo documentation: http://rtfm.modx.com/display/revolution20/Using+One+Gateway+Plugin+to+Manage+Multiple+Domains

My questions, I guess, are as follows:

1. Do people (MODx core team and/or anyone with experience managing multiple domains) agree that the "switch-statement" and "multiple directories" methods are somewhat problematic in regards to upgrades? And that the plugin method seems best in this regard? Or am I just doing something wrong?

2. Does anyone have any data on the relative performance of these approaches? More to the point: is there any significant performance cost to using the plugin method vs. the other two?

I’m using MODx to manage a 3-site setup and I agree, I had some difficulty deciding which method to go for.

In my case, all 3 sites on my modx setup are actually related - so I have my personal site (’web’ context) a photo gallery (’photos’ context) and another context for storing all media items (’media’ context.)

When I started playing around with Revo (I’d been on Evo before) I started using a gateway plugin. However my issue with this approach, is that because all 3 site addresses pointed to the same document root, you could access the manager using them all.

E.g.

www.mysite.com -> www.mysite.com/manager
photos.mysite.com -> photos.mysite.com/manager
www.mysite.com/media -> www.mysite.com/media/manager

This I didn’t want and I couldn’t find any other way around it. I also tried setting up a manager-specific domain (e.g. modx.mysite.com) and while this worked, it wasn’t handled great in the manager (login cookies on different domains.) I also had an issue (which I think may have been fixed now) where you couldn’t take a single site context off-line, because the plugin was being executed after the "is site online" check, or something like that.

Another disadvantage, in my opinion, is that all your sites share the same database so you have a single basket scenario. It would be very difficult, if not impossible, to restore a single site if required.

Shortly afterwards, I found the official manual (now the #1 tool in my modx toolbelt) and read what the modx team suggested, and tried the filesystem approach. This was actually a lot easier to set up than I imagined and if I want to, I can switch out one of the sites (or bring a new, unrelated site onto the platform) and use a different config key and different database. I’ve also moved the core out of the webroot to be that little bit more secure.

In my future developments, all sites will now share the same modx core and each site will get its own manager. Individual sites may use contexts where it seems appropriate (like my personal site.) I feel that although this will take more time during upgrades - as I will have to upgrade each manager in-turn - this is an added benefit in that upgrades are more controlled. If something breaks the manager, it won’t break it for everyone.

Also as there are no changes to the shipped index.php script (as the default context for each site is ’web’) - any changes to the original will be much simpler to deploy.

Pandy,
Wow, that’s a brilliant post!!! I learned a lot, and it sums up everything I’d found in separate bits. I used the index.php approach, and I can definitely see spacing out and upgrading right over it. I’m just happy that I finally got multisite working at all, too.

Cheers, Dave

I suppose for this part you could play with .htaccess if you really wanted to stop this stuff maybe, right?
Quote from: Pandy06269 at Oct 27, 2010, 10:26 AM

When I started playing around with Revo (I’d been on Evo before) I started using a gateway plugin. However my issue with this approach, is that because all 3 site addresses pointed to the same document root, you could access the manager using them all.

E.g.

www.mysite.com -> www.mysite.com/manager
photos.mysite.com -> photos.mysite.com/manager
www.mysite.com/media -> www.mysite.com/media/manager

This I didn’t want and I couldn’t find any other way around it.

Quote from: Pandy06269 at Oct 27, 2010, 10:26 AM

Shortly afterwards, I found the official manual (now the #1 tool in my modx toolbelt) and read what the modx team suggested, and tried the filesystem approach. This was actually a lot easier to set up than I imagined and if I want to, I can switch out one of the sites (or bring a new, unrelated site onto the platform) and use a different config key and different database. I’ve also moved the core out of the webroot to be that little bit more secure.

In my future developments, all sites will now share the same modx core and each site will get its own manager. Individual sites may use contexts where it seems appropriate (like my personal site.) I feel that although this will take more time during upgrades - as I will have to upgrade each manager in-turn - this is an added benefit in that upgrades are more controlled. If something breaks the manager, it won’t break it for everyone.

Thanks for that, very useful information - although I’m still struggling to visualize how it works, so please forgive the basic questions.
Presumably you set up the first site using the advanced installation method and move the core directory. So what happens when you set up a second site? Do you create a new directory, use the advanced installation but delete the core directory and during the setup point it to the same core directory referenced by the first installation?

The bit I’m struggling to visualize is where the resources and elements are stored. When you have the two sites up and running how does the manager work? If I install a package, for example Wayfinder, is that part of the core and does that then get installed for all the sites linked to that one core directory? So then what about the resources and the files, I presume these are linked to each individual site with it’s own database. So what happens on the second site, does it get the resources and files from it’s local database but the elements are taken from the core? Is this where you’d use parameter sets to tailor snippet calls for the relevant website? Am I talking sense or am I completely wide of the mark?

Sorry for all the questions but I’m just trying figure out how it works.

Regards

Adrian

Quote from: Pandy06269 at Oct 27, 2010, 10:26 AM

I’m using MODx to manage a 3-site setup and I agree, I had some difficulty deciding which method to go for.

In my case, all 3 sites on my modx setup are actually related - so I have my personal site (’web’ context) a photo gallery (’photos’ context) and another context for storing all media items (’media’ context.)

When I started playing around with Revo (I’d been on Evo before) I started using a gateway plugin. However my issue with this approach, is that because all 3 site addresses pointed to the same document root, you could access the manager using them all.

E.g.

www.mysite.com -> www.mysite.com/manager
photos.mysite.com -> photos.mysite.com/manager
www.mysite.com/media -> www.mysite.com/media/manager

This I didn’t want and I couldn’t find any other way around it. I also tried setting up a manager-specific domain (e.g. modx.mysite.com) and while this worked, it wasn’t handled great in the manager (login cookies on different domains.) I also had an issue (which I think may have been fixed now) where you couldn’t take a single site context off-line, because the plugin was being executed after the "is site online" check, or something like that.

Another disadvantage, in my opinion, is that all your sites share the same database so you have a single basket scenario. It would be very difficult, if not impossible, to restore a single site if required.

Shortly afterwards, I found the official manual (now the #1 tool in my modx toolbelt) and read what the modx team suggested, and tried the filesystem approach. This was actually a lot easier to set up than I imagined and if I want to, I can switch out one of the sites (or bring a new, unrelated site onto the platform) and use a different config key and different database. I’ve also moved the core out of the webroot to be that little bit more secure.

In my future developments, all sites will now share the same modx core and each site will get its own manager. Individual sites may use contexts where it seems appropriate (like my personal site.) I feel that although this will take more time during upgrades - as I will have to upgrade each manager in-turn - this is an added benefit in that upgrades are more controlled. If something breaks the manager, it won’t break it for everyone.

Also as there are no changes to the shipped index.php script (as the default context for each site is ’web’) - any changes to the original will be much simpler to deploy.

Thanks for sharing your experience. I have been struggling to make one of the methods works. One gateway plugin didn’t work with friendly urls.

Now trying the filesystem approach, it works with friendly urls but no css is interpretted, and mystically the home page is redirected to the modx root domain.

Would you mind sharing your htaccess files for modx root, for other website, and if any other changes you made to the 3 files that being copied from modx root folder.

I had to change, the following line in config.core.php file

"define(’MODX_CORE_PATH’, dirname(__FILE__) . ’/core/’);"

to

define(’MODX_CORE_PATH’, ’/home/username/public_html/modx/core/’);

It was giving "error 503" if I keep the original line.


Thanks

Quote from: samba at Oct 27, 2010, 10:37 AM

I suppose for this part you could play with .htaccess if you really wanted to stop this stuff maybe, right?

Yes, you could, but then you’re back to the issue of what happens if the modx team change the .htaccess file? For me, it was more maintenance and another task to get it working - with the filesystem approach, it just works.

Quote from: apcherry at Oct 27, 2010, 11:36 AM

Thanks for that, very useful information - although I’m still struggling to visualize how it works, so please forgive the basic questions.
Presumably you set up the first site using the advanced installation method and move the core directory. So what happens when you set up a second site? Do you create a new directory, use the advanced installation but delete the core directory and during the setup point it to the same core directory referenced by the first installation?

Pretty much, yeah. I’ve not actually set up another manager and site yet but I have upgraded my existing sites and I assume it’ll largely be the same, without the core upgrade.

The core is obviously already there - so copy the setup directory from the installation package to a new site root - configure your web server and head off to yournewsite.com/setup. When asked, tell setup where the core directory is located and off you go. I assume the manager gets created during the setup process.

I might give this a go on my test kit just to see what happens as I am going on assumptions from the initial setup.

Quote from: apcherry at Oct 27, 2010, 11:36 AM

The bit I’m struggling to visualize is where the resources and elements are stored. When you have the two sites up and running how does the manager work? If I install a package, for example Wayfinder, is that part of the core and does that then get installed for all the sites linked to that one core directory? So then what about the resources and the files, I presume these are linked to each individual site with it’s own database. So what happens on the second site, does it get the resources and files from it’s local database but the elements are taken from the core? Is this where you’d use parameter sets to tailor snippet calls for the relevant website? Am I talking sense or am I completely wide of the mark?

Right - firstly, resources and elements are in the database. If you have two managers, I would assume you’ve set up two databases (remember to set a different config key for each site during set up - it’s a tiny link on the first page IIRC.) Therefore resources and elements are separate.

The recommendation from modx is that files such as PHP classes to support components go into the core/components directory (so are in the core) and front-end files to support these components (e.g. images/javascript etc) go in assets/components in the site (so are site-specific.)

Of course packages can also put things in the database - system settings, for example - so again these are site-specific.

I would hesitate a guess that you can install a package in one site, but it won’t be available in the other site (even though it’s in the core.) Judging by how modx works, I’d also guess that the package - once downloaded in one site - will be available to install in the other site without downloading it again.

Quote from: apcherry at Oct 27, 2010, 11:36 AM

Sorry for all the questions but I’m just trying figure out how it works.

No worries - I’m learning something new every day with modx! It’s a huge beast.

Quote from: dragona at Oct 28, 2010, 12:15 AM

Now trying the filesystem approach, it works with friendly urls but no css is interpretted, and mystically the home page is redirected to the modx root domain.

I would check the paths to your assets folders. Personally all my CSS is a resource in modx so I can use [[~id]] tags for images in my CSS files.

Quote from: dragona at Oct 28, 2010, 12:15 AM

Would you mind sharing your htaccess files for modx root, for other website, and if any other changes you made to the 3 files that being copied from modx root folder.

I had to change, the following line in config.core.php file

"define(’MODX_CORE_PATH’, dirname(__FILE__) . ’/core/’);"

to

define(’MODX_CORE_PATH’, ’/home/username/public_html/modx/core/’);

It was giving "error 503" if I keep the original line.

My installation started with a different core path from the word go, so in my original config.core.php I think it’s already got the absolute path to the core. It looks like you’re installation has the core as part of the site - what you’re looking for is a shared core; therefore all sites will need an absolute path to the core in their config file.

The only thing I’ve changed in the index.php files for other sub-sites is the context. As I said above, I haven’t yet set up another separate site with a new manager but shared core - I’ll give this a go over the next few days and post back my findings.

Thank a lot for the advice. I will give a try to using css as a resource.