I have a article with attachments and when this article is displaying in short form (i.e. when ) i get meny of this errors:

Notice: Undefined offset: 35 w file_field_prepare_view() (linia 201 z /home/esperant/domains/esperanto.pl/public_html/d7/modules/file/file.field.inc).
Warning: Invalid argument supplied for foreach() w file_field_prepare_view() (linia 201 z /home/esperant/domains/esperanto.pl/public_html/d7/modules/file/file.field.inc).

When I remove the attachments the warning disappears.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Luna Vulpo’s picture

I forgot write. This problem shows up after upgrading to 7.2

calculus’s picture

Subscribing

webchick’s picture

Issue tags: +Needs tests

We need tests for this condition, because they should've caught this.

By attachments, do you mean filefield uploads?

Luna Vulpo’s picture

Yes. I add field to standard content type "article". I set for this field "field type is file"

I comment the content of this function and this warning disappears but is is not clean solution so i submit bug report.
I thing that problem is elsewhere because is this function looks same as in D7.0

pmelab’s picture

Got the same issue. Only happens if a file field is left empty and the node is displayed in a list. Looks like the $items array is not populated with all entity-ids occuring in $entities.
Same problem with taxonomy terms.

olafveerman’s picture

Same issue here, but in my case it also happens when I have nodes of different languages in the list even if all filefields have a file.

Notice: Undefined offset: 1 in file_field_prepare_view() (line 201 of [...]/modules/file/file.field.inc).
Warning: Invalid argument supplied for foreach() in file_field_prepare_view() (line 201 of [...]/modules/file/file.field.inc).
Notice: Undefined offset: 1 in file_field_prepare_view() (line 207 of [...]/modules/file/file.field.inc).
Warning: array_values() expects parameter 1 to be array, null given in file_field_prepare_view() (line 207 of [...]/modules/file/file.field.inc).
Notice: Undefined offset: 3 in file_field_prepare_view() (line 201 of [...]/modules/file/file.field.inc).
Warning: Invalid argument supplied for foreach() in file_field_prepare_view() (line 201 of [...]/modules/file/file.field.inc).
Notice: Undefined offset: 3 in file_field_prepare_view() (line 207 of [...]/modules/file/file.field.inc).
Warning: array_values() expects parameter 1 to be array, null given in file_field_prepare_view() (line 207 of [...]/modules/file/file.field.inc).
plach’s picture

Title: Warning: Invalid argument supplied for foreach() w file_field_prepare_view() » Field invoke multiple does not handle field language correctly
Version: 7.2 » 8.x-dev
Priority: Normal » Major
Status: Active » Needs review
Issue tags: +translatable fields, +Needs backport to D7
FileSize
3.04 KB

The attached patch should fix the issue, tests are still missing.

webchick’s picture

Thanks for getting on this so quickly, plach! :D

plach’s picture

I should stop fixing core issues at 3:00 AM, see what happened the last time :(

ubersuts’s picture

Hi, when I try a dry run of the patch, I get this:

patch -p1 --dry-run < ./tf-1169426-7.patch

patching file modules/field/field.attach.inc
Hunk #1 FAILED at 303.
Hunk #2 FAILED at 312.
Hunk #3 FAILED at 329.
Hunk #4 FAILED at 347.

any ideas what I might be doing wrong?

plach’s picture

Be sure to checkout the latest code from the 7.x branch, this applies cleanly to 7.2 however.

yli_ektor’s picture

#7: tf-1169426-7.patch queued for re-testing.

rodrigoaguilera’s picture

suscribe

lklimek’s picture

Patch #7 seems to fix the issue (or at least remove error messages ;) ).

oerjann’s picture

Patch #7 removed the error messages for me to :)

fietserwin’s picture

fietserwin’s picture

FileSize
2.74 KB

Perhaps using the $items from the foreach is more clear (although the PHP manual states that foreach operates on a copy, the old version seems to work anyway):

    // Iterate over all the field translations.
    foreach ($grouped_items[$field_id] as $langcode => $items) {
      $results = $function($entity_type, $grouped_entities[$field_id][$langcode], $field, $grouped_instances[$field_id][$langcode], $langcode, $grouped_items[$field_id][$langcode], $a, $b);
    // Iterate over all the field translations.
    foreach ($grouped_items[$field_id] as $langcode => &$items) {
      $results = $function($entity_type, $grouped_entities[$field_id][$langcode], $field, $grouped_instances[$field_id][$langcode], $langcode, $items, $a, $b);
yareckon’s picture

subscribe

Carlos Miranda Levy’s picture

Patch applied properly and errors are gone on 7.2 multisite site

webchick’s picture

Issue tags: +Release blocker

I'd like to make sure this is part of 7.3.

Any takers on writing that test?

plach’s picture

Assigned: Unassigned » plach

I'll do

plach’s picture

Assigned: plach » Unassigned
FileSize
2.86 KB
6.04 KB

Here are tests. The test-only patch is supposed to fail to show that tests capture the bug.

Status: Needs review » Needs work

The last submitted patch, tf-1169426-22-test.patch, failed testing.

webchick’s picture

Status: Needs work » Needs review

Stop that, bot. :)

darq88’s picture

eee...how to install this patch?

fietserwin’s picture

take the most recent patch (not the test only one) and remove the test part out of it before applying

darq88’s picture

sorry, I'm new to drupal could you explain it to me step by step?
thx for your replay

fietserwin’s picture

g4b0’s picture

#22 worked for me!

isaac.el.cec@gmail.com’s picture

eduardo barros’s picture

aspilicious’s picture

Sub

jviitamaki’s picture

Sub

plach’s picture

Ok, it seems the patch fixes the issue: a feedback from @yched and @sun would be welcome...

sun’s picture

+++ b/modules/field/field.attach.inc
@@ -303,9 +303,6 @@ function _field_invoke_multiple($op, $entity_type, $entities, &$a = NULL, &$b =
-        $grouped_entities[$field_id][$id] = $entities[$id];

@@ -315,6 +312,10 @@ function _field_invoke_multiple($op, $entity_type, $entities, &$a = NULL, &$b =
+          $grouped_entities[$field_id][$langcode][$id] = $entities[$id];

@@ -327,8 +328,10 @@ function _field_invoke_multiple($op, $entity_type, $entities, &$a = NULL, &$b =
+      $entities = $grouped_entities[$field_id][$langcode];

@@ -346,9 +349,9 @@ function _field_invoke_multiple($op, $entity_type, $entities, &$a = NULL, &$b =
     // Populate field values back in the entities, but avoid replacing missing
     // fields with an empty array (those are not equivalent on update).
...
+    foreach ($grouped_entities[$field_id] as $langcode => $entities) {
+      foreach ($entities as $id => $entity) {
+        if ($grouped_items[$field_id][$langcode][$id] !== array() || isset($entity->{$field_name}[$langcode])) {
           $entity->{$field_name}[$langcode] = $grouped_items[$field_id][$langcode][$id];
         }
       }

I'm not really sure whether we also need to stack all entities by language. For monolingual sites, this change makes no difference. But on multilingual sites, $grouped_entities will contain {fields} x {languages} "copies" of each entity. Whereas it looks like we.......

well, scratch that - the overall processing logic already exists. Looks like _field_invoke_multiple() could use some @chx magic and @sun clean-up in a follow-up issue.

+++ b/modules/field/field.attach.inc
@@ -327,8 +328,10 @@ function _field_invoke_multiple($op, $entity_type, $entities, &$a = NULL, &$b =
-    foreach ($grouped_items[$field_id] as $langcode => $items) {
...
+    foreach ($grouped_items[$field_id] as $langcode => &$items) {

Is there a reason for allowing the callbacks to change $items in $grouped_items[$field_id] by reference?

Powered by Dreditor.

plach’s picture

@sun:

I'm not really sure whether we also need to stack all entities by language. For monolingual sites, this change makes no difference. But on multilingual sites, $grouped_entities will contain {fields} x {languages} "copies" of each entity.

If I'm not mistaken objects are always passed by reference, so what get copied are object references not object data structures.

Is there a reason for allowing the callbacks to change $items in $grouped_items[$field_id] by reference?

Well, this is only a readability improvement: the old code already lets items be passed as reference, see for instance: http://api.drupal.org/api/drupal/modules--field--field.api.php/function/....

sun’s picture

the old code already lets items be passed as reference

While that is true, the foreach ($items[$id] as $delta => $item) { generates a copy of &$items[$id][$delta] as $item. Only the results of the callback are put back to the &$items passed by reference, but the callback only gets the copy in $item.

I'd suggest to revert that change to the foreach for now. Deciding on whether field callbacks should be allowed to manipulate $items by reference looks like a different question to me that should be discussed in a separate issue.

plach’s picture

I cannot parse your latest comment: the current _field_invoke_multiple() code passes $grouped_items[$field_id][$langcode] as the $items parameter of hook_field_X() (multiple) implementations. Implementing hooks may decide to get a reference or a copy depending on their signature.

Do you mean that the current code always passes a reference and so hooks altering for their private reasons the $items array may see their changes unintentionally propagated?

sun’s picture

Status: Needs review » Reviewed & tested by the community
+++ b/modules/field/field.attach.inc
@@ -327,8 +328,10 @@ function _field_invoke_multiple($op, $entity_type, $entities, &$a = NULL, &$b =
-    foreach ($grouped_items[$field_id] as $langcode => $items) {
-      $results = $function($entity_type, $grouped_entities[$field_id], $field, $grouped_instances[$field_id], $langcode, $grouped_items[$field_id][$langcode], $a, $b);
+    foreach ($grouped_items[$field_id] as $langcode => &$items) {
...
+      $results = $function($entity_type, $entities, $field, $instances, $langcode, $items, $a, $b);

ah, ok, now I get it -- you also replaced $grouped_items[$field_id][$langcode] with $items in the arguments passed to the field callback.

Alright, makes sense.

Powered by Dreditor.

Levure’s picture

subscribe

henwu’s picture

subscribe

snupy’s picture

subscribe

auris’s picture

subscribe

mordonez’s picture

subscribe

auris’s picture

Using view's frontpage, you don't get this warnings.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Awesome work! Thanks folks!!

Committed to 8.x and 7.x.

Levure’s picture

Hello !

I have a production site impacted by this issue.

Is the patch [tf-1169426-22.patch] reliable ?
Do we have to manually apply that patch, or is there a new core release planned soon ?

Many thanks in advance for your reply ! :-)

plach’s picture

The patch in #22 got committed: a development snapshot is coming in 4 hours. If I understood the current plans correctly, the next stable release should be available by the end of June.

Everyone here is encouraged to test the patch by manually applying it or downloading the development snapshot, because the code in it will be part of D7.3. We have more than one week to fix possible side effects and ensure D7.3 behaves well, let's make this happen ;)

eduardo barros’s picture

patch in #22 is working for me.

texis’s picture

patch in #22 is working for me too :-)

Axl’s picture

Sub

Levure’s picture

For information, this patch is now included in Drupal 7.4 release.

Thanks to everybody ! :-)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

wogelberg’s picture

i am running windows and cygwin doesnt work properly for me.
*pulling my hair out and crying*
cant somone upload the patched files instead of the patch.
thanks