[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: |
|
||||||||||||||||||||||||
| 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:
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. Most likely the bug came in via this ticket: Behavior hypothesis:The system has a matching rule as the 'NotEmptyUriPrefixMatcher' returns true. Reproduce:Generally: Convenient: Test done on bundled versions:Magnolia 5.5.9 works (multisite 1.2.6)
|
| Comments |
| Comment by Christian Ringele [ 31/Jul/18 ] |
|
An additional comment to the configuration Mr Vass has provided in the ticket Speaking of this configuration in 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:
Not finding/expecting a de page: |
| 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 I'd suggest to close this one as a duplicate (in case you have no objections) because we already have 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 ] |
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 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:
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'. I think content apps should react to a system value and not to a specific (or fallback) site definition:
Like this it would also be very easy to understand: 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:
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 |