[MGNLDAM-504] RichTextEditor: DAM image URLs in the rich text editor contain the context path in the created link (and stored text property) Created: 05/Aug/14  Updated: 01/Sep/14  Resolved: 21/Aug/14

Status: Closed
Project: Magnolia DAM Module
Component/s: DAM Core
Affects Version/s: 2.0
Fix Version/s: 2.0.3

Type: Bug Priority: Blocker
Reporter: Christian Ringele Assignee: Eric Hechinger
Resolution: Fixed Votes: 1
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File RichTextImage-Author.jpg     JPEG File RichTextImage-Public.jpg    
Issue Links:
causality
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   

When enabling the 'images' property on a RichTextFieldDefinition the resolved link/URL contains the context path.
Also a link to a dam image shows the same problem.

So when activating the content (or changing the context path afterwards) the image is not found.
See the print screens RichTextImage-Author.jpg and RichTextImage-Public.jpg
The image didn't show up on the public (attention as long the magnoliaAuthor is running the image is on the public is resolved by the author). I changed both context paths and the behavior was as expected: on both the image and the link was wrong.

If I'm not mistaken, in the former FckEditor the URL was also stored in in the text's property, but the uuid itself was then used for the url creation.



 Comments   
Comment by Moritz Siuts [ 15/Aug/14 ]

We have a project with the same issue.

As far as we have debugged we see that the conversation between the UUID format in the model and the presentation-format does not work properly. It fails with a swallowed LinkException and we can see this in the logs:

2014-08-15 11:35:23,026 [http-nio-8080-exec-3] DEBUG info.magnolia.link.LinkUtil  - can't parse link
info.magnolia.link.LinkException: can't find node /jcr:f6f34399-7182-4b4c-803e-8ff7c56042a8/mario_real in repository dam
	at info.magnolia.link.LinkUtil.createLinkInstance(LinkUtil.java:564)
	at info.magnolia.link.LinkUtil.parseLink(LinkUtil.java:649)
	at info.magnolia.link.LinkUtil.convertAbsoluteLinksToUUIDs(LinkUtil.java:149)
	at info.magnolia.dam.app.ui.field.factory.AssetsEnabledRichTextFieldFactory$2.convertToModel(AssetsEnabledRichTextFieldFactory.java:111)
	at info.magnolia.dam.app.ui.field.factory.AssetsEnabledRichTextFieldFactory$2.convertToModel(AssetsEnabledRichTextFieldFactory.java:108)
	at com.vaadin.data.util.converter.ConverterUtil.convertToModel(ConverterUtil.java:156)
	at com.vaadin.ui.AbstractField.convertToModel(AbstractField.java:745)
	at com.vaadin.ui.AbstractField.convertToModel(AbstractField.java:725)
	at com.vaadin.ui.AbstractField.setValue(AbstractField.java:468)
	at org.vaadin.openesignforms.ckeditor.CKEditorTextField.changeVariables(CKEditorTextField.java:164)
	at info.magnolia.ui.vaadin.richtext.MagnoliaRichTextField.changeVariables(MagnoliaRichTextField.java:80)
	at com.vaadin.server.communication.ServerRpcHandler.changeVariables(ServerRpcHandler.java:403)
	at com.vaadin.server.communication.ServerRpcHandler.handleBurst(ServerRpcHandler.java:228)
	at com.vaadin.server.communication.ServerRpcHandler.handleRpc(ServerRpcHandler.java:111)
	at com.vaadin.server.communication.UidlRequestHandler.synchronizedHandleRequest(UidlRequestHandler.java:91)

But actually we can not reproduce the issue on the demo-project if we download the current (5.3.2) version, but in our project (with Blossom) it fails.

Are you sure you have the issue with 5.2.x? Because we are under the impression that the issue is caused by the new DAM 2.x.

Comment by Eric Hechinger [ 16/Aug/14 ]

You're right... this issue was introduce by DAM 2.x.

Generated at Mon Feb 12 05:00:30 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.