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.