File upload preview broken

This problem is real. I have implemented the temporary fix of using the private:/ file stream, but we already use private, so I cannot point it to a temp directory -- so I guess we will be accumulating unwanted files in there until this is fixed, eh? In any case, the best theory I could come up with, discussing with Pnatheon support, is that the module maintainers are wrongly referencing the tmp directory, without anticipating multiple application servers in a modern environment such as pantheon’s. The issue did not appear during our QA, because we test on a multidev site, which does not use the same file handling as the live site. The other functionality of our site apparently uses the temp directory just fine, so that is why our best guess is that there is a problem with this module.

I suppose that the stream was changed to 'temporary' form 'public' because tmp directories have special functionality, and these are not files we want in with our permanent files. So we will be watching this issue carefully! Thanks all.

New finding. This is also broken on a lando site running the pantheon recipe. Might make this easier to replicate if you are not on pantheon. I worked with pantheon support ton this and they are of course clear that the issue is with this module. Which is reasonable since other functions of the site use temp directory and everything else works.

Would be interesting to see what @dpagini @Deciphered and @voleger think about this.

Same issue since updating to beta6. Upgrading major, as it's an ongoing issue that needs some kind of determined path forward.

As said in comment #6 🐛 File upload preview broken Needs work , I just needed to change the Temporary file location in File (Field) Paths settings (/admin/config/media/file-system/filefield-paths) to private://filefield_paths to get the previews back without any patch.

In my setup, both the file system (/admin/config/media/file-system) and my image field use the private system which path is declared in the settings.php file.

Thanks to joro78 →

I think the issue is that temporary:// isn't pointing to the defined temporary directory, right?

So of course we can change the location to private:// or public://, but we should be able to have temporary:// correctly point it to the specific temporary directory defined in the File System... especially if this is the module's default. This directory default which was changed in beta6 was to address a security issue. So I think a fix is still necessary.

A few tests I made.

My original setup had no private path set in settings.php so I've set it to a specific folder outsite the web directory, on the same level of the temporary folder. I had to confirm the settings in /admin/config/media/file-system and clear the caches.
Then, I updated the module from beta 5 to beta 6 and run update.php.

My settings in admin/config/media/file-system/filefield-paths are set to temporary://filefield_paths.
When I create a new node with an image then the thumbnail is not visible and when I inspect the location of the file it reads <img data-drupal-selector="edit-field-image-0-preview" src="/site10/web/system/temporary?file=styles/thumbnail/temporary/filefield_paths/kippen2023.jpg&amp;itok=6VN5sNjz" width="100" height="75" alt="" loading="lazy" class="image-style-thumbnail">.
I can not find any thumbnail file in the temporary folder that correspond to the file uploaded and that is the reason why the thumbnail is not seen.

Second test:
I change the settings in admin/config/media/file-system/filefield-paths to private://filefield_paths.
I create again a new node and add the same image. The image is now visible and when I inpect the location of the thumbnail file again it reads <img data-drupal-selector="edit-field-image-0-preview" src="/site10/web/system/files/styles/thumbnail/private/filefield_paths/kippen2023.jpg?itok=j7MjYfJJ" width="100" height="75" alt="" loading="lazy" class="image-style-thumbnail">.
Now I can find a file that correspond the file uploaded in the private folder and everything is fine now.

So the beta 6 version only works:
1. if you specify a private folder in settings.php AND
2. use the private://filefield_paths settings and NOT the temporary://filefield_paths settings.

Since using a private path is not the default settings in a new installation nor for those that have never the need to use it, this update does NOT work for the most of us.

Please a look to my findings. Maybe some light is coming in the darkness now.

Hello,

The issue has not been seen until now because most people didn't change the (default) settings of the filefield_paths module. These settings were somewhere hidden inside the settings of the /admin/modules and then choose this module. These default settings were always public://. And this selection worked out.
Changing the settings to temporary:// on previous versions didn't work neither.

Now, from beta6 on, these settings are changed to temporary:// by default and this doesn't work like before. Also a new settings page is created in admin/config/media/file-system/filefield-paths next to the admin/config/media/file-system settings page, so that users can more easily change the settings and most imported: it is more visible.

So, if you used the settings public:// before in beta5 and earlier versions and you don't want to use the temporary path for your temporary files when you create or edit a node then first go to admin/config/media/file-system/filefield-paths and change it back to public:// like it was before in beta5. This way, you wil see your thumbnails again.

Greetings

I had upgraded to 8.x-1.0-beta6 weeks ago but the exact same problem happened first time today.
I agree with #24 last paragraph.

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

@EricVL - your solution worked. Thank you!

@EricVL - I confirm solution #24 worked after updating to beta7. Thanks!

I agree with @eugene.ilyin comment #3.
In the core modules system FileDownloadController::download() method, the requested file path with image style fails the is_file($uri) check and the method returns 404 Not Found.

Although the suggestion at #24 does indeed work, keep in mind there is a security risk here if your site was using private files. That is, your temporarily uploaded private images will be placed in the public files folder (and probably just left there I suppose).

If your site is not using private files, it should be fine to do #24 as a workaround. However, it's not a permanent solution (for e.g let's say your site were to use private files in the future, then you should revert the change).

The root issue should be fixed in this module as the permanent solution.

Thank you #6!

Same patch with last version

Patch in #32 works

Hi!

I have set my tmp path in settings.php
Either i use /tmp or ../../tmp, the preview does not work and I have the mentioned error in the IS.
with the patch in 32, the preview is displayed in any edit form's field that uses filefield_path

Best

After testing the patch, i have realized that with the patch, any file uploaded does not follow 'File path' and 'file name' anymore, only what it seems the 'file_directory' path.

Best

@gorkagr I found the same thing. Breaks file field paths.

Patch number #32 🐛 File upload preview broken Needs work worked for me! thanks!

Do not use attached patches.

As a workaround use #12 approach with private://filefield_paths (which is preferred) or public://filefield_paths.

Disallowing using temporary:// schema makes sense. But we need better test coverage for that.

@voleger
Correct. You can find my complete explanation in #24.
If you don't have a private setting in your setiings.php file, the only posssibility is to use the public:// scheme.

`temporary://` filesystem is OK to use except when the form widget supports file preview and expectations require it.

So, we now have a global 'temp_location' configuration, which is used by default by the rest of the field widget configurations.

To resolve the issue, we need to allow the overriding of the default filesystem used by the file field widget. Also, we need to keep promoting the `private://` filesystem over `public://`.

I think ✨ Override temp_location in field configuration Needs review resolves this issue.