Uploaded image for project: 'Magnolia Site Module'
  1. Magnolia Site Module
  2. MGNLSITE-52

Switching language in preview does not work for variations

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • Neutral
    • 1.0.5
    • None
    • None
    • None
    • Basel 30
    • 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

      Checklists

        Acceptance criteria

        Attachments

          Issue Links

            Activity

              People

                pmundt Philip Mundt
                fgrilli Federico Grilli
                Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  Checklists

                    Bug DoR
                    Task DoD

                    Time Tracking

                      Estimated:
                      Original Estimate - Not Specified
                      Not Specified
                      Remaining:
                      Remaining Estimate - 0d
                      0d
                      Logged:
                      Time Spent - 5h
                      5h