@gooddev Are you renaming the file uploads using the "Rename files" option on the file upload component in Webforms? That might be the difference and why it works for you and not for me.
I've I added a patch for the issue branch that fixes the issue by decoding the filename before saving it. The patch also cleans up the function a bit and a I have replaced a deprecated function. Can you try if this works for your case as well?
Is this upload endpoint working for you for files with special characters in them? I.e. "filename™.pdf".
To be able to upload files with special characters in the filename, the filename in the Content-Disposition header should be encoded or it will fail even before uploading:
"Content-Disposition": `file; filename="${ encodeURI(file.name) }"`,
When I do this and upload a file with spaces in it, the filename is saved in Drupal with %20 instead of spaces, and as a result it throws an error when trying to download it:
InvalidArgumentException: The filename fallback cannot contain the "%" character. in Symfony\Component\HttpFoundation\HeaderUtils::makeDisposition() (line 182 of /app/vendor/symfony/http-foundation/HeaderUtils.php).
When I remove the encodeURI part, it works for most files but the POST will fail for files with special characters in them:
Cannot convert argument to a ByteString because the character at index 52 has a value of 8482 which is greater than 255.
It's probably useful to attach the patch as well.
I cannot clone branch 2899902-sendupload-files so I've created a new (full) patch based on 4.x, with the changes from branch 2899902-sendupload-files and a fix for D10.3.
AstonVictor → credited markwittens → .
I removed some code manually from the previous patch because it only contained some removed spaces, this might cause problems with testing so I've attached the full patch.
Patch didn't apply on the latest version anymore.
This patch has the same general idea, the code is somewhat different though.
Isn't it possibible to fix this problem by highlighting the match using javascript instead of messing with the cache?
Any news about this issue? I just came across a website we've update to Drupal 10.1.8 where both workarounds from this issue are not working anymore:
Workaround I always used:
{% set _render_cache = content|render %}
Alternative workaround:
{{ { '#cache': content['#cache'] } }}
The provided patches to add the twig function don't apply anymore.
It seems the only way to render the proper cache tags is now to render the entire content variable.
markwittens → created an issue.
Can confirm this patch works, resolves issues reported by the Upgrade status module and PDF's still get generated as expected.
I have the same problem and the patch in the related issue doesn't seem to fix the problem for me. I'm always getting a Javascript error the second time the dialog should load:
jquery.min.js?v=3.7.0:2 Uncaught Error: cannot call methods on dialog prior to initialization; attempted to call method 'destroy'
at Function.error (jquery.min.js?v=3.7.0:2:2741)
at HTMLDivElement. (widget.js:234:16)
at Function.each (jquery.min.js?v=3.7.0:2:3129)
at ce.fn.init.each (jquery.min.js?v=3.7.0:2:1594)
at t.fn. [as dialog] (widget.js:224:10)
at confirmLogout (autologout.js?v=10.1.0:192:22)
markwittens → created an issue.
markwittens → created an issue.
Then what do you propose? The pager information is loaded directly from the view itself, so there's hardly any code duplication. A pager is often essential for a view and I think it actually shouldn't take any extra work for it to be added to the API resource.
Thanks for this patch! I needed the pager info in the output and this patch adds just that plus some more useful data.
Tests should be fixed however and there should be some new tests added for the new output.
markwittens → created an issue.