[MGNLSITE-52] Switching language in preview does not work for variations Created: 02/Feb/16  Updated: 19/Feb/16  Resolved: 11/Feb/16

Status: Closed
Project: Magnolia Site Module
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0.5

Type: Bug Priority: Neutral
Reporter: Federico Grilli Assignee: Philip Mundt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0d
Time Spent: 5h
Original Estimate: Not Specified

Attachments: XML File config.modules.multisite.config.sites.travel.variations.xml     XML File config.modules.travel-demo.config.travel.variations.xml    
Issue Links:
causality
relation
is related to MAGNOLIA-6518 BeanMerger attempts to proxy final cl... 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: Basel 30
Story Points: 5

 Description   

When previewing a variation in Pages App the language switching has no effect and in the logs the following stack trace shows up:

016-02-01 18:46:26,421 ERROR info.magnolia.rendering.engine.RenderingFilter    : RepositoryException while reading Resource [/travel/de]
javax.jcr.PathNotFoundException: /travel/de
	at org.apache.jackrabbit.core.ItemManager.getNode(ItemManager.java:577)
	[..]

This was found after fixing MAGNOLIA-6518.

Howto reproduce

In travel-demo

Source of problem

The problem seems to be at info.magnolia.module.site.filters.SiteMergeFilter.doFilter(HttpServletRequest, HttpServletResponse, FilterChain) in the code block starting at line #96, that is if there are variations. The fakeSite (an instance of info.magnolia.module.site.ConfiguredSite) used to merge with variations gets the default info.magnolia.cms.i18n.I18nContentSupport configuration which turns out not to be able to resolve Locale s correctly (only new Locale("en") is set as fallback). This also breaks the currentUri in the aggregationState so that code eventually ends in the path shown above with an actually non existing URI /travel/de hence the failure.

Possible solutions

Inheriting the i18n-settings from the current site

The following snippet in SiteMergerFilter seems to do the trick:

...
final ConfiguredSite fakeSiteWithProperName = (ConfiguredSite) Components.newInstance(clazz);
fakeSiteWithProperName.setName(currentSite.getName());
fakeSiteWithProperName.setI18n(currentSite.getI18n()); // Use the i18n setting from the currentSite
...

Downside: this makes it impossible to set a custom i18n support for a variation (as it would be overwritten).

Move fallback from site to SiteI18nContentSupport

Instead of setting the DefaultI18nContentSupport in the ConfiguredSite we could instead return a new instance of DefaultI18nContentSupport when info.magnolia.module.site.i18n.SiteI18nContentSupport#getI18nContentSupport() encounters an i18n support of null for the current site.

See: https://gist.github.com/anonymous/b989610f7059a29e0229



 Comments   
Comment by Philip Mundt [ 02/Feb/16 ]

Solution indeed works. But

I see a potential problem with it (which might be neglectable though?): when someone specifies custom i18n settings for the variation itself, those will get lost. Setting i18n to null for fakeSiteWithProperName will result in the same problem, as the configured variation itself will get DefaultI18nContentSupport by default.

Unfortunately I couldn't find any details related to variations in documentation (see https://documentation.magnolia-cms.com/display/DOCS/Site+definition).

Comment by Philip Mundt [ 03/Feb/16 ]

Would be good if we could add some nice javadoc to info.magnolia.module.site.Site#getVariations() explaining these limitations.
Even though this is already broken – introduced by delegation mechanism for i18n content support – we should add release notes and documentation.

Generated at Mon Feb 12 07:12:13 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.