Multi-Site Single Core - Pros and Cons

I've been looking around the forums and Google and while I have found some good tuts and people successfully using the advanced Revo feature of a single Core installation for multiple websites I am not returning much of anything to the benefits and possible pit-falls of it.

This sounds like an amazing feature and I am very interested in it, but I am worried about the unforeseen problems that may arise like possible caching overloads, component problems, site speed, and update issues.

For those who successfully use this feature what have you discovered?

If you could give your pros and cons for this type of install it would be great to hear about.

Thanks!

I have several sites running on a single core, and there are indeed both pros and cons of this setup.

Pros:

• Shared upgrade process for MODX and extras.
• Shared chunks/snippets/etc
• Shared login for manager users
• Possible shared login for front-end users. This could be a big one if you want your visitors to have a single user account for all of your sites.
• Direct access to data from the other sites - for example if you want to list blog posts from one site on another site.

Cons:

• Shared cache. This is the big one IMO. Clearing the cache clears it for all sites, so edits to one site impact performance for all sites. There may be ways around this with cache partitioning and getCache, I haven't tried that yet.
• Single point of failure. If something goes wrong all of your sites break at the same time. I've had this happen.
• Potential for cross-context scripting errors. This isn't a big deal, but when you're writing your own snippets you have to make sure to be aware of context. you should probably do that anyway, but it's one more thing you have to worry about. There is also the possibility that bugs in existing extras will affect you that would not have otherwise.
• Security headaches. If you want some manager users to only access one site you have to deal with context-specific permissions. Again, not a huge deal but something else to be aware of.
• Size, complexity and clutter. I advise using categories carefully to keep your chunks in particular from becoming a tangled mess. You also tend to end up installing a lot of extras that may not be necessary for all sites.

I'm actually in the process of splitting one site off onto a separate core. The reasoning here is that it really doesn't have a lot to do with the other sites. They don't share content, they are managed by different users, and they use different extras. This site has been having some problems and creating problems for the other sites in the database. It's a small site and won't be hard to move, and I've reached the conclusion that it'll be better off on its own.

I'm still keeping other sites in the same core. They share content and data and use a lot of the same extras, and may ultimately need to share front-end users as well.

Very interesting and useful info, thanks for sharing freejung.

This site has been having some problems and creating problems for the other sites in the database.

Some of your points like this one didn't occur to me. Seems obvious now the fact that they would all share one database. That seems like a potential mess to clean up if you migrated a single site of the shared core. I can see the sharing of elements could be very useful for similar types of sites, and I do hear what you're saying about having to keep up on your housekeeping or it would become confused.

From your points it sounds like probably if you had related or similar sites that utilize the same add-ons or users etc it would be great, but if you had completely different types of sites on one core it could prove to be more hassle than help when it comes time to update or isolate a problem.

I'm actually in the process of splitting one site off onto a separate core.

From this I would assume it is possible to go from traditional to advanced installs, or back, in order to either separate/join cores or just move the core out of the web access folder. Is that as simple as running the advanced installer when you update and picking a new location for the core or is it much more involved?

Thanks again for the input.

Quote from: eric.swd at Nov 19, 2012, 07:13 PM

From this I would assume it is possible to go from traditional to advanced installs, or back, in order to either separate/join cores or just move the core out of the web access folder. Is that as simple as running the advanced installer when you update and picking a new location for the core or is it much more involved?

No, not really. There is no easy way to do this that I know of, and I wouldn't recommend going into a project with the assumption that you can reverse this decision. In most cases you'll probably be stuck with it.

The way I'm doing it is to create a completely new, clean install of MODX and import the data from the shared site into it. In this case it's not a lot of data (~40 resources and a handful of chunks and templates) so it's not that hard. I'll export the resources directly from the database and move the chunks and templates by hand.

If the site were more complicated I wouldn't attempt this. Also, I'm not done with it so I'm not sure how it'll work out, but if worse comes to worst, completely recreating the site by simple copy/paste would not be all that hard.

From your points it sounds like probably if you had related or similar sites that utilize the same add-ons or users etc it would be great, but if you had completely different types of sites on one core it could prove to be more hassle than help when it comes time to update or isolate a problem.

Yes, that's exactly it. If you have several sites that are similar in design and/or function, or if your sites are all managed by the same manager users or will have the same group of front-end users, sharing the core might be the way to go as it will reduce redundancy.

On the other hand, if you have several sites that are pretty much independent of each other, I would go with a separate install for each site. It's not all that much hassle to keep multiple installs updated - package management makes updating your extras extremely easy and core updates aren't that hard either. If your only reason for sharing a core is to save time on updates, don't do it. It is quite likely that maintaining multiple contexts in one core will be more hassle than upgrading multiple cores.

Quote from: esnyder at Nov 20, 2012, 03:04 PM

f you have several sites that are similar in design and/or function, or if your sites are all managed by the same manager users or will have the same group of front-end users, sharing the core might be the way to go as it will reduce redundancy.

I'm working on this setup at the moment (a kind of white-labelling system for building sites on multiple domains using the same set of MODX elements) and it's all functioning very nicely.

You do have to take some extra care in your custom coding to ensure you're initialising the correct context however, especially for ajax and back end processes which might default to 'web' and return unexpected results.

Very interesting and useful information.

I noticed that some add-ons note that they require the .pl package to work properly. Have you experienced any problems with add-ons not working well, or at all, with the advanced install/single core deployment?

Quote from: eric.swd at Nov 21, 2012, 12:35 PM

I noticed that some add-ons note that they require the .pl package to work properly. Have you experienced any problems with add-ons not working well, or at all, with the advanced install/single core deployment?

Actually in my case I'm running multiple sites of the Standard installation, so can't answer this for you.

Each domain is represented as a separate context, with switching handled by a (heavily cached) context router plugin that runs on every page request.