I ran into an issue when setting a Page Redirect in a content type.
My content type, callled Document, has a Media Entity reference field (field_file) to allow user to upload files (e.g. PDF, DOC, DOCX). I set a Page Redirect when accessing the Document content type to redirect to the media file from field_file, using the following token:
[node:field_file:entity:field_media_file]
Redirect works fine, except when the file name has a space, for instance "my document.pdf". In this case, the user is redirect to a nonexisting page. For instance:
Correct (expected) file path:
/sites/default/files/documents/my%20document.pdf
Given file path:
/sites/default/files/documents/my%2520document.pdf
What's happening here is that the received token target is already urlencoded, and as long as the path isn't external, the function toString() on line 173 apparently urlencodes target again, replacing % for %25 (ASCii code for percent symbol).
I created a patch which undoes the token urlencoding (using rawurldecode(), preventing the duplication. Of course, it needs review, especially for more complex cases such as multilingual sites.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 2995993-12-token-duplicate-urlencode.patch | 631 bytes | jimafisk |
| #11 | 2995993-11-token-duplicate-urlencode.patch | 759 bytes | jimafisk |
| #10 | 2995993-10-token-duplicate-urlencode.patch | 759 bytes | jimafisk |
| #9 | 2995993-9-token-duplicate-urlencode.patch | 759 bytes | jimafisk |
| #7 | htmlspecialchars_decode-2995993-7.patch | 573 bytes | Technorange |
Comments
Comment #2
maursilveira commentedThis is the patch I wrote to fix it. Of course, it needs review, especially for more complex cases such as multilingual sites.
Comment #3
maursilveira commentedI wrote the following patch to solve the duplicated urlencoding. Of course, it needs review, especially for more complex cases such as multilingual sites.
Comment #4
maursilveira commentedI wrote the following patch to fix the duplicated urlencoding. Of course, it needs review, especially for more complex cases such as multilingual sites.
Comment #5
maursilveira commentedComment #6
danielvezaNot working in my case, redirecting to [term:tid]. I'll chuck a patch up if I can spot the cause.
Comment #7
Technorange commentedNeeds to decode it using
htmlspecialchars_decode()instead ofrawurldecode()I have updated the patch.Comment #8
avpadernoComment #9
jimafisk commentedRerolled patch from #2.
Comment #10
jimafisk commentedActual patch attached.
Comment #11
jimafisk commentedOk I think I got it this time :).
Comment #12
jimafisk commentedMaybe this one will actually apply...
Comment #13
matroskeenHey there,
Can anyone confirm that issue still exist in the latest dev version? (8.x-1.x branch)
I was trying to reproduce it recently, but it seems ok. Our tests also don't complain about the file with space in the file name, see: https://git.drupalcode.org/project/rabbit_hole/-/blob/8.x-1.x/tests/src/...
If you're able to reproduce it somehow, please let me know.
Thanks!
Comment #14
matroskeenI believe it was fixed at some point, so closing this one.
Feel free to re-open if the issue still exists in the 8.x-1.x branch.
Thanks!
Comment #16
gillesv commentedThis is still an issue in the latest versions of Rabbit Hole 1.x and 2.x
When there are spaces in the filename, and you try to redirect to it (via [node:field_file] for example), it double encodes the URL resulting in a "Page not found" error.
@jimafisk ' s solutions to replace "PlainTextOutput::renderFromHtml" with "rawurldecode" in PageRedirect.php seems to fix the problem.