Not sure if any one else has seen this error yet, but when you link to a document, page or external link and then use Open in New Tab in the Rich Text Editor it generating a 404 error. But if we use the same link and tell it to open in the same tab then it works.
I could see no issue here; this is the intended behavior in Umbraco, consistent with previous versions. When you link to a document using the URL picker, Umbraco saves the link as the document’s ID rather than the full URL. This approach ensures that links remain functional even if the document’s path changes, as Umbraco dynamically resolves the URL based on the document ID.
In recent versions, this behavior has changed slightly:
In Umbraco 13 and below: Links are saved using the document’s UDI, resulting in URLs like this:
If you prefer to use a specific URL, you can enter it manually; it will then open that exact URL in a new tab as specified. This setup provides flexibility, allowing you to link within your site’s structure while also supporting custom or external URLs as needed.
Hope this helps! I tested this on the latest version (14). If you encounter any version-specific issues, let me know—I’d be happy to check further.
After looking into the repo, it seems the problem is with the FindLocalLinkIds regex in Umbraco v14. The regex in HtmlLocalLinkParser.cs doesn't seem to work as intended in this version. I confirmed that this issue is specific to v14, as the same function works fine in v15 and earlier in v13.
For those who are encountering similar problems, it looks like v15 has resolved this, but if you're on v14, this might be the root cause of any issues related to local link parsing.
Hope we can get it fixed or someone fixes it on next release.
Umbraco 14 Rich Text Editor Link Error
Hi,
Not sure if any one else has seen this error yet, but when you link to a document, page or external link and then use Open in New Tab in the Rich Text Editor it generating a 404 error. But if we use the same link and tell it to open in the same tab then it works.
Is this a But in Tiny MCE.
Thanks Darren
Same issue here.
Back office redesign seems a little buggy.
I could see no issue here; this is the intended behavior in Umbraco, consistent with previous versions. When you link to a document using the URL picker, Umbraco saves the link as the document’s ID rather than the full URL. This approach ensures that links remain functional even if the document’s path changes, as Umbraco dynamically resolves the URL based on the document ID.
In recent versions, this behavior has changed slightly:
In Umbraco 13 and below: Links are saved using the document’s UDI, resulting in URLs like this:
In Umbraco 14: Links are saved using the document’s GUID, resulting in URLs like this:
In Umbraco 15: Links are saved using the document’s GUID as well but with slight difference, resulting in URLs like this:
If you prefer to use a specific URL, you can enter it manually; it will then open that exact URL in a new tab as specified. This setup provides flexibility, allowing you to link within your site’s structure while also supporting custom or external URLs as needed.
Hope this helps! I tested this on the latest version (14). If you encounter any version-specific issues, let me know—I’d be happy to check further.
This wasn't the previous behavior, it doesn't matter how the link is stored, its how it is rendered on the front end when using the RTE.
Hi Amir,
I couldn't see any issue on frontend as well. What version are you on?
Version 14.3.1, and its only if target blank is set, it even fails if you manually add target="_blank" in the code.
After looking into the repo, it seems the problem is with the FindLocalLinkIds regex in Umbraco v14. The regex in HtmlLocalLinkParser.cs doesn't seem to work as intended in this version. I confirmed that this issue is specific to v14, as the same function works fine in v15 and earlier in v13.
For those who are encountering similar problems, it looks like v15 has resolved this, but if you're on v14, this might be the root cause of any issues related to local link parsing.
Hope we can get it fixed or someone fixes it on next release.
Same version here as well.
is working on a reply...