[4.0] Revisit Multi-site Design Options, IMPLEMENT SQL VIEWS TECHNOLOGY in the Joomla core as well as implement a Multisite concept based on SQL VIEWS to share same php codebase and master tables in slave sites

[DeRaja]

Is your feature request related to a problem? Please describe.

There is a need by hundred-thousands of Joomla users to have a multisite feature, to share the same codebase and to have different databases per domain or subdomain. In 2011-2012 the core team had organized a Group to check possibilities on multisite. No conclusion was reached. Following is the link on this issue published by the core team:

https://docs.joomla.org/Multi-site_Design_Options

On one side the Joomla website claims two million installations. On the other side, the core team has not reopened the issue of multisite in the last six to seven years. This burning need has not been properly evaluated in context of new technologies developed in the last years.

Some vendors have implemented some basic multisite concept. The component Mightysites implements multisite based on configuration.php. Logically, one cannot have too many variables of multiple slave sites in one configuration.php. On the other hand, JMS2Win implements multisite concept by hacking the core! It forces to have an installation directory and applies patches for each component and the core. SEBLOD organises groups based on ACL and with this demarcation, different views are generated for different sites.

None of these solution has substantial value as the extensive one hacks the core and the other, which does not hack, offers a very restrictive function or possibility.

Thus, this issue requires to be urgently revisited.

Describe the solution you'd like

• Creating directory links on a different domain/subdomain that resides on the same server is a very simple thing. Php scripts could create this to share the same php codebase of Joomla installation.

• Now, the MySQL VIEWS technology is highly advanced, is stable and is fully functional. It offers sharing of tables in-between databases without any problems. Further infos are here:

http://www.mysqltutorial.org/mysql-views-tutorial.aspx

• With this VIEWS SHARING TECHNOLOGY, one could share User tables in master on all other slave sites. Likewise, if there are other tables that could be shared, like jos_countries, jos_states and jos_cities, then all slave databases could use the same geo_ids from these master database tables.

• The first installation of Joomla should become the master installation with master database. This will have administrator directory protected by htaccess.

• All other sites will have shared code based i.e. only sharing data of directory links with views connecting to master database as well as slave database tables for slave site specific data.

• Create Global parameters in the Joomla Framework to handle global for slave sites and make available to all components, modules and plug-ins. This requires implementation of "site_id" as a field in the framework.

• In table jos_sites, one could have many global configuration specific to a site, like language, extensions used, modules used, etc. If there is a field in any component "site_id", then it will make queries accordingly and provide global to interface to slave sites, from the shared table jos_sites.

Additional context

The Multi-site Group identified four fundamental strategies to make multisite.

With this concept, all the problems discussed by the Multi-site Group before six years will be addressed because the above solution is not based on a concept like SEBLOD to organise groups per site but creates a field to map it as well as creates a real SQL VIEW for sharing across sites.

In contrast to those four concepts discussed by the Multi-site Group, the concept proposed above addresses a unique combination of these four concept and takes into consideration the SQL VIEWS technology.

Implement a system of 0 for global sharing that field or table for all sites and a different value for a particular site. This means if the value in field of site_id in user group is 0, that group will be shared with all the slave sites. If the value is - for e.g. 7, then it will be mapped to the site_id 7 only. This creates a one-many and many-many relations.

Consequently, one could have different slave sites for different languages or for different subdomains for different categories, which will totally differentiate articles, templates, etc. based on site_id detection.

[B3nito]

That would be perfect y absolutely what is needed !!! Please yes!!!

[mbabker]

The Joomla application is not an Apache and MySQL only application, and Joomla itself is not only installed by system administrators who can make configuration changes based on the web server in use (which may not even be possible on some shared hosts that users choose to deploy sites onto). Therefore, unless your feature requests are cross-database portable (MySQL (and its "drop in replacements" or forks) and PostgreSQL at a minimum) and cross-server portable (Apache, NGINX, and IIS are officially supported platforms; Joomla does run fine on LiteSpeed as well), they cannot be entertained.

Joomla cannot reliably provide an interface to manage web server configuration files (platforms like NGINX don't even have a .htaccess like file, and Apache is default configured in a way where local .htaccess files are not even processed; the administrator must enable this capability for the web space).

Joomla cannot impose a requirement that it have files placed outside the web space. This in effect removes the ability to deploy Joomla as anything other than a root domain installation or prevents use of Joomla on platforms where only the web space is write accessible to the user.

Most of what you have suggested in your issues are things that can be done with extensions or enhancements that can be made by site/server administrators, but are not suitable for the core distribution without imposing major restrictions on the application's capability.

[brianteeman]

You suggest there is a massive need for this by hundreds of thousands of users. Please show where you get this fact from.

[brianteeman]

Sorry but this has to be closed as the concept of your proposal cannot be accepted for the reasons stated above.

[laoneo]

Perhaps some parts of the issue needs to change. But when there is interest in multisite then we should listen. If nothing usefuel comes out then we can close it later. Shutting down an idea an hour later is just a wrong action.

[mbabker]

The multisite stuff needs to be isolated in its own issue away from the rest of the content that is either not feasible given Joomla's distribution model or just not practical (i.e. this concept of shared global tables like jos_countries). It needs to be strictly on that request without any of the other baggage otherwise as is this isn't actionable.

[DeRaja]

Dear Mr. Laoneo,

I am a Linux administrator since 1998. I have seen this domain market growing and have had use of many frameworks, took part on discussions on variety of platforms.

The manner in which how Joomla core was developed in in version 1.5, I had to terminate my project and change over to Xoops, got engaged with xoops coding.

The state of affairs has not much changed today.

After the initial conversation with Mr. Babker and the manner how he as well as Mr. Teeman reacted to my last feature request, I am definite that these people are excellent coders but have a low degree of visions and experience.

It is to me more than laughable on certain expressions by Mr. Babker.

I have no objection if one of these guys closes this feature request. The community deserves them.

I am running multiple sites with multisite solution mentioned above already since many years. I did not care to even report it here, unless someone inspired me to do to.

It is not a big problem for me to make a shell script to have a complete multisite option to share databases but this kinda option is for people like me. Other users may not dare to to do.

Because I run multisite, I know very precisely that it has to have a substantial reference in the Framework and site_id has to have a global reference through controller model mapping.

I have also worked with many other systems, like ProcessWise, or even on Symphony. There exists other CMS like Schlix, SatCMS, Drupal, etc. One of the major work is on Multisite Wordpress.

As mentioned above, I have the least interest with this topic to place anything beyond a simple feature request. It is the fate of Joomla community to have certain - and the most important - feature into or not into the core. Here, I am the last to cry amongst the joomla community.

Shocking was to see the background of Mr. Teeman and his question to me to blatantly ask on the statictics, from where I derived a conclusion on the fact that there is a hugh demand. With that, I told myself that I am having a totally wrong people to communicate with.

Also, it is not common to have these kind of personal discussions with coders, who contribute their valuable time. However, when it comes to contribution of my time, I only feel sorry to have wasted my time totally because the environment here is in the direction or "not visionary" and having less foresight.

Again following expression declares lack of experience and the ability to evaluate a concept:

The multisite stuff needs to be isolated in its own issue away from the rest of the content that is either not feasible given Joomla's distribution model or just not practical (i.e. this concept of shared global tables like jos_countries).

Even to here this, I feel sorry and have practically NO energy to write a counter arguments. Mr. Babker did not or never used this concept and hence needs to talk like this. Totally useless discussion on it.

Why should the team not run a voting series on the main portal website and ask the community to declare by votes, if they want to have this feature integrated in the framework?

[alikon]

why not you starting to propose some code as a RFC or POC for example, this surely give you some boost at your proposal's

[mbabker]

Ignoring all the "I have more experience than you" commentary, I'm not going to waste my time evaluating a proposal that comes with all sorts of baggage. You aren't proposing a multi-site feature with this item, you have here about 5 or 6 different requests that each require individual evaluation for their merits and whose technical implementations would require major architectural changes to the core of the Joomla application and framework, with a particular technical emphasis on a subset of the environments that Joomla is supported for deploying onto (essentially Apache + MySQL only) and if implemented exactly as you suggested would reposition Joomla as a platform that is only suitable for developers and system administrators to build and manage websites upon, completely ignoring what is arguably the biggest contributor base to this volunteer community or the bulk of the existing consumers of our software.

[brianteeman]

which is why i closed it

[DeRaja]

Which is why I consider both of you to be wrong people here to evaluate this topic, which was left half the way by the Multisite group in 2011, and handle this matter any further.

Both are only interested in a choice of feature request of your choices and not that of a community, which is a shame. For both of you, it is most important to become opponents to such a feature, and that may not have anything to do with myself in person, is to close it with lightening speed, right?

Both of you should at least learn that there may be others, who may want to bring out their input and contribute to such a feature, or pour their intelligence in some form. But that does not somehow suit your personal ego, which defines which feature request could remain for a few days and weeks in the discussion.

And that's a shame to handle such an important feature request, by closing it at a lightening speed.

[alikon]

@ArchitektBerlin wanting a feature is not the same thing as doing something concrete that helps things happens, if you have some hidden developers, that have this goal in their mind, and they have quite suffcient free time to develop it , I really again ask to you , please post some RFC or some POC

[alikon]

nice to have for me, as it is now, not more not less

[roland-d]

I am going to close this because feature discussion can take place at the appropriate channel in the Google Groups CMS Development.

If there is code to discuss, please create a pull request with code so we can discuss the code and feature it holds. As requested by @alikon, feel free to post a POC.

[brianteeman]

I stand by my earlier comment questioning if there really is a demand for this by anyone other than yourself