On my site I just created a news with an idea to improve xoops and use one database for one or more sites.

The need arose for the simple reason of use of the same resources for both the desktop and the mobile site.

The problems presented themselves in different ways, to use different themes is not possible, to use only some modules and not in both spaces is not possible, always with the same configuration and the same database.

In addition, the session and the user no longer be both otherwise you will always show the same site that has set the theme that has been set at that time.

To better understand what I wrote you can translate it with google translate

Having a "multi-site" feature in XOOPS is definitely on top of the list. I was hoping that we would tackle that after having stable 2.6.0 released.

There were few attempts in the past (search for "multisite" on these forums), but my guess is that they were not solid enough to make into the Core.

I hope they can be solid after xoops 2.6.0, because I have spoken of desktop and mobile, but I also have two subdomains for modules and themes, and that's why the problem comes when I need to load all the modules on both the main site and on that of modules, and not to have the error messages that the data modules do not exist.

Same thing with the issues if I were to use a different theme for each site, the setting would be the same for all in a single database. That's why using a single database, you must create a "multi-site" configuration with a unique identifier for each site.

I have considered multisite for a while and I am unfamiliar with how others have attempted it in the past. I have a proposal of doing this by manipulating the prefix which I believe will work with minimal change to the core and minimal if any changes needed to most modules. Modules will work as is if they don't need to be shared and only require modification to a particular method call to identify themselves if they want to support sharing the database across sites. Sites that use high level database calls only may not need any modifications to work as intended.

This will require that the core database fields be separated into sections. A main section that has to be unique to each site and then secondary sections that can be shared across sites such as the user database. I suspect as an example that the user database can be considered a module and be treated as a module even though it is essential to the core and always included either as profile_lite or as a profile compatible module. If that is the only data that can be shared between sites easily then treating it as a module should work fine and no further considerations for core sections need to be made. This could be the initial setup and if we decide to add other core data as sections that can be shared they could be added later. (Pm might be another candidate since it has code in the core and can be replaced with a module.)

An admin menu would need to be added to configure a lookup table and to write it out to the required location. This would allow you to setup what modules use the tables from what site. This lookup table would consist of a list of the modules and any core sections (if any) as the key and the value would be the index for the desired prefix to use. For security purposes this would be written out to a file which would need to be loaded each time. We don't want this stored in the session variable or it could allow injections across sites.

The secure.php file would be modified so that it would use the settings as they exist now for the site and add a list of all available prefixes as an array but would also include a separate prefix file that would contain the default prefix for the desired site and the above mentioned lookup table. The file to include would be based on the URL the site was called from.

How this would work is that the prefix method would be called with an extra parameter added to it that would identify the module (or section) requesting the prefix. The prefix method then would look up the prefix to use and pass this back. If the extra parameter isn't added it will use the default prefix thus allowing for backwards compatibility. This added parameter would be the only thing needed to be added by modules wanting to become multisite compliant. The admin routine would not have a way to know however if the module is compliant so a user could change the database prefix in the lookup table and the module never take advantage of it. Another detection method could be included to determine the object calling it when the added parameter isn't used so that when a module extends the xoopsobject and calls that then the prefix method could determine the object calling it and determine the prefix that way.

Module installation would also need to consider the potential of a multisite installation and allow a user to just link to the already installed tables.
Other considerations would be changes if any needed to themes to make them work and any template issues that come up.

This method would be EXTREMELY flexible. You could have multiple sites using the same code base and each have their own database tables with nothing shared, share just the user base, share EVERYTHING or anything in between.

I CAN look into the potential of this after I get done with the install script assuming my proposal makes sense.

Because 2.5.6 is the current stable version I will do any tests using this code base since it is not likely to change much in the near future.

I also want to do some work on the Groups and permission stuff so it would be a good time to look into this.

Of course as I have mentioned elsewhere anything I do will be done as a hack/patch to 2.5.x to hopefully be included in a future 2.6 core. But I plan to make it fully functional with the current system if I do start working on it as well as the latest version of the 2.6 branch.