[MGNLDAM-535] Changing internal link after initial editing does not open tree browser - when using custom config.js file or images property is set to true Created: 27/Oct/14  Updated: 01/Jul/15  Resolved: 14/Jan/15

Status: Closed
Project: Magnolia DAM Module
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.7

Type: Bug Priority: Neutral
Reporter: Diana Racho Assignee: Evzen Fochr
Resolution: Fixed Votes: 2
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File dam_link.jpg    
Issue Links:
dependency
is depended upon by MGNLUI-3294 Links to magnolia pages created from ... Closed
relation
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 using custom config.js file to modify ck editor and you change internal link which was created with Magnolia link buttons the standard link dialog will be opened and not the Magnolia tree browser.

Also the Magnolia link buttons are disabled when this link is selected.

For further information see: MGNLUI-2727, SUPPORT-3976



 Comments   
Comment by Jaroslav Simak [ 27/Oct/14 ]

Moved from MGNLCKEDIT project (which is a forge module that adds ckeditor to Magnolia 4.5 branch) to the Magnolia UI project.

Comment by Mikaël Geljić [ 13/Jan/15 ]

This issue can also be reproduced when configuring images to true. To reproduce:
1. set images to true on stk's generic text field; e.g. on public demo
2. issue can then be observed when editing textImage component at /demo-project/about/subsection-articles/article

Basic explanation:

  • Setting images to true results in registering/loading the "magnoliaFileBrowser" plugin to the CKEditor
  • This also happens whenever one uses a custom config.js; so that one can enable it (add it to config.extraPlugins) in the JS file.

As far as I know, the "magnoliaFileBrowser" is merely a patched duplicate of CKEditor's original "filebrowser" plugin. Sometimes with Christian we've noticed a "double-repainting" issue when we close the choose-dialog (e.g. after link to pages/assets, or adding an asset directly into the text body). Things generally keep working 'ok' but there are obviously some glitches, like the one mentioned here.

We need to review our patched filebrowser plugin and make sure it does not interfere with default CKEditor behavior.

Comment by Mikaël Geljić [ 19/Jan/15 ]

Nice catch @Evzen

Indeed we set the Vaadin converter in the exact same conditions, which would also turn link hrefs to absolute — while the magnolialink plugin does not support these absolute links (requires the UUID fashion).

As a side note, transforming these links was not completely wrong, this used to make them clickable from within the CKEditor (e.g. open link target in a background tab). Now they will give a 404 from the editor — but that's at least consistent with whenever the Vaadin converter is not set at all (i.e. when images flag is configured as false).

As a future improvement, it would be nice to do this transformation for links again (all the time), while modifying the magnolialink plugin to preserve the uuid-link in a data- attribute, so that it can keep working with it.

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