[MURLTRANS-2] Module doesn't work for page variants Created: 18/Jan/18 Updated: 17/Jul/19 Resolved: 27/Jul/18 |
|
| Status: | Closed |
| Project: | URL Translation |
| Component/s: | None |
| Affects Version/s: | 5.6 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Neutral |
| Reporter: | Ervin Vystup | Assignee: | Richard Gange |
| Resolution: | Won't Do | Votes: | 1 |
| Labels: | i18n, incubator | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||
| 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 |
|
Hi, When I use URL Translation module made by Richard Gange (from old urltrans module), it doesn't work for translated variants. Problem is a query that is used in URLTranslator.java, which expects node to be [mgnl:page]. When you have path like: page/page/page/variants/variant, it can't find anything. I made workaround of this problem and I'm using [nt:base] as type in this query, but I think that should be fixed properly. |
| Comments |
| Comment by Richard Gange [ 31/Jan/18 ] |
|
I think the fix will be to replace [mgnl:page] with [mgnl:content] based on the nodetypes files from: |
| Comment by Richard Gange [ 09/Apr/18 ] |
|
After some thinking about this issue there are a few problems here. First of all this module was developed before personalization existed. So it does not surprise me we hit the issue now. One workaround would be to try and use component variants over page variants to avoid the problem altogether. I was thinking I could fix the URL Translation module to look at the parent page for it's translations in the case where a variant is requested. This is not a problem. However, there are two things that would also need to be fixed.
So for now I will say this module cannot be used with page variants. I am also going to revert the change I made on the query. |
| Comment by Richard Gange [ 09/Apr/18 ] |
|
One approach does come to mind. We use a special dialog for setting the page translations. It can be triggered via a custom action that is only available for the parent node. |
| Comment by Richard Gange [ 10/Apr/18 ] |
|
I think I may have a solution for this. Rather than control the page names via the page level dialog, instead the approach will be to use the "Rename page" action. This action provides a light dialog that can be i18nized on the jcrName field. |
| Comment by Marvin Kerkhoff [ 24/Jul/18 ] |
|
Hi Rich, this should be easy to fix, but it needs a change in a core class: We just need to wrap a codeline in info.magnolia.ui.dialog.action.SaveDialogAction Wrap line 81 following: if(!NodeUtil.hasMixin(node, "mgnl:variant")){ setNodeName(node, item); } This should exclude all variant nodes from nodename changes. In my opinion this should be a save solution. |
| Comment by Richard Gange [ 24/Jul/18 ] |
|
Hello Marvin- Right, I know what you mean. However, making a change to core to help support an extension is not likely to happen. What I was thinking might be doable is to change the property which holds the translation. The idea was to make that configurable, see
|
| Comment by Marvin Kerkhoff [ 25/Jul/18 ] |
|
Yes this would be also a solution. But in my opinion adding the 2 lines of code into the core will help making the product more stable. Because it's not only this extension that can add a name property to a website. In the end you don't wan't that the node name changes if there is a name attribute, this would be always an issue. |
| Comment by Richard Gange [ 25/Jul/18 ] |
|
Yes I understand. The problem is every bug/code-change has a certain amount of overhead. We only have so much man-power. Therefore we have to prioritize tickets. You are right about the node name. Probably it would have been better to not store the translation under a property called name in the first place. But again, at the time this code was written Personalization was not yet a thing in Magnolia. Anyway, I will try and tackle |
| Comment by Richard Gange [ 27/Jul/18 ] |
|
|