Oh nevermind. Turns out the was something in my theme that blocked out javascript alltogether. Closing this while being embarrassed.
AdamEvertsson → created an issue.
AdamEvertsson → created an issue.
3 x RTBC. Could this be implemented in a stable release, I wonder?
Awesome!
Cool. Any idea when it'll reach a stable version of the module? Our clients don't accept dev-versions of modules.
AdamEvertsson → created an issue.
I just started using Photoswipe and yes, the error is there, filling the log.
Warning: file_get_contents(/Applications/XAMPP/xamppfiles/htdocs/web/adamevertsson.se/web/libraries/photoswipe/photoswipe.json): Failed to open stream: No such file or directory in photoswipe_library_info_alter() (line 120 of /Applications/XAMPP/xamppfiles/htdocs/web/adamevertsson.se/web/modules/contrib/photoswipe/photoswipe.module)
PHP: 8.1.17
Drupal: 10.1.4
Thank you for a quick reply. You're awesome!
How do you exactly use these modules?
I have several content types with image fields (I'm not using the Media library on these fields, to be extra clear). On every field TinyPNG used to shrink the uploaded images.
What is your TinyPNG module (/admin/config/tinypng) configuration? Is the "Compress on upload" enabled? Is "Integration Method" value is "Download" or "Upload"?
Download.
Is your File field path is configured to use the private:// path?
Yes. The settings at admin/config/media/file-system/filefield-paths is set to private://filefield_paths and in settings.php I use a path to a folder outside the www, chmodded to 777.
How your image field exactly configured?
It's set up the most standard way possible. The only addition is the File Field Paths which I use to change the filename based on information in other fields on the content type.
When does this error usually appears?
On every image upload. The watchdog log says "access denied", and then renders the message Path: /system/files/filefield_paths/image.png. Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException: in Drupal\system\FileDownloadController->download() (line 92 of /home/kulhisto/domains/reklamfranforr/www/web/core/modules/system/src/FileDownloadController.php). which makes me think that the awesome TinyPNG-module and service can't access the image due to access restrictions.
The image gets uploaded allright, and a thumbnail is shown, but the image doesn't get shrunk via TinyPNG.
AdamEvertsson → created an issue.
I've followed the advice above, and I can now verify that the change in File (Field) Paths brakes the TinyPNG modules functionality (as I suspected in comment 11).
The reason for the functionality failing, as far as I can see, is that the image, now "hidden" in the private file folder, isn't available to TinyPNG, and doesn't get shrunk due to this.
Perhaps this is out of scope, but can anyone see a solution here? Other than going back to a previous version of File (Field) Paths and render the site insecure?
Kind regards,
Adam
AdamEvertsson → created an issue.
Would be interesting to see what @dpagini @Deciphered and @voleger think about this.