I edit a node that already has a few images. I replace the images with new images and set their alt title.
First, the regenerated thumbnail is off the old image (or another image from somewhere else on the site).
Secondly, when I save the node, the order of the images are different from what appears on the node edit screen.
Thirdly, after node save, the images used are wrong. For e.g. if I uploaded image1, image2, image3 in this order, then when i save, I see image1, image2, image2. And the alt title for image3 is now used for image2.
Edit a node that already has a few images and replace the images with new images whilst also setting alt titles for the new images. Observe the re-generated thumbnails on the node edit screen. Save the node and observe the order of the newly uploaded images.
NB - I am using Cloudflare CDN on this site and I know that Cloudflare caches images. So I initially thought this was the issue. But after pausing Cloudflare, the issue persists.
Please see attached my filefield_path settings for my image field.
| Comment | File | Size | Author |
|---|---|---|---|
| Screenshot.png | 244.09 KB | xamount |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #4
decipheredConfirmed on the current
8.x-1.x. Every upload on a File (Field) Paths field is staged at<temporary location>/<original name>until the entity is saved. When a second upload has the same name as the first, it takes the same staged path, and the image widget builds its preview URL anditokfrom that path, so the second upload shows the first file's thumbnail wherever the first one was cached. That is the wrong image on the edit form from the original report. The other two symptoms, images out of order and one image duplicated onto another item, do not reproduce any more; a functional test that removes three images and uploads three new ones finds every alt, URI and checksum where it should be.The merge request stages each upload in a directory of its own under the temporary location, so no two uploads ever share a staged path or a preview URL. A new
hook_file_deleteremoves that directory once it is empty, when cron deletes an upload that was never saved, and only when the directory sits directly inside a configured staging location. A site with no staging location configured, or one set to a bare scheme root such asprivate://, stages under that root, the way core does. Kernel, unit and functional tests cover the staged path, the cleanup and the two edge cases. Needs review.