• Register
    • Help

    striker  0 Items
    Currently Supporting
    • Home
    • News
    • Forum
    • Wiki
    • Support
      • Manage Subscriptions
      • FAQ
      • Support For
        • VaultWiki 4.x Series
        • VaultWiki.org Site
    • What's New?
    • Buy Now
    • Manual
    • 
    • Support
    • VaultWiki 4.x Series
    • Feature
    • Multisite support

    1. Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

      VaultWiki allows your existing forum users to collaborate on creating and managing a site's content pages. VaultWiki is a fully-featured and fully-supported wiki solution for vBulletin and XenForo.

      The VaultWiki Team encourages you to join our community of forum administrators and check out VaultWiki for yourself.

    Issue: Multisite support

    • Issue Tools
      • View Changes
    1. issueid=3803 June 16, 2014 4:05 PM
      Alfa1 Alfa1 is offline
      Distinguished Member
      Multisite support

      See: http://xenforo.com/community/threads...em-paid.58618/
      This would allow us to run several instances of VW from the same backend / database. It will result in more license sales because we will VW on multiple domains.
      The thing that it needs to do is show specific areas per domain.
      vbulletin has cerberus which also allows people to run multiple installs.
    Issue Details
    Issue Number 3803
    Issue Type Feature
    Project VaultWiki 4.x Series
    Category URLs / Routing
    Status Implemented
    Priority 8 - Major Features / Enhancements
    Suggested Version 4.0.0 Gamma 6
    Implemented Version (none)
    Milestone VaultWiki 4.2
    Software DependencyXenForo 1.x
    License TypePaid
    Votes for this feature 0
    Votes against this feature 0
    Attachments 0
    Assigned Users (none)
    Tags (none)




    1. July 2, 2014 4:39 PM
      Alfa1 Alfa1 is offline
      Distinguished Member
      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
      Reply Reply  
    2. July 2, 2014 5:36 PM
      pegasus pegasus is offline
      VaultWiki Team
      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.
      Reply Reply  
    3. July 3, 2014 11:10 AM
      Alfa1 Alfa1 is offline
      Distinguished Member
      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.
      Reply Reply  
    4. July 3, 2014 11:50 AM
      pegasus pegasus is offline
      VaultWiki Team
      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.
      Reply Reply  
    5. July 3, 2014 12:04 PM
      pegasus pegasus is offline
      VaultWiki Team
      Re-opening this related issue, as many of the parts discussed in the OP were never completed: https://www.vaultwiki.org/issues/2007/
      Reply Reply  
    6. September 7, 2016 11:33 PM
      pegasus pegasus is offline
      VaultWiki Team
      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.
      Reply Reply  
    7. January 17, 2021 5:31 PM
      pegasus pegasus is offline
      VaultWiki Team
      "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.
      Reply Reply  
    8. January 20, 2021 5:11 PM
      Alfa1 Alfa1 is offline
      Distinguished Member
      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.
      Reply Reply  
    + Reply

    Assigned Users
    Loading Please Wait
    Tags
    Loading Please Wait
    • Contact Us
    • License Agreement
    • Privacy
    • Terms
    • Top
    All times are GMT -4. The time now is 9:13 AM.
    This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Learn more… Accept Remind me later
  • striker
    Powered by vBulletin® Version 4.2.5 Beta 2
    Copyright © 2023 vBulletin Solutions Inc. All rights reserved.
    Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2023 DragonByte Technologies Ltd.
    Copyright © 2008 - 2013 VaultWiki Team, Cracked Egg Studios, LLC.