Bug #68777
closed
Can't edit external links with htmlarea's Element Browser
0%
Description
Hi,
On some of our sites, the element browser (EB) to edit external links can't be opened successfully in htmlarea.
When we try to edit an external link, the EB opens and loads the webserver's 404 response page. See the attached screenshot (from Chrome, but this happens in all browsers).
I looked at the EB's iframe in the DOM:
<iframe class="content-iframe" src="mod.php?M=rtehtmlarea_wizard_element_browser&moduleToken=644344f98253d4e419018e15ebc7356614697e56&&RTEtsConfigParams=tt_content%3A1237%3Abodytext%3A311%3Atext%3A311%3A&editorNo=data_tt_content__1237__bodytext_&sys_language_content=0&contentTypo3Language=default&curUrl[href]=http%3A%2F%2Fwww.ondaverde.ch%2F&curUrl[target]=_blank&curUrl[class]=external-link-new-window&curUrl[data-htmlarea-external]=1" id="ext-comp-1046" style="height: 488px; width: 536px;"></iframe>
And noticed this part:
curUrl[href]=http%3A%2F%2Fwww.ondaverde.ch
If I change it to
curUrl[href]=http://www.ondaverde.ch
directly in chrome's inspector, the EB works again, and all the fields appear as normally! (cf second screenshot)
Now I don't know where to continue: shouldn't these values be URL-encoded? Or rather: why can't the element browser interpret this encoded URL? Is this a bug, or a misconfiguration on the server? It happens on the web server, but I could not reproduce it locally with MAMP.
Any hints would be appreciated.
Files
Updated by Urs Braem over 9 years ago
- File Google Chrome 4.jpg Google Chrome 4.jpg added
I'm re-adding the first screenshot - maybe someone with edit rights could delete the file Google Chrome.jpg from above?
Blurring was incomplete.
Updated by Susanne Moog over 9 years ago
- Status changed from New to Needs Feedback
Can you debug that on your system? I'm not able to reproduce it here in any way :(
Updated by Urs Braem over 9 years ago
Yes, I guess it's some server config that causes the problem - but where should I start? What setting could be related to the misinterpretation of the encoded URL? We've already checked mod_security logs and cageFS.
Or the other way round: where can I find the code where the following call "mod.php?M=rtehtmlarea_wizard_element_browser&moduleToken=644344f98253d4e419018e15ebc7356614697e56&&RTEtsConfigParams=tt_content%3A1237%3Abodytext%3A311%3Atext%3A311%3A&editorNo=data_tt_content__1237__bodytext_&sys_language_content=0&contentTypo3Language=default&curUrl[href]=http%3A%2F%2Fwww.ondaverde.ch%2F&curUrl[target]=_blank&curUrl[class]=external-link-new-window&curUrl[data-htmlarea-external]=1" is executed?
Updated by Urs Braem over 9 years ago
It was indeed mod_security - in fact, there are different vendors for mod_sec rulesets, and one ruleset was blocking the URL for the Link Wizard iframe.
We changed the ruleset vendor, and now it works again.
Based on http://www.typo3.net/forum/thematik/zeige/kategorie/sonstiges-1/thema/117838/ which mentions a similar error with the error message `Reason: File "mod.php" was not found (2)` (we also got that under certain circumstances), it could be related to the length of the URL, maybe that was the issue (also based on http://stackoverflow.com/a/507344/160968)
If anybody wants to investigate further, I can provide the names of the mod_sec ruleset providers in private.
So this could be seen as a possible improvement: make RTE link dialogue more server compatible. If no one else has the issue, of course, it also could be closed.
Updated by Wouter Wolters about 9 years ago
- Status changed from Needs Feedback to Closed
I close this issue.
1. we shortened the URL for this within 7 release
2. if many other people had this problem we would have received more reports about it
I hope this is fine for you. If not, please contact me :-)