[MGNLETK-28] multi-site support: fixing various issues in the new Created: 12/May/10  Updated: 10/Sep/21  Resolved: 26/May/10

Status: Closed
Project: Extended Templating Kit (closed)
Component/s: None
Affects Version/s: 1.3
Fix Version/s: 1.3.1

Type: Bug Priority: Blocker
Reporter: Philipp Bärfuss Assignee: Jan Haderka
Resolution: Fixed Votes: 0
Labels: multisite
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File multi-site.patch    
Issue Links:
Relates
relates to MAGNOLIA-6626 Generated links do not have always th... Closed
relates to MULTISITE-109 Incorrect i18n links with subsites Closed
causality
caused by MAGNOLIA-3212 NodeDataModelFactory forcing arbitrar... Closed
caused by MAGNOLIA-3213 MagnoliaTemplatingUtilities do not su... Closed
is causing MGNLETK-60 replace usage of the Java 6 method St... Closed
relation
is related to MAGNOLIA-3204 aggregation state loses all informati... Closed
is related to MGNLETK-21 in admin central the wrong templates ... Closed
is related to MGNLETK-27 Multi site support and virtualURIMapp... Closed
Template:
Patch included:
Yes
Acceptance criteria:
Empty

 Description   

The multi site support, mainly the detection of the site, must be improved.

Use Cases

This is not trivial as we have to support various scenarios:

1) authoring without domain

  • detection must work without the domains
  • if done by the path the solution conflicts with the i18n support
  • add a site parameter: currently done by /sitename/shortURI links

2) i18n

  • links might be using the i18n pattern: /de/mypage
  • a simple path matching does not work
  • multi site filter has to be in front of the i18n filter as the site defines the i18n configuration

3) cross site links

  • public: use the domain on public sites if defined
  • author: use /sitename/shortURI link

4) subsites

  • one can map sites to subpathes
  • /section -> /mysite/section

5) virtual uri mappings

6) no domain

  • sites don't necessarily have a domain definition
  • respect that, this sites can always match

7) sitename and site-root name can be the same

  • don't remove the site-root name if it looks like being the sitename

Different ways a page can be accessed (should we reduce that? probably not)

  • full path (for instance if opened in the website tree)
  • /sitename/shortURI
  • domain/shortURI

Solution/Ideas

  • write all essential test cases
  • use best match strategy
    • domain
    • site
    • mapping
  • extract a clean URI method
    • either in the filter or in the sitemanager by introducing a return value object in getAssignedSite(domain, uri)
  • tree opens the page by using the link transformer (no conflict with other links)
    • but might not be possible with the current tree
  • combine mutlisite detection and i18n detection
    • I don't like this because this just hides the problem and other dynamic link generation might cause the same issue

The relevant Classes:

  • info.magnolia.module.extendedtemplatingkit.filters.MultiSiteFilter
  • info.magnolia.module.extendedtemplatingkit.ETKLinkTransformerManager
  • info.magnolia.module.extendedtemplatingkit.sites.ETKSiteManager


 Comments   
Comment by Philipp Bärfuss [ 12/May/10 ]

Attached a work in progress patch to allow others to jump in.

Generated at Mon Feb 12 01:47:48 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.