[MAGNOLIA-2132] One Magnolia to rule them all Created: 13/May/08  Updated: 23/Jan/13  Resolved: 19/Aug/09

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: None
Fix Version/s: 4.1.1

Type: Improvement Priority: Major
Reporter: Fabrizio Giustina Assignee: Fabrizio Giustina
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
depends upon MAGNOLIA-2309 Add a standard way of configure beans... Closed
relation
is related to MAGNOLIA-2849 Cache: cache keys based on host names... Closed
is related to MAGNOLIA-2133 Authoring: filtering usable templates... Closed
is related to MAGNOLIA-2134 Public instance: virtualhost support ... Closed
is related to MAGNOLIA-2135 Public instance: repository content f... Closed
is related to MAGNOLIA-2136 Public instance: different error page... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

In some situations it would be great to have the ability to use a single magnolia authoring instance + a single public instance for managing more websites.
We encontered similar requirements several times in the past and may want to work at adding a better support for this in Magnolia. I'll use this as a master issue in order to group any related issue or needed enhancement for this.
Open for discussions



 Comments   
Comment by Simon Goodchild [ 15/May/08 ]

I know quite a few people (myself included) have developed slightly kludgey solutions to this problem (see user list and wiki), so an easier and more standardized solution within the magnolia core would be very useful. The memory use improvements in recent releases have made it more viable to run multiple instances, and there will always be cases where it is better to separate things completely like this, but there are also many instances where a shared solution would work much better. A classic example of this is multiple small microsites - it is impractical to run say 50 instances of magnolia when each one only contains 5-10 pages, but there are also administration benefits to using a shared system:

  • You can use the same set of standard dialogs across each site, with easier deployment of changes to these to one system instead of 50
  • Setting up a new site is just a case of copying or importing an existing site, so no need to configure app server, RDBMS, boostrap, etc. each time
  • There is just one set of administrator credentials, so easier to change these in one place if you need to
  • Easier to monitor the system, as if the single shared instance is up then all the sites should be

That's just off the top of my head, but there are probably plenty more!

Regarding the high-level approach to how we could go about doing this, the approach all out kludgey solutions have taken is to have a separate root node for each site and apply permissions and Web server mappings to allow access. That would seem the obvious choice for a core product solution, and make migration from existing solutions easier for everyone. When I was architecting the approach to my own kludge I also considered the alternative of a separate workspace for each site - that would provide better separation but not sure if that is makes things significantly easier or harder for implementing this new function?

We would use this function extensively, so I'm happy to devote some development time to it once we have an approach agreed. I haven't done a huge amount of development on the core magnolia code, so would need some guidance, but should be able to pick things up quite quickly.

Simon

Comment by Fabrizio Giustina [ 19/Aug/09 ]

All the related issues have been solved. I'll add a page to the wiki explaining the suggested configuration for a multi-website public instance.

Generated at Mon Feb 12 03:33:43 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.