[MGNLPN-224] Getting the siteRoot from a variant page fails Created: 10/Jul/15  Updated: 15/Apr/16  Resolved: 13/Jul/15

Status: Closed
Project: Magnolia Personalization
Component/s: None
Affects Version/s: 1.2
Fix Version/s: 1.2.1

Type: Bug Priority: Neutral
Reporter: Espen Jervidalo Assignee: Espen Jervidalo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1d 7h
Time Spent: Not Specified
Original Estimate: 1d 7h

Issue Links:
causality
is causing MGNLDEMO-79 Navigation broken on page variants Closed
is causing MGNLPN-226 STK's navigation doesn't show variant... Closed
is causing MAGNOLIA-6297 re-fix site root resolution after spl... Closed
dependency
is depended upon by MGNLDEMO-78 Hardcoded link about page breaks rend... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Sprint: Sprint 2 (Basel)
Story Points: 5

 Description   

Given a page structure like this:

  • home (template-type ‘home’)
    • variants
      • variant-0
      • variant-1
    • bla-feature (template-type ‘feature’)

using any templating functions like cmsfn.page(content) or cmsfn.siteRoot(content) on one of the variants will return the variant and not the actual ‘home’-page.
So when you e.g. want to find a page with template-type ‘feature’ it won’t start searching from the actual site-root ‘home’ but from the variant and therefor fail.

info.magnolia.templating.functions.TemplatingFunctions#contentListByTemplateType(..., siteRoot, ..)
info.magnolia.rendering.template.type.TemplateTypeHelper#getContentListByTemplateIds

The path returned here is /home/variants/variant-0 because of info.magnolia.personalization.decoration.PersonalizationNodeWrapper#getPath returning the path of the wrapped node and not the original.

#getPath returns the path to variant on purpose because it’s the only way to differentiate whether we’re dealing with a variant and changing it would probably need significant changes to the page editor. OTOH it seems a bit misleading as other overridden methods do take the original node into account.

We worked around this problem in MGNLDEMO-79 but for fixing e.g. MGNLDEMO-78 we would again have to work around this issue.

Proposed fix:
One proposal which works and is committed to branch is to have p13n replace and override the TemplatingFunctions by a variant-aware one, which overrides the affected functions, in this case #page(content) will make sure we get the page and not the variant.

Problem: It’s an easy fix, but there might be customers already replacing the TemplatingFunctions. Besides that what do you expect when you call #page(content)? The page or the variant of the page?



 Comments   
Comment by Jan Haderka [ 10/Jul/15 ]

After discussion between Greg and myself: We will proceed with proposed solution already implemented on the branch and come with more flexible and permanent fix in frame of Magnolia 5.5, facilitated by split of core. See related issues for more details.

Generated at Mon Feb 12 06:35:32 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.