Hallo all!

I have placed a message in the SF.Net and sincerely beleive that this solution could be helpful. So I thought to place this message in this forum also. The thread (my user name is xoops_gold) is as follows:


I would be really interested to know views of many people that are involved in the development or knows the internals...

--------------MESSAGE---------------------------
I have extensively used the multisite module by Mr. Jan Pederson for about 21 subsites. Through this I saw that it could be really very very difficult to configure all of them. Ofcourse this was just a module that did a perfect job.

However, I think that if some of the fundamental factors in the new development is layed, it would be excellent.

Giving thoughts to this wish, I came to the following idea and wish that it could be implemented:

There are 3 tables that are really controlling everything within XOOPS database. If there was one more field $sitegroup in the exististing database, that would really solve the entire problem.

By doing so, the existing tables of xoops_config, xoops_category and xoops_configoptions an extra dimension to work with that through this the entire database could be used and multiplied. Hence the field $sitegroup would be the main multi-plicator of the entire database. Therefore, it would be necessary to have the first PRIMARY TABLE as the MASTER TABLE known as xoops_sitegroups!!! This table would then be responsible to install one or more sites.

This is the table that would then be responsible during the BOOT SEQUENCE by the kernel of xoops. In this table, some basic information would be stored, like paths and other informations.

During the installation, the installer will only install the primary site and make the access possible. Thereafter it would be possible to get in the administration.

Hence, this follows a theory, that all the other tables that are required should also get the variable fields like xoops_modules, xoops_blocks, xoops_groups, etc.

Also, here in the PRIMARY TABLE as the MASTER TABLE, there could be possibily a field $lang that tells the code of the language givin a multi-language feature.

The only thing which in each and every table that should be refected is the $sitegroup variable! That shall bring a multisite and multi-language feature to the entire database!!!

Does this idea of mine make sense?

Hi!

Well, by doing so there are really many advantages. One of them is:

The table format is instantly available with the compatible version of the module scripts since updating respective tables with their respective scripts are done in one instance reflecting all the subsites! Currently, with the multisite module, the tables would be duplicated inducing a danger that if one subsite is updated with a change in the fieldset of a table and not getting updated in all other subsite instantly!!!

The install.php will be multisite and multi-language sensitive!!! Those information would be stored in the table xoops_sitegroups. So all the calls go through this table.

Hence, with the same installation and the same database it would be possible to install as many websites as possible through install.php. One installs the websites through the install.php and NOT through the admin panel!!!

This would change everything. To have access to generate and multiply real XOOPS websites the first administrator password is not necessary.

There could be NO conflicts within the database tables. Currently, with the multisite module, if I uninstall some shared modules, it will destroy everything as the uninstall is in principlly possible. However this is just a very nice working module, which I like.

Well, thinking on it, I found some more things that could be interesting!

In the SiteGroups table one could have AdminGroups data!

That means the Group permissions could be given to their respective admins from here.

Then in the SiteGroups one can have:

Language=english
RootAdmin=UserXXX Permission 777
Administrator=UserYYY Permission 755
SubAdmin=UserZZZ Permission 700

I am using the numbers with the Unix style system for the purpose of explaination.

The RootAdmins could do everything to all the site, meaning thereby SuperUsers. Administrator could be Site Admins. SubAdmins would then be Module Admins...

And the Editors Permissions could then be within or lower than Module Admins...

Just some thoughts...