Issue: Multisite support

I'm now running multisite on my dev install. It should be fairly easy to add support for this. Mostly its a matter of letting XCMS filter nodes per domain.
Please contact XCentral to see what can be done.
http://xenforo.com/community/members/xcentral.15723/
https://desk.xencentral.com/index.php?/Tickets/Submit

I think VaultWiki might also need a hook location in the method that handles URL canonicalization. Otherwise, there is not currently a way to filter cached URLs based on domain. On top of that, the URL builder caches the base URL statically once per page request, so every wiki link on a given page or in a sitemap would currently have the same domain base. Without completely rewriting this, it would then be up to the receiving index.php?wiki/ script to decide whether the request needs to be redirected to a different domain.

Basically, a perfect solution would require that any multi-site integration would need some form of native support by VaultWiki to handle multiple domains. This is something we moved away from in VaultWiki 4, because no one ever used the tools for it that were in VaultWiki 3. To rebuild that kind of support natively again is something that will now have to wait until 4.1 or later.

xenforo multisite is pretty popular. Multisite installs in general are nowadays. I think you were ahead of the times implementing it in VW3, but now its certainly popular. For me its crucial, because my new spinoff site is based on addiction help articles.

It might be simple enough to add an Area setting for a custom Wiki Base URL, and that could be used to change the domain used by that area and wiki pages within it. In that case, VaultWiki would require relatively minor changes in order to convert and canonicalize URLs within that area. However, cross-site logins, style changes, and other domain configuration would for now need to be handled by a third-party system, like the XenCentral mod.

Re-opening this related issue, as many of the parts discussed in the OP were never completed: https://www.vaultwiki.org/issues/2007/

Since I was working on routing today, I wanted to add that this could simplify the problem with XenForo non-Friendly URLs + VaultWiki Friendly URLs. This combination has major bugs that we have been trying to fix, but doing so has been problematic from a coding perspective, especially when Name of the Wiki Route is blank and there are articles with custom paths imported from VW3 (or would have custom paths in the future from the other request I linked above).

We avoid the problem of two-way conversion of routing for these unusually formed URLs by implementing a multi-site feature as follows:
- Remove the Wiki Base URL setting and the Name of the Wiki Route setting
- Create a new Structures admin panel for URL Paths, where admin-defined paths (base-path + wiki-route) are defined in pairs and have unique IDs.
- All wiki content uses one of the base_path_id defined in the new panel. The base-path part of the pair is used as the front half of the URL. If a split is needed due to a weird setting configuration, the split occurs between the base-path and the wiki-route. Rather than the current system that splits and stores the entire URL, the route for a given wiki page is stored beginning with the portion after the wiki-route as defined by its base_path_id.
- Lookups based on the route compare all known base-paths against the left-most part of the route. Next, after removing the split (if applicable), if the paired wiki-route for the found base-path matches, we know the rest is a wiki path. If a split was expected but did not occur, and the next part of the path is the expected wiki-route, we assume that it was the friendly-form and will probably forward to the canonical hybrid path. Beyond the wiki-route, the rest of the path is looked up in the normal way. If the wiki content matching the remaining path has a different base-path+wiki-route combination than we requested, route the request anyway and forward the user to the correct base-path.

A multi-site integration by XenCentral would then only need to provide the admin with a chooser for which wiki area to use as the starting point on each site. XenCentral would simply replace the URL that appears in the navbar with the wiki area URL in order to achieve this. However, this will require the wiki's caching system to add a customizable value to its hash, so that the correct navbar for each site is cached. That is a simple change. XenCentral would have to insert a unique value for its sites (like a site_id) into this hashing function.

To make each site seem more separate, search functions and auto-links could have an option to only search certain base_path_ids. XenCentral could force certain selections for its sites by modifying the wiki's search form.

However, because routing is base-path agnostic, other functions, such as special pages, wiki links, and naming restrictions, would still function on an inter-site basis. A node's content list must still show all of its contents, even if the contents were saved under a different base-path. To prevent something like inter-site categories, a category-level setting would be added saying that only certain base_path_ids can be added to that category. This can be set by default based on the settings of the area that contains the category. Of course, this would apply to books, feeds, etc as well.

"Implemented" in 4.2.x. In 4.2.x, we no longer use one Wiki Base URL for everything. There is a new admin Structures page which allows you to define any domain/path/route combination you want, and assign these to various pages (with defaults per area).

This should play nicely with XenCentral. For "different wiki indexes" per domain, set various wiki pages so that their URL looks like an index (preferably use areas for this). Then clone a custom XenForo navigation tab for each domain's wiki, and link the root tab directly to the appropriate area/wiki page which is the index for that domain.

Hopefully XenForo will implement multisite support at some point. Its nice that VW is ready for it.
This suggestion is from 2014. I stopped using XenCentral many years ago after a critical bug rendered the site useless for 3 months and it was clear that you cannot rely on an addon for multisite support.