Uploaded image for project: 'Magnolia Multisite Module'
  1. Magnolia Multisite Module

Multisite behavior: Site definition detection in MultiSiteManager does not cover all "corner" cases



    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.0, 1.1
    • Fix Version/s: 1.0.5, 1.1.1
    • Labels:


      Situation (from SUPPORT-3270):
      Two sites & two site definitions, here in this ticket named site "a" and site "b" with site definition name "a" & "b".
      Both have a domain mapping:

      • a -> www.test1.ch
      • b -> www.test2.ch

      Use case:
      Site /a needs a sub page with the same name as site b: /a/b
      So this uri "www.test1.ch/b" should render the page "/a/b"

      The problem:
      The system will always serve the site b (node /b) instead of /a/b.
      So it does a cross site access instead of rendering the sub page.

      1. First it seems the system serves the site b because the site definition b maps to the site b. But it seems that the system always uses the site definition name if it matches and not even its mapping. One can change the mapping of site definition b pointing to site c: www.test1.ch/b will now serve site c!

      2. As the system can not access at this state JCR to determine the site definitions it can only operate on on the site definition configurations them selves. Therefore the system detect a site definition which seems to serve this site (b site is assumed) and can not check if a actual sub page exists.

      Proof & workaround:
      Rename the site definition from b to "bbb" but leave it mapped to site /b. (and remove the two workaround site definitions)
      Now www.test1.ch/b really serves the page /a/b.

      Drawback of workaround:
      Accessing the site b not vie its mapped domain internal links use the site definition's name and not its mapping value. The link & uri to the page /b/d is then "/bbb/d" which leads to the wrong assumption (and URL) that the root node is names bbb.

      Wrong behavior:
      1. One could argue that this behavior is correct, when there is no domain mapping in place. But when a domain mapping is detected, a request domain/page should always stay in its scope and not do a cross site access. If the domain/page does not exist, a 404 is correct out of my view, and not a cross site access.

      2. Not the site definition's name should be used for the link creation (not resulting in "/bbb/d" paths) but its inner value of the mapped handle.
      If you have more than one site definition mapped to the same site, one can't anyhow name them both identical to the site's root node. So this effect will show in at least one of the two used site definitions.

      Reproduce & test:
      Just import the bootstrap files I attached, and change the hosts file to point the two domains to local host.


        1. config.modules.extended-templating-kit.config.sites.a.xml
          15 kB
          Jan Haderka
        2. config.modules.extended-templating-kit.config.sites.b.xml
          15 kB
          Jan Haderka
        3. config.modules.extended-templating-kit.config.sites.workaround-a.xml
          5 kB
          Jan Haderka
        4. config.modules.extended-templating-kit.config.sites.workaround-b.xml
          5 kB
          Jan Haderka
        5. config.modules.multisite.config.rules.xml
          41 kB
          Philip Mundt
        6. config.modules.multisite.config.sites.a.xml
          12 kB
          Philip Mundt
        7. config.modules.multisite.config.sites.b.xml
          12 kB
          Philip Mundt
        8. SiteDefinition-NamedDifferentThanTheMapping.jpg
          121 kB
          Jan Haderka
        9. SiteDefinition-NamedDifferentThanTheMapping-Drawback.jpg
          125 kB
          Jan Haderka
        10. SiteDefinition-NamedDifferentThanTheMapping-Result.jpg
          114 kB
          Jan Haderka
        11. website.a.xml
          46 kB
          Jan Haderka
        12. website.b.xml
          36 kB
          Jan Haderka
        13. website.c.xml
          5 kB
          Jan Haderka

          Issue Links



              pmundt Philip Mundt
              cringele Christian Ringele
              0 Vote for this issue
              3 Start watching this issue


                Date of First Response: