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?