Ah, perhaps I wasn't clear enough..

Yes, I have existing sites, each with their own independent databases and XOOPS installs (see my siggy). My end result would be a shared database for (at least) the users, forums and extended profiles to eliminate the users having to login to each of them with varying usernames and/or passwords.

I believe I'm going to have to try and attempt this in multiple steps:
a) merge the user tables with an integrated "dupe" user check so that the user's statistics can be summed rather than overwritten - perhaps a complex join statement on the users in the case that their username or email addy shows up in multiple databases
b) merge the extended profiles tables using a common format to include any custom fields that may not extend across the different databases
c) combine all the newbb tables into a single database, adjusting userid information so that credit is not lost for posts and the newbb author fields don't lose reference

Ya know, I think I just talked myself out of it.

Hi!

Yes, that certainly extends scope of the discussion making things clear. Well, here I cannot be helpful at all. If you are not a programmer but have some knowledge of playing with scripts then there are some scripts that may help for a start:

Link one

Link two

Well, things you plan is possible but nothing like this is available! NOT IN THE MULTISITE MODULE!

You need a custom script importing each database one by one. The best thing is ofcourse to bring them into one format before begin. However, mind you that there is also a problem in the import which I faced through the import script.

I am going beyond the scope of discussion of this thread, however a few lines. Make sure about the pm_link which was - for me - difficult fo get things going.

1-The popup for pm_link did not show up through the user_profiles.
2- Make sure to check the user_id from the user table rather than letting it like it going into the user_profiles. In certain cases the import did not work well and therefore there were user_id existing but not the profile_ids! Some parts of the scripts within XOOPS uses : if user_id else profile_id, which I found as troublesome!

Hope this helps...

Quote:

Well, one more comment:

Well, then you need to remember to share sessions table.

Logout from master and immediately login into subsite. Then in the preferences, you need to immediately change the sessions_cookie name of the second subsite. (If you love nightmares, then ignore this part!)

Thereafter, things may be working fine with the cookies. All the configuration in preferences and module admin will thereafter start working properly.

In my case, I still need to login each subsite. I did not try to work with auto-login possibilities of having scripts on the same domain.

Different domains have different cookies and require different logins. For your information. This is regardless of XOOPS or multisites module!!!

Pardon me if this is a newbie... Well, I know it will be because I am currently researching CMS packages to replace what I have.

It looks to me like this discussion revolves around the sharing of databases, or portions of, among many sites.

What I am in search of is a common code base install that supports multiple sites (each with its own database) from a single CMS instalation. Is XOOPS capable of this? Or am I missing some key point completely?

Thanks
LS.net

Quote:
To answer you short:

Yes, XOOPS is the one and only one for your purpose. I know however, that there is a multisites module in Mambo that came out before a couple of months. However, if you are fond of problems, use Mambo, an award winning CMS with basic and superficial permission features, without further thinking.

If you wanna have an excellent application control, permission and groups features, simply close your eyes and work with XOOPS with some frustration during the installation phase as a beginner. If you are experienced programmer, things will go forward with a simple click in seconds...

To answer your question more detailed:

You do are missing the understanding of the concept of this lovely and creative multisite module. As I said before, the docs are not good enough or are confusing. Thanks for giving a prrof of it.

Well, Multisite Module works like the following:

1. Install the XOOPS installation in a database
2. Install all the modules required in the (first and only) master database. There will be all tables created.
3. Configure all necessary information everywhere. For instance categories, etc in the modules, session time, notifications, etc, which also takes hours to do it.
4. Install multisites module and generate the first subsite1. It is here you decide which tables you wanna clone, including users table, sessions, news, forum, etc. Hence if you have feed all necessary information in the core preferences and also in the modules, then all those information would be cloned or duplicated under a different name for the new subsite1. By this you simply generate a new site from an existing master database for X number of times as you want!!! Is'nt that GREAT!!!
5. Logout from the master installation and then immediately loggin into the subsite1 domain.
6. Change the sessions name
7. Change or correct all the preferences like templates or first page, etc... in the subsite1 domain.

What has happened above? See here:

The installation of XOOPS remains the same! The database remains the same!!! From the same database and the XOOPS scripts, the multisites module captures the domain name and delivers respective information from the respective tables.

Is that what you are looking for?

I was wondering the same thing about the Multisite module - the single database versus a database for each subsite.

I plan on having 200 community sites all spawned off the master XOOPS website and would prefer each site to have its own database. If I dont share tables between the sites then I would be looking at a database with 200x100 tables = 20,000 tables!!!!

Im not too familiar with how MySQL handles load but which would perform better - 200 separate databases Vs 1 database with tables for 200 sites?? Any MySQL experts out there?

As for the commercial mambo/joomla multisites module developed by ElearningForce DK, it does look pretty slick and powerful to handle the whole creating/managing of subsites. However Ive decided to go with XOOPS to accomplish my project for varied reasons.

Quote:
There are advantages and disadvantages of each system, one or multi-databases. Having multi-databases, you could seperate them due to legal reasons. Well, then it would ofcourse open a new Arena of Server configuration as one needs to connect with the database eachtime seperately.

Here there are also many advantages as then you can have each subsite on different servers. This then opens anathor Arena of problems as the sungle logins would never work due to cookie restrictions! However, exports and imports would be much simpler...
Quote:
Goodluck, my friend, with the gigantic network in your dreams... Well, the number of tables really depends on the choice. If you choose those 100 tables to clone, then you are right. But you could just keep remaining information as common and really make for e.g. news and forum module different for each site. Then you would have less number of tables for cloning. However, modules, blocks, etc system tables could be shared.
Quote:
Each query requires time. Once connected, it would make quries. Hence having all of them in one database, it would make connection and make quries. Having information partially in one database and other in anathor database would have to make too many connections. With the volume of connections that may generate out of your requirements, I doubts that it would work better with too many databases, as the connection would multiply drasticaslly.
Quote:
The quality of group permissions is a very convincing requirement that turns down all other CMS, including to that of module by ElearningForce. If the core do not offer the very basic and the most important feature, every other thing is useless. However, an extra-ordinary patience against frustration by the admin is a challenge that crops up using Xoops, which shall change in a very near future.

However a comment on the ElearningForce module: It simply allows you to duplicate tables and other information. It does not say that it would resolve i.e. the installation would resolve into different websites, which is what XOOPS certainly does! Understand? Hence, I beleive it is a duplication utility/manager rather than a true multisite component, which is what the Genius Mitrandir developed...... Or am I wrong?

There are however some scripts that maintain many CMS with shared database and databases having other information. For instance aMember or other similar such scripts would take care of registration and modification of accounts and will also update all XOOPS installations. Auto-logins will NOT work however, you will have all the features of multi-sites and all excellent features of multisite, which would higly recommended for your requirements.

Deepy, thanks for the indepth response. It answered my initial questions quite well. But, unfortunately, has led to others :).

Quote:

Ive tackled some pretty ugly CMS applications before. xoops, in its basic form, installed without a hitch.

Quote:

This is where I kind of run off the tracks. Maybe a brief list of my requirements will get me straightened out, and help others to understand as well.

First, I must have separate databases for security/privacy reasons. Each day, client databases are dumped, pgp'd and put on an ftp site for client retrieval. As you can imagine, sharing a database would mean all clients would have each others usernames and passwords. Legally, I think this would get me into a mess.

Second, as it currently stands, I have a CMS (which shall remain unamed :) ) codebase installed for EACH client, even though they are all using the same CMS. This leads me to patching each install whenever a security fix is released. This is what I am trying to get away from. I want to patch once, and have it apply to all sites hosted with that particular CMS (hopefully xoops).

Third, I'm a lazy admin. If I didn't admit it, someone would have called me lazy anyway.

So, a single code core install of XOOPS supporting multiple sites with their own, dedicated, databases. Single point to patch. Possible?

Thanks so much for the complete repsonses!

LS.net

Quote:
Much easier than hacks and stuff.

On a Apache/Linux server, you can use symlinks so you would have

/websites/common
with all the files and directories except mainfile.php, templates_c, cache and (perhaps) uploads

and for the subsites, you'd have
/websites/site1
/websites/site2
/websites/site2

that would only have mainfile.php, templates_c, cache and (perhaps) uploads and everything else would symlink to the /websites/common files and directories with the sites themselves being virtual hosts on the webserver.

That way, you would only have one core to maintain, but could use individual databases (and database servers) for the sites. No sharing of database tables would be involved, though.

Quote:

Thanks much for the response! Thats exactly what I am looking for. I assume things like the mainfile.php and templates_c are updated but not as often as other files?

With that, I apologize for hijacking the thread and will let you get back to the Multisite core hack.

Thanks again!!

LS.net