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

    XMLWordPrintable

    Details

    • 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:
      5
    • Magnolia Release:
      4.5.26

      Description

      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?

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                Created:
                Updated:
                Resolved:
                Date of First Response:

                  Time Tracking

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