- 🇨🇦Canada Charlie ChX Negyesi 🍁Canada
We confirm this issue on Amazee, changing
$settings['file_temp_path']to a directory shared between pods (virtual machines) solved it. - 🇨🇦Canada deviantintegral
I think there's a related bug as well for servers hosting multiple distinct Drupal sites, such as in multisite. In our case, we were running automated tests in parallel and file uploads were failing around 30% of the time for files with the same name. Adding a random string to each uploaded file like mktemp does would solve this, but we just moved to using the private files directory.
- 🇺🇸United States khaldoon_masud
#22 worked for me on Pantheon, but I believe we should introduce a setting to create a subdirectory within the designated schema. For example, saving temporary files in the private directory can lead to overcrowding with unsuccessful bulk uploads. We need a solution to manage and clean up those files, which can be achieved by running a cron job.
- 🇺🇸United States uri_frazier Portland, Oregon
#22 🐛 Don't rely on temporary:// (Files do not upload when dropped) Needs work Worked for me as well.
The issue I had was that although the GUI would show all the images were uploaded (green checkmarks across the thumbnails), on the next part of the pop-up where you can add the alt text and other details, only 50% or less of the images would show up to be saved.
So when uploading 4 images at a time, only 1 or 2 images would show up for editing prior to saving. And only those would actually be saved.
This bug was in a Pantheon environment, and only replicable in the stage/test and production/live environments. The multidev and dev environments worked fine (I assume because they don't get any "balance loading"/don't use multiple containers).
Pantheon currently lists DropzoneJS as a problem (thanks shopkinsbit → for mentioning this in #19 🐛 Don't rely on temporary:// (Files do not upload when dropped) Needs work )
The widget relies on a temporary path that is not shared between application containers.
