Multi-site Design Options
This document is a design document for the Multi-site Working Group.
In the Joomla Day New York City in October 2011, a small group met to discuss the possibility of adding some type of multisite capability to the Joomla CMS core. At that meeting, the consensus was that the primary goal for this feature was to allow one set of Joomla programs to run multiple logical sites. Two possible methods of achieving this were discussed as outlined below (in Seblod / ACL Approach and Site Layer Approach).
Then, at J and Beyond in May 2012, another multi-site meeting was held. There, the group came to a different conclusion about what the primary goals of multi-site should be. Instead of sharing one set of Joomla programs across multiple sites, that group decided that sharing data across multiple separate Joomla instances was the top priority.
Each of these approaches is discussed in more detail in this document.
One Set of Programs for Multiple Sites
Seblod / ACL Approach
Sebastien from Seblod displayed their extension that implemented multisite by using the native ACL system. The entire site is divided into sub-sites using ACL groups. Each group only has permissions for a portion of the site. For example, if we have three logical sites, we might have three groups, each of which has ACL permissions for a different set of categories. The Seblod extension adds special UI to make it easier to create the ACL and copy it for new users and groups.
There is also a way to map each site's URL to a logical site and logical site to group.
Missing from this is the ability to separate modules, menu items, and plugins. Seblod has proposed using View Access levels for this. Another approach could be to add ACL permissions for menu items, modules, and plugins. (In other words, add rows in #__assets for these to allow permissions to be set.) This is being worked on independently at present in the feature tracker.
Two variations of this approach are also possible. One would be to add categories to menu items, modules, and plugins. This would allow us to use the ACL for categories to control permissions for these elements.
Site Layer Approach
This approach would add a logical layer called Site that would sit between the Global Configuration and the component options. Each component item (menu item, module, and plugin) and each category would be assigned to one site, a group of sites, or all sites. ACL could be used to control permissions at the site level and these would be inherited in the normal way to categories and components.
Building site into the Joomla core in this way has the following consequences:
- Setting up a simple site is somewhat more complex. You can ignore site but it is another thing to have to learn about.
- It is reasonably easy to set up and manage a small number of sites under one instance of Joomla. Since all sites share the same program folders and database, it is easier to manage than multiple instances and it is easy to share content items. So this approach addresses both the site management and content sharing functions of multisite.
- A major drawback of this approach is that third-party extensions would need to be modified to take advantage of this feature.
- Another major disadvantage of this approach is that all core components would need to be modified.
This approach is to run multiple Joomla databases from one set of shared folders. This could be done with a separate application (for example, based on the platform) that allows the setup of sites. Each site is mapped to a program folder, a media file folder, and a database and prefix. In this setup, the program folder for each site contains only a few files (for example, defines.php, admin/defines.php, and configuration.php). A plugin maps the URL to the appropriate folder for each.
The Site Manager application would handle the installation and update of the Joomla CMS and of all extensions. Extensions would be updated to the shared program folder, but each site would do Discover / Install to actually install the extensions for that site (in the site's database).
This approach does not immediately address the ability to share content items across sites. However, functionality could be added to allow copying content items from one database to others.
This approach has the following characteristics:
- It requires only minor changes to the CMS (for example, the ability to disable the updating of Joomla and extensions and the installation of extensions).
- It does not directly allow for sharing content items across sites, but this could be added to the platform application.
This approach, as implemented by Virtual Domains , allows a single Joomla installation to have multiple domains, each with different Home menu items.
- Unique templates/template styles can be assigned to different menu items to allow for each domain to have a unique look.
- Content sharing between domains is possible.
- User access between domains may be shared, or even segregated with core ACL.
- Only a single point of software updates are necessary.
Focus on Sharing Data, Not Sharing Program Files
At J and Beyond in May 2012, a roadmap session was held on multisite. In this meeting, it was argued that sharing a single instance of the CMS programs was not the most important priority for multisite. The argument was made that managing CMS updates and extensions (installation and updates) is now relatively easy (for example, using a tool like JMonitor to montir the sites and using automatic updates to keep them up to date). It was proposed that sharing data between entirely separate Joomla instances was the most important priority.
Messaging Between Separate Joomla Instances
The proposed solution was to create a separate application or extension that allowed for copying content items from one Joomla database to others in the same family of sites. This could use a restful approach, web services, or some other messaging system to enable this functionality.
Current Status and Next Steps
At present, there is no formal consensus on which approach to take. The Seblod / ACL approach is the only one for which there is presently a coded solution. If the ACL changes are made to modules and plugins, this approach could be available in the short term for version 2.5.
As far as the separate databases and messaging approaches, the next step is to try to develop a consensus about which use case is the most important between: (a) the use case discussed in New York of sharing one set of programs for multiple Joomla instances and (b) the use case of having completely separate Joomla instances share database data via some type of messaging system. Once a consensus is reached on this, then a functional design based on the desired use case can be finalized.