Uploaded image for project: 'Magnolia'
  1. Magnolia
  2. MAGNOLIA-6243

Inline rich text links don't work on public instances when using custom URL mappings


    • Type: Bug
    • Status: Closed
    • Priority: Neutral
    • Resolution: Fixed
    • Affects Version/s: 4.5.24
    • Fix Version/s: 4.5.26
    • Component/s: fckeditor
    • Labels:
    • Sprint:
      Kromeriz 11
    • Story Points:
    • Magnolia Release:


      We have modified Magnolia's multisite request matcher rules to avoid pages being available on multiple URI's, and to avoid all sites being available on all domains through their prefix. We did this by moving config:/modules/extended-templating-kit/config/rules/uri-starts-with-sitename below its handle-not-empty sibling.

      Afterwards we found that all of our inline rich text links were broken, because the link URI's are generated (by RepositoryBrowserPage#resolveAbsoluteURI()) and stored in the rich text HTML when the link is created, while assuming the default mappings apply on public instances, which is not necessarily the case.

      An example from our setup:

      1. Add a TextImage component to a page.
      2. Type some text into the rich text editor, select a word to link and click the Insert/Edit Link button.
      3. Click the Browse Server button and select a page from the website tree, e.g. /site/path/to/page
      4. The code in RepositoryBrowserPage generates /site/path/to/page.html as the absolute URI, which gets stored in the text property of the TextImage component.
      5. Activate the page and request the page on a public instance.
      6. The inline link points to /site/path/to/page.html (as expected, because that's what was stored in the rich text HTML), but this is not a valid URI on our public instance. In this case it should be /path/to/page.html, as /site is the handlePrefix of this site.

      An idea might be to have this work like the internal teaser, storing a target UUID and generating the link at render time instead of creation time.

      Also, we noticed that magnolia-module-fckeditor no longer exists in Magnolia 5, but this mechanism might have been carried over to the new rich text editor? Or is Magnolia 5 handling this differently?


          Issue Links



              • Assignee:
                efochr Evzen Fochr
                breun Nils Breunese
              • Votes:
                0 Vote for this issue
                3 Start watching this issue


                • Created:
                  Date of First Response:

                  Time Tracking

                  Original Estimate - Not Specified
                  Not Specified
                  Remaining Estimate - 0d
                  Time Spent - 1d 7h
                  1d 7h