-
Bug
-
Resolution: Fixed
-
Neutral
-
5.5.1
-
-
Empty show more show less
-
Saigon 86, Saigon 87, Saigon 88, Saigon 89, Saigon 90
-
5
As Magnolia 5.4.11/5.5.2 restores support for upload fields with i18n. It now appears that the mgnl:resource nodes created with i18n suffix are not properly accounted for.
- First, it appears I18nNodeWrapper no longer delegates #getNode to the I18nContentSupport, as it does for properties, and as it did between 4.5.2 and 4.5.8.
- Once we sort this out, we should ensure link generation gets it right.
Thanks for reporting, tomwespi:
I tested with 2 languages (de/en), created an i18n file upload field, uploaded 2 files (test_de.pdf, test_en.pdf) and created a link to them with cmsfn.link(content.file).
It creates following, wrong link:
/test/main/0/test_de.pdf
/en/test/main/0/test_de.pdfThe files are saved correctly under the node
/test/main/0/file/filename ...
/test/main/0/file_en/filename ...
- relates to
-
MAGNOLIA-4866 Make sure every node and property returned by HTML or I18N wrappers are wrapped
- Closed
-
MAGNOLIA-4031 i18n: doesn't work for binaries which are actually subnodes
- Closed
-
MGNLUI-3602 info.magnolia.dam.app.ui.field.definition.DamUploadFieldDefinition is not i18n aware
- Closed