Quote:

The confusion ist certainly not a carefully planned behaviour but a cheksum of carelessness and adamont behaviour of the CORE developers in an irresponsible way.

For about more than half a year, the Core developers did not care about leading the XOOPS community in the right way forcing everyone to wait until the Fundamentals are re-designed. That has lapsed about 8 Months of time. Now people met in Paris to exchange while the entire community of XOOPS + other CMS community is watching the move.

The declaration of a meeting in Paris won't help users like like you or me, who like and love XOOPS but are constantly confronted with versions, versions conflicts and modules being unusable!

More of an intelligent Joke.

Well, 2.2.3 > 2.2.4 was a simple and small upgrade patch. I am not aware if this is already in the full version of 2.2.3 now officially available.

Quote:

You are welcome. However if it would be for legal reasons, I would take a complete distance to all possible common cross points. Law DOES NOT recognise the rights of an Admin to be lazy (I love those rights as well), regardless of any Hacks or possibilities.

@Jan!

Hallo Captain! Thanks for coming out of the Submarine of Xoosphere and placing anathor Hack idea!!! That generates a new possibilitiy and its really great to know. I really like the multisite module very much... except for the de-installation possibilities available in each websites that did create nightmares...

Just to remind you of a feature request regarding a multisite possibiulity I placed sometime ago is here:

My user name: xoops_gold
Click here
Thanks for your contribution everywhere.

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.

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?

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!!!

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...

Hallo!

No!

The module works only with one database. Within the same database, it is possible to generate or clone tables that will store information regarding different websites.

It will then depend on what information you may want to be cloned. Hence you need to create a master database, feed all the information into the tables and then clone them.

The Multisite module is a trigger to differenciate different websites based on the same installation within a database.
Quote:

Why do you need databaseS? To have many websites, you do not need more than one database. The Multi-website module will recognise from the URLhttp://www.Domain1.com andhttp://www.Domain2.com and will offer information with their respective tables withiin ONE Single database. Am I making things clear?

Or do you already have databases and you need to wmerge all of them. If so, you may require a total different approach. But then you need to tell us more for a better suppport.

Quote:

Yes, as a User I certify that the Multisite works WITHOUT any problem with 2.2.4! The only stupid thing in the 2.2.4 is that the extended profiles module will not offer any Group function in the Admin to transfer users from one to anathor. The permission features remains untouched. It is only the form that stops working.

I sincerly beleive that this is a bug of a very low degree and should be absolutely easy to remove. However, since I have been the only one to speak about it, the core developers have shown adamont behaviour not to listen and iron the bug.

There are also serious reasons behind it. The software is ofcourse affered for free as open source. Also the core developers are heavily interested to really bringout a new version of 2.3. So the time available is mostely invested in the new version, which is perfectly understandable!

Hence, I warn you about using the 2.2.4 at all! If the custom fields are more than about 25 extra fields then the module shows strange behaviour!!! Be warned and do not cry later afterwards. However, this has nothing to do with Multisites.
Quote:
You seem to miss the understanding of the Multisites Module. This tiny little module has gigantic potential, ridiculous enough. Once you start using it, you shall realise how clever people are hanging around in the CORE development and will beginn to appreciate.

However you may have to undergo an extra-ordinary pain of frustration in configuring, - if you did not follow the basics - out of the very very little and superficial documentation out there. The great Hero "Mitrandir" has developed this great "Star" Module and did not write very much of documentation or atleast a very confusing documention for beginners.

Hence, I would offer to help you out for very basic questions witth a hope to substitute his or others time, as I did undergo or was forced to undergo the pains and frustrations arising out of it, which seems to be also programmed unknowingly and unintentionally! They shall imediately vanish the moment things start working and you will appreciate it for a very long time, which is the only thing programmed intentionally.

I write this hoping that Jan reads my message and works on a better module + docs!!!

Hallo kiranshotgun!

On the website there does not seem to be any solution in relation to the problem discussed but looks like more of an advertisement.

Hence your post should be deleted.

Hallo!

It was a bit of work to findout about upgrading possibilities to 4.1 mysql, after which I gave up!

I tried to use the patch you supplied in the comments for earlier versions but had no success!

Any more solutions?