Posted on: 2013/5/1 21:33
Re: More than one site with the same database
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.