Gatewaying separate vBulletin sites
 

We are interested in finding a way that several independent organizations can each operate its own vBulletin site for their own users - but share certain sub-forums so that if a user on one one site posts to a shared sub-forum, that post will be seen by the users on the other sites and can be responded to from any of the sites.

As an example, think of independent organizations in New York, Chicago and San Francisco, each of which operates a vBulletin system with many sub-forums for local issues but- in addition-each system has a number of shared sub-forums for national issues.

Is there an existing hack or plug-in that would make that possible. If not, do you think it could be done easily?

Initially there would be three sites but more might be added later.

It could be possible, but not without a lot of editing. There are also issues relating to this, such as how users are managed. Imagine 2 users with the name "Dismounted"...

FirstClass has a system that does, out of the box, the kind of gatewaying we want. Servers connect every 15 minutes to update message lists and remote user names are tagged with the system location (e.g. Dismounted,Boston; Dismounted,Chicago; Dismounted,San Francisco, etc).

Although FirstClass can be used with a browser, it's primary use is in settings where each user has proprietary FirstClass client software installed.

We are trying to understand the difficulties we may be getting into if we try to modify vBulletin (which has a simpler browser interface) versus buying an off-the-shelf product.

Would the "lot of editing" be a one-time thing or would each upgrade of vBulletin require a lot of work?

Thanks very much for helping us to understand this.

The editing would need to be done to files that are altered due to an upgrade. You could always keep a record at where the files need to be edited.

For the sort of system you have described above, you could probably get away with using (vbulletin) cron jobs and custom files, so minor version upgrades (i.e. 3.6.x >> 3.6.y) shouldn't need any changes. Major version changes (i.e. 3.6 >> 3.7) may need the jobs checking.