Fix #462: Normalize resolveuid links to avoid portal-prefixed URLs

[anushka-codes1]

Problem

When editing tiles with TinyMCE, internal links can sometimes be saved with portal-prefixed absolute URLs (e.g., /Plone/resolveuid/...) instead of relative paths (e.g., ../resolveuid/...). This causes the resolveuid transform to fail when the viewing site URL differs from the editing URL, resulting in broken links.

As described in #462, this happens when:

1. A user selects text in a rich text editor and adds a link using the link button
2. The first POST saves the link with an absolute URL: /Plone/resolveuid/3c99581261e6479bb0500daea17f57fe
3. When re-editing the same link, it gets saved with a relative URL: ../resolveuid/3c99581261e6479bb0500daea17f57fe

The relative URL is correct, but the initial absolute URL breaks when the Plone site is viewed on a different URL from the editing site.

Solution

This PR adds normalization of resolveuid links before saving tile content. The normalization:

• Converts portal-context prefixed URLs to relative ../resolveuid/...
• Converts full absolute URLs containing resolveuid to relative paths
• Provides a generic fallback for any /sitename/resolveuid/... patterns

The normalization is applied in the Tile.save() method for app/textapp tiles, ensuring consistent relative URLs are stored. This allows the resolveuid transform to work correctly regardless of where the site is accessed.

Changes

• Modified resources/js/mosaic.tile.js:
  • Added URL normalization logic in the save() method before POSTing tile content
  • Normalizes various forms of absolute resolveuid URLs to relative ../resolveuid/ format
  • Stores normalized data as lastSavedData to prevent unnecessary saves

Testing

Manual testing steps:

1. Open Chrome DevTools Network tab
2. Edit a tile and add a link to an internal item
3. Verify the POST body contains ../resolveuid/<uid> instead of /Plone/resolveuid/<uid>
4. Re-edit the same link
5. Verify it continues to save with relative URLs

Fixes #462

[thet]

Thank you for the fix! This is a very welcome improvement - I've seen incorrect resolveuid URLs also. Also very clever cases, which are covered here.

But I think the we always want "../resolveuid" (actually not "resolveuid/", as this would not work if the URL contains a view name). Therefore we can simplify the 3 regexes into one, as suggested in the comment.‌

I see a problem with my suggestion, which is also in the orignial PR: on portal root and not virtual hosted, so e.g. for https://localhost:8080/Plone, a ../resolveuid in the portal root would break.

Note: I haven't tested this!

While we're are at this: Tests would be fine and best practice too. But I don't require them here, as this could delay the PR finalization. Tests can be added later.

Oh, we don't have any mosaic JavaScript tests, so tests are obsolete anyways.

[thet]

@petschki please check this PR also, I'm curious of your opinion.

[petschki]

I've just tried mosaic with master branch and with this PR on a vanilla classic-ui Plone Site. I've tested several scenarios without and with VHM and unfortunately could not reproduce the initial issue where the Plone Site id gets added to the resolveuid link. All my @@edit-tile/plone.app.standardtiles.html POST requests already correctly call ../resolveuid/<UID> without an absolute url.

I think the metioned issue is outdated for Mosaic 3+ as there was a complete ES6 rewrite in the meantime.

[anushka-codes1]

Oh :( Could you kindly recommend any more issues I can work on and contribute? @thet @petschki

[petschki]

Oh :( Could you kindly recommend any more issues I can work on and contribute? @thet @petschki

First of all: thank you very much for your contributions! Highly appreciated 🙌🏼

I'll add a comment to #651 which would be nice to be fixed (I saw your fix in your fork ...)

[anushka-codes1]

@petschki Thank you for your kind words! Will be eagerly waiting for your comment. Looking forward to keep contributing to Plone 😊

[anushka-codes1]

Also, I had raised 2 PRs in ploneorg.theme, a long time ago. All the checks had passed, but no maintainer merged the code. Would be grateful if any of you could kindly check it out.

[petschki]

@thet if OK for you, I will close this without merging since it targets an outdated issue.

[thet]

@petschki Yes, that's ok. I thought I saw these cases regularly, but it's perfectly possible that I've seen this in old tinymce resp. Plone instances. The work isn't lost anyways as GitHub keeps the branch internally alive.