I have this hack - based on bd_csmc's work - working fine on a couple of sites, but want to both share it with you and also make it as easy to use as possible.

Hack files

The way to use this is:

1. Setup a XOOPS Site - for your convenience, it should be as empty as possible, as it will be a "template" for all other sites
2. Unzip the files in the archive to the webserver's XOOPS root - NOTE: You will overwrite the mainfile.php, so it might just be easier to download your mainfile.php off the website and change the
define('XOOPS_URL', '...'); to
define('XOOPS_RESCUE_URL', '...');
since that is all that is changed in that file
3. Go to the site's administration
4. Install the "site" module
5. From modules administration, click on the site module link in the installed modules list (sorry, no module badge created yet)
6. Create a new site item, the fields are as follows:
- Site Name : Just an identifier for you
- Site URL : The URL to the site (just like if you were setting XOOPS_URL)
- Theme Path : Where to store themes for this site. Go from the XOOPS_ROOT_PATH WITHOUT a first slash - e.g. "themes" will result in XOOPS_ROOT_PATH."/themes"
- Templates Path : Same, just the templates_c dir
- Uploads Path : If you want separate upload dirs
- Cache Path : If you want separate cache dirs. This is recommended as the cached adminmenu.php files might interfere with each other
[NOTE: ALL these directories must be present - and for the three latter ones, writeable - on the webserver]
- URI Pattern : How this site can be recognized from the accessed URL, WITHOUT http:// in front of it - e.g. http://www.web-udvikling.dk for my site that has the Site URL http://www.web-udvikling.dk
[NOTE: So far it is a little fishy as the detector code will respond equally to http://www.web-udvikling.dk and http://www.web-udvikling.dk/subfolder - depending on the order in which the sites were created. I have not had the need for this as I have either all my sites (including the main site) in subfolders or with different (sub-)domains]
- DB Prefix : Which (unique) database prefix to use for this site
- Shared Tables : Select the tables you want to share with the main/"template" site (and all sites also sharing those tables with the main site)

The non-selected shared tables will be copied to new tables with the specified database prefix.

Now you are ready to setup the first "child" site. The important thing to work out is how to get the webserver to "know" that this is a different site as all the sites should be configured to point to the same physical files.

If you are using subfolders as your URI pattern, you will need to setup ALIAS'es in Apache (or the equivalent in IIS, which I don't know) to point to the XOOPS root even though the browser is asking for a subfolder. This is done quite easily with this line

in your Apache's httpd.conf

I don't know if you can set aliases via .htaccess, but my guess is no since it requires a restart of the webserver service. Again, I don't know the IIS equivalent.

If you are not using subfolders to distinguish between sites, but instead domains or subdomains, you will have to get them configured to all point to the same physical location - I don't know what the name would be for subdomains, but this is what is called a "parked domain" for full domains.

[WARNING]
I don't give any support to crashed sites except trying to improve the code, so don't try this on your production site and expect me to help you get your site back if the hack takes a dump on it.

[ANOTHER WARNING]
You should be careful about which tables you share. Some tables are very tightly intertwined and should either be shared altogether or none of them shared.
For example, it doesn't make sense to share the newblocks table but not the modules table, as the newblocks table has references to the modules table.

Likewise sharing groups_users_link without sharing groups and users tables is gonna cause trouble, but you can share just the users table and define groups and group memberships independently from site to site.

There are many more table dependencies - usually in groups of 3-4 tables that depend on each other, so
DON'T SAY I DIDN'T WARN YOU

[NOTICE]
You do not need to create a site in the "site" module for your main "template" site as that will be the default site if no other site is found to match the URI Pattern

[INFO]
If you want to know exactly what is changed in this hack, read the enclosed Readme.txt

[POSSIBILITIES]
There is a new constant available, XOOPS_SITE_ID, that defaults to zero (for the main site) which can be used in modules to cater for a module that can be shared across multiple sites, but with some content unique to each site - and some content shared between all sites. I'll let you work out the details in how to accomplish this (a "site_id" field in a category table springs to mind as a way to do this)

[MODULE INSTRUCTIONS]
To avoid confusion, you should uninstall the "site" module from the subsite, once the site is created

Module Installation
Not Shared Module:
Install module as normal on the subsite where it should be installed

Shared Module:
1. Install on main site
2. Install on subsite
3. Edit the subsite in the main site's Site Module administration to share the new module's tables

Module Uninstallation
Not Shared module:
Uninstall as normally on the subsite

Shared Module:
1. Edit the subsite in the main site's Site Module administration and set it to not share the module's tables anymore
2. Uninstall on subsite

Thoughts?

Thanks Mithrandir for adding this information on multisites: pending feedback/comments we'// make this an FAQ

Quote:
Some appeared...
1. What about small how-to about joining existing live sites?
2. If you changed DB-related stuff, maybe you can add even more possibilities - use tables from different tables and (sweet dreem) from different hosts (in case of known auth-data for remote database and MySQL accept connnections on TCP-socket)?

Quote:
I would recommend this:
a. Create a new blank database
b. Setup a new main site using the new blank database. This site is only used to setup subsites and install cross-sites modules
c. Backup the database tables from the existing sites
d. Copy modules from existing sites to the new location (only those not already present, of course)
e. Setup subsites in the main site's Site Administration module
f. Import the database tables from the existing sites to the new database with the site-specific prefixes, corresponding to the one input in e. (if all your sites run on different databases with the same db prefix, you should change this in the backed up SQL file with a search and replace)
g. Configure the webserver to point to the physical location

It is a bit more cumbersome moving existing sites to a subsite, but I hope you understand the basics of this hack and what it should look like (database-wise)

Quote:
Not the ones, you mention. I'm hacking the database class to specify the prefix to use, dependant on whether the table is shared or not. I cannot without further hacking change the database from one query to another. This would be a very extensive hack as you get the database through XoopsDatabaseFactory::getDatabaseConnection() or $GLOBALS['xoopsDB'] and it is very hard to see how you can determine which connection object to get back, unless you specify additional parameters.

On the rights of delirium
I think about additional layer (Dispatcher), which
- accept requests from application layer (local and remote) and converts into requests for XoopsDatabaseFactory

db_prefix, db_name, user, pass, host, port is full (?!) and max. set of used for establishing parameters

Quote:
I think about joining user base, and couldn't find good solution
Separate sites have before merging same uid for different users. I can easy search-replace uids from "slave" sites using main site numeration, but it will broke all related to this user data (?!) - news, forum posting...
Can you suggest any (easy or hard...haven't meaning) functional way?!

That is the main obstacle when merging sites. Takes a lot of work and probably a custom script to insert the user from one site into the other site and get a new user ID - and then update all references to that user in the rest of the database... Quite a big work.

However, not sharing any tables between sites still means that you will only have to upload a module or the core once when a new version is out, and it will be there on all sites (you'd still need to update the module on each site, naturally)

Main reason for me in creating site's network is common userbase (single login) and, lesser, sharing some, small part of modules (news and, maybe, forums). Merging users will be AFAIS big headache and I'm happy to have only one site with users and user's activity in future E-City Network... I waited long time and it seems, that now I have live solution for creating network from empty sites. Good

Hi mith ,

I seem to be having a problem just setup a fresh install uploaled the hack files changed the mainfile etc . but when i go to install the "site" module in moduleadmin it not showing as there . all the other modules are tho.

Any ideas .

oz, try changing line 105 of modules/system/admin/modulesadmin/modulesadmin.php (the enclosed one)

currently


change to