Multivalue field : only the first field is correctly treated

Here happens the same with the multiple images.

Edit - Happens only when "Active updating" is selected for me.

I confirm the problem. Only first file is processed on node save. Is it possible to fix this soon?

I can confirm problem as well using the dev from 2012-Mar-26

Field Settings:
*Not Required
*png, gif, jpg, jpeg
*(max)1024x1024
*(min)(blank)
*4 MB
*(progress) Throbber
*(num values) 9
*public files

File (Field) Path settings:
*dynamic/post/image/user/[node:author:uid]/listing/[node:nid]
*[file:owner:uid][node:nid][file:fid].[file:ffp-extension-original]
*Active updating (enabled)

Same problem when Active updating is disabled...

Oh, forgot to mention that If I do a retro update, it only does the 1 image for each node per pass.

Ex. 2 nodes with 10 pictures, it only does 2 pictures per run which means I have to run the retro update 5 times.

Also, If I have "Active Updating" turned on, edit a node and save it, it will convert the next picture in line but only 1 per save. 4 total pictures = 3 additional edit/saves after node creation.

GRRR! Also forgot to mention that I'm using the multiupload_imagefield_widget but I doubt that has much to do with it...

Will it be better?

--- filefield_paths.inc.orig	Mon Mar 26 07:17:59 2012
+++ filefield_paths.inc	Tue Apr 10 13:14:46 2012
@@ -79,7 +79,6 @@
               }
               break;
             }
-            break;
           }
         }
       }

Here's a patch, can confirm it works for me.

Followup: just performed a "Retroactive update" on three content types, containing image fields with up to 5 images. About 1000 images in full, with 300 nodes. Both moving folder and renaming filename. Worked perfectly with the patch, while before it only processed the first image.

+1 on #5. Major indeed.

I discovered this myself just now and solved it the same way.

My case - I had programmatically added a number of attachments (PDF_to_image), only the first was getting renamed.
That "break" there looks like a typo - it's nested inside several layers of if() but it has the effect of completely breaking out of the $items loop and abandoning any more attachment processing.

For testing - this problem MAY be hard to reproduce if using the UI and attaching files one-by-one, as the AJAX form submission that happens each time you 'add more' may mask the bug.
To test, try starting with a clean site, adding multiple files to a field without the module,
THEN enable filefield_paths, apply a rule to that field, enable 'active updating' and try to re-save the node. Only one field will be updated.

Other modules that add more that one file at once (eg multiupload_imagefield_widget as above) will also trigger this. Daily use may not.

Chances to commit?

+1 on this issue... the patch on #7 solve the problem.

Tested and verified.

This nearly critical for projects

Yes, patch is confirmed to work. Thanks!

-Daniel
Highline Residential

I don't think the patch in #7 applies to the latest 7.x-1.x-dev. It might need a reroll.

Thanks guys, confirmed and committed.

I'm not sure if this is related or a new bug, but this problem still occurs in the latest builds, stable and dev.
Only the first item of a multivalue-field ist treated right.

I tried it on a fresh D7 installation

Simple Testcase:
- Enable filefield_paths
- Add an image field to any content type (in my case basic page)
- Set number of values (in my case 4)
- Set filefield-paths settings (in my case "images/[node:nid]")
- Create a node of the content type and add some images

The first image will be placed in sites/default/files/images/1/filename.ext as it should be.
The rest of the files will not be treated and remain in sites/default/files.

If i enable retroactive-updating the files still won't move to the right directory.

I'm currently experiencing the issue described in #18 as well, except there's a slightly different configuration of fields:

* field_image_a
* field_image_b
* field_image_c

FFP works perfectly on A, but not B or C.

There are tests in place that prove that the usecases in #18 and #19 do actually work, if you can provide steps on how to reproduce the issues you are having I'd be happy to re-open, but currently re-closing this issue.

Just done a clean installation of 7.50 with this module and attached is the files folder after adding 2 nodes of type tour where the file field path is set to be a folder called tour

I got the same issue. In my case I have multivalue file field which use [node:nid] token for the File path.
Every time when I upload a few files only first one is saved in the folder.

I debugged a bit and found that file_prepare_directory() returns TRUE for the first file and FALSE for all other uploaded files. That's why a single file is always listed in a folder.

Created a patch where a directory creation is not checked and file_move() can throw an error if something goes wrong.

This exact same issue also applies for the D8 module (see #2842793), both on fields with > 1 value or with multiple file fields on a node. I've created a new ticket for the D8 issue as the patch from #23 can't be applied straight away due to some changes in the variables. The patch itself however does resolve the issue.

There are tests in place that prove that the usecases in #18 and #19 do actually work, if you can provide steps on how to reproduce the issues you are having I'd be happy to re-open, but currently re-closing this issue.

I'm not sure whether it is relevant, but I've seen this issue when using the pathauto plugin to rewrite the filenames. AFAICS, there are tests for multiple file fields using the token replacement, but not for pathauto.

I confirm the #23 is working nicely!!!
I use this patch for a multivalue field inside a field collection (private path).
Before applying it, my file was not copied at the right place... now, it is perfect.
Thank you!!!!!!!

#23 works great. Thank you!

This appears to also be fixed with #1924686: File Field Path does not overwrite existing file but adds _0 to filename instead.

As I mentioned in https://www.drupal.org/project/filefield_paths/issues/1924686 the recent security update seems to have included that fix, though it was left out of the patch notes. The testing I've done on my dev site seems to support this issue was fixed as well.

If you're still experiencing this issue after updating to the most recent version, feel free to reopen. Since the file structure has changed, any patches will have to be rerolled if necessary.