[MULTISITE-90] Recent changes to NotEmptyUriPrefixMatcher result in: content-i18n page without specific site defintion (using fallback) returns 404 on non-default-locales Created: 31/Jul/18  Updated: 08/Dec/22

Status: Open
Project: Magnolia Multisite Module
Component/s: None
Affects Version/s: 1.2.20, 1.3.1, 1.3.2, 1.3.3, 1.3.4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Christian Ringele Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
caused by MULTISITE-80 URIPrefix doesn't cope with i18n Closed
is causing LIVECOPY-55 404 when changing the language of the... Closed
dependency
relation
is related to MULTISITE-86 Site not matched correctly if page an... 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:

 Description   

Setup / situation:

  • Using fallback site defintion, meaning NO specific site defintion is mapped
  • Content i18n in (fallback) site defintion is enabled -> single tree multi lang is used (dialogs react etc)

Problem description:

A page using "single tree multi lang" content i18n returns for NON-default-locales a 404

Problem source:

The 'NotEmptyUriPrefixMatcher' in the multisite module.
Remove it and it works.

Most likely the bug came in via this ticket: MULTISITE-80

Behavior hypothesis:

The system has a matching rule as the 'NotEmptyUriPrefixMatcher'  returns true.
-> The fallback site defintion is not used (fallback is  used when no matcher rule matches)
-> the i18n configuration enabled=false is used instead of enabled=true
     (i18n enabled=true means -> /de/ is just a flag but not a page, set local and remove it form currentURI
      i18n enabled=false means -> /de/ is a flag and a page, set local and don't remove it form currentUR)
-> the system thinks the /de/ flag is a real page and tries to fetch it -> 404

Reproduce:

Generally:
Create on top level a page which used i18n enabled dialogs.
Add non default content and try to render it -> 404

Convenient:
Copy the page /travel/about/company to top level and switch to de -> 404

Test done on bundled versions:

Magnolia 5.5.9  works (multisite 1.2.6)
5.6.1 works (multisite 1.3.0)
5.5.10 does NOT work (multisite 1.2.20)
5.6.2 does NOT work (multisite 1.3.1)

 



 Comments   
Comment by Christian Ringele [ 31/Jul/18 ]

An additional comment to the configuration Mr Vass has provided in the ticket MULTISITE-87
I'm nor convinced that the MULTISITE-87 is really a bug, it depends a lot on the i18n enabled configuration of his site defintion in use.

Speaking of this configuration in MULTISITE-87:


F.e. travel demo with a multi tree configuration:
[http://travel.demo.magnolia-cms.com|http://travel.demo.magnolia-cms.com/] - this is the english page
[http://travel.demo.magnolia-cms.com/de]  - this is the german page

travel
  domains
    travel-demo
      name - travel.demo.magnolia-cms.com
  mappings
    website
      URIPrefix
      handlePrefix - /travel
      repository - website

travelDE
  domains
    travel-demo
      name - travel.demo.magnolia-cms.com
    mappings
      website
        URIPrefix - /de
        handlePrefix - /travelDE
        repository - website

 

An essential part of the 'travelDE' site defintion for being able to find out if the system behaves correctly or not is the i18n/enabled property of the site defintion.

The correct behavior should be:

Finding/expecting a de page:
travelDE
  i18n
    enabled=false
  domains
    travel-demo
      name - travel.demo.magnolia-cms.com
    mappings
      website
        URIPrefix - /de
        handlePrefix - /travelDE
        repository - website

 

Not finding/expecting a de page:
travelDE
  i18n
    enabled=true
  domains
    travel-demo
      name - travel.demo.magnolia-cms.com
    mappings
      website
        URIPrefix - /de
        handlePrefix - /travelDE
        repository - website

Comment by Jaroslav Simak [ 31/Jul/18 ]

Hi Christian,

i've updated the "caused by" in the ticket description and links, this is caused by the MULTISITE-80 ticket, and this problem is also reported by the MULTISITE-86.

I'd suggest to close this one as a duplicate (in case you have no objections) because we already have MULTISITE-86 in our sprint and are working on a fix.

Btw. thanks a lot for the analysis, it's completely correct.

Comment by Mikaël Geljić [ 31/Jul/18 ]

FYI jsimak I also brought up "the flag idea" to cringele shortly before; he found it redundant with i18n being enabled or not. Are there other examples where knowing if i18n#enabled is true/false is not sufficient to determine the correct behavior?

Comment by Jaroslav Simak [ 31/Jul/18 ]

cringele mgeljic Not really, you can use fallback site with some default i18n settings to be always applied, if no site matches. If i18n#enabled=false on fallback, you wouldn't be able to edit language specific versions in content apps.

I am doing an analysis of the current behavior - https://wiki.magnolia-cms.com/display/~jsimak/MultiSite+and+I18n.

Hopefully it will help us to determine the best solution for the whole multisite / i18n setup.

Comment by Mikaël Geljić [ 02/Aug/18 ]

If i18n#enabled=false on fallback, you wouldn't be able to edit language specific versions in content apps.

cringele this might be why users keep i18n enabled (cf. MGNLUI-3616), despite choosing to go multi-tree.

Comment by Christian Ringele [ 02/Aug/18 ]

jsimak Thanks for the heads up  

Sure, close it if its redundant. I just fear a bit regarding MULTISITE-86:
It has the same root problem, but the title "Site not matched correctly if page and locale are equal" is the exact opposite situation of this ticket (searching for a local page where there is none). So i fear a bit that this test case of this ticket could be forgotten as it would be a different situation to test then the MULTISITE-86 case, even it has the same root cause.

I personally would leave it open until bug is fixed, add this specific test case and then close it. But its your call

 

Regarding the flag:

Not really, you can use fallback site with some default i18n settings to be always applied, if no site matches. If i18n#enabled=false on fallback, you wouldn't be able to edit language specific versions in content apps.

I think here is the main problem a (historically grown) wrong concept of the close coupling of the content apps i18n behavior and the fallback site defintion. Out of my view this is even a 'mini bug'.
-> site definitions are for defining a website's behavior. Also the fallback site definition. That's also why its called SITE definition . One can have various website with various site definitions serving different sets of languages (real multisite and not like the demo), but all of them retrieving content from the same content app (for example assets). So in the end the content app 'assets' would need to provide ALL existing locals defined in all exiting site definition. The close coupling that content apps allow only the locales defined in the 'fallback' definition forces you to define in the 'fallback' ALL possible locals of ALL existing site definitions, which is wrong behavior out of my view.

I think content apps should react to a system value and not to a specific (or fallback) site definition:
For all content apps -> 'config:/server/i18n/authoring/locales'
For the websites -> their site defintion/i18n/locales

 

Like this it would also be very easy to understand:
'config:/server/i18n/authoring/locales' -> defines system wide what content can be entered in content apps (and implicit all websites as total summ)
'specific site defintion/i18n/locales' -> defines for a specific website and implicit overrides for this website the config:/server/i18n/authoring/locales value
'fallback site defintion/i18n/locales' -> defines for all websites not having a specific site defintion and implicit overrides the config:/server/i18n/authoring/locales value

One could define: if the site defintion does not define any locales at all the ''config:/server/i18n/authoring/locales'' is used as fallback value for the authoring locales -> the same for all content apps and websites.

 

By the way:

I'll read trough "https://wiki.magnolia-cms.com/display/~jsimak/MultiSite+and+I18n" and see if I have some inputs.

Comment by Christian Ringele [ 02/Aug/18 ]

mgeljic Regarding:

If i18n#enabled=false on fallback, you wouldn't be able to edit language specific versions in content apps.

cringele this might be why users keep i18n enabled (cf. MGNLUI-3616), despite choosing to go multi-tree.

See my comment above.

Comment by Mikaël Geljić [ 03/Aug/18 ]

Totally agree, see also my comment on MGNLUI-3616 from 2 years ago. After a successful PoC last year, this is entering development now, under the umbrella of Content Types.

Using the fallback site-definition has always been a workaround, despite being a practical solution to customers' requirements. We never intended to depend on that for content apps.

Comment by Christian Ringele [ 09/Aug/18 ]

mgeljic totally agreed  

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