Fatal error: Cannot access empty property in modules/field/field.attach.inc on line 324

I fix same error by modifying function _field_invoke_get_instances()

Before
return $instances;

You should put

$instances = array_filter($instances);

Here link to patch: http://pastebin.com/TcyETP3X

Same here.
Did the patch manually as shown in comment #3 - works well.
Thanks to sir.eduha!

Hello,

In which revision the patch will be applied please ?

do you think this will be available on drupal 7.27 ?

Thanks in advance.

Fix the issue, please check attached patch.

I've got the same issue and the patch fixed it. But should I 'hack core' to fix it? Will the fix be in the next version and, if so, when can we expect that to be released? For me, this only affects one content type, and it's one that is not directly displayed to the public (it's for carousel items.) So I can live with the problem if until the next release. But if I fix it and it's not in the next release, the fix will be undone when I upgrade.

This is the first time I've had a problem with core in my six months or so of drupalocity, so I'm not sure how to proceed.

Also, given it only affects one content type, I wonder what the underlying cause is and whether I can somehow modify the affected content type to not cause the problem without applying the patch?

@danbarron If you feel the patch works for you then you can mark the ticket status as "Reviewed & Tested by Community" so that contrib owner can patch it in core and release it.

@sandykadam - With the help of a colleague, I found a bug in code of mine that was causing my issue. I was trying to get the value of a field that did not exist on the node. Sloppy on my part. But that's why I only saw it on one content type. Fixing that made the error go away without the patch, so I should not mark the ticket. Makes me wonder, too, if it's true this is a core bug, but I'll leave that to more experienced folk to sort out. Sorry for the confusion.

Yeah i might have to agree with @danbarron in the fact that it is not a core bug.

I also ran into this problem and after further review noticed there was a hook_node_forms_field_attach_presave put in place that was causing an empty array set to be added to the $instance variable inside the _field_invoke_get_instances(). Although, I do think that the code could definitely be strengthened if some very simple logic was added to make sure that blank arrays couldn't make it into _field_invoke_multiple(). I think the gain of stability from a line or two of code and minimal extra processing would surely outweigh the fatal error you get otherwise. Food for thought.

I was also running into this error but again as above I was trying to call a value of a field that did not exist.

This is still broken in 7.31

Something as trivial as a missing or empty field shouldn't result in WSOD, and hacking core is not ideal obv. The patch worked for me in my case, so in the absence of anything else and on the strength of it working, it gets my vote.

Had same issue; tested patch. Fixed issues with no apparent side effects.

To WSOD because of a request for an empty or non-existent field is a bug. Functions should always have a way to cleanly fall out if there is an error.

Just to confirm, we had the same error message when moving to a new host, and the patch in #6 fixed it for us.

We need to get to the bottom of what causes the bug.

Is this the same issue as #1161708: Problem with function _field_invoke when used on a content type with no field instance? Because the patches there are fixing a specific, identifiable problem with this function that could result in $instances having an empty element in it.

I'm writing this comment to make it easy for others. We had the same error message when moving to a new host, and the patch in #6 fixed it for us.

Sames as #18:
Moved multiple sites to a new server, suddenly WSOD on all sites' pages where field_view_field() is called.

Resetting the status.

I can confirm that I am also getting this error after the latest update of core. As SkyBuzz indicated. patch in #6 does fix for me.

I confirm the patch in #6 works for me too. The error appeared on a production server with php "5.3.2-1ubuntu4.27" and I tried to reproduce it locally with php 5.5.10 but the local version didn't crashed.

This is a question of having clean and bulletproof code or better performance.

$instances = array_filter($instances);

This is the one and only line added in patch.
With this line we are assuring that the $instances array is free of any FALSE values with the cost of checking this array for those values.

I'm a type of coder that checks if $nid is is_numeric() before passing it to node_load().
So.. do you want to take the blue pill and end the story or do you want to take the red pill, stay in WSOD wonderland and see how deep the rabbit hole goes with questioning yourself what kind of values may end up in there after all future updates?

Because minimum requirement for Drupal 7 is NOT PHP 5.5, this needs to be resolved.

If you don't want to renounce of getting an error message about an empty property while avoiding a WSOD, we could make use of a callback function in array_filter.

As I had this issue some time ago, I am not be able to reproduce it. I haven't tested it. Please do.

I like the upgraded solution in #27.

@lolandese, you probably upgraded your PHP version, so you're not getting the WSOD any more.

To test the #27 patch without the need of the issue occurring:

// Remove the last four array elements to not provoke the error message.
$instances = array("a"=>1, "b"=>2, "c"=>3, "d"=>4, "e"=>5, "zero"=>0, "false"=>false, "", "null"=>NULL);
print_r(array_filter($instances, "error_empty_property"));

/**
 * Return a value unaltered but nothing if it equals to FALSE. Return an error
 * message in that case and add the same to the watchdog.
 */
function error_empty_property($instance) {
  if ($instance) {
    return $instance;
  }
  else {
    $message = t('Cannot access empty property from the variable $instances in the function _field_invoke_get_instances in modules/field/field.attach.inc. Probably there is an empty or non-existent field on an entity/bundle.');
    drupal_set_message($message, 'error', FALSE);
    watchdog('field', $message);
  }
}

Just put it in the node body with the text format 'PHP code' and save.

Furthermore the error message is more specific to aid in debugging.

Can anyone answer my question above?

We need to get to the bottom of what causes the bug.

Is this the same issue as #1161708: Problem with function _field_invoke when used on a content type with no field instance? Because the patches there are fixing a specific, identifiable problem with this function that could result in $instances having an empty element in it.

The patch in #1161708-15: Problem with function _field_invoke when used on a content type with no field instance looks like it still applies to Drupal 7, if you need that to test.

Looking at the patch here:

+    $message = t('Cannot access empty property in modules/field/field.attach.inc');
+    drupal_set_message($message, 'error', FALSE);

We definitely don't want to do a direct drupal_set_message() because the site may have error reporting to the screen turned off. Maybe a trigger_error() or something.

However, the only point of logging/displaying this would be if it's something that the calling code needs to fix and this helps developers find the bug. Maybe it makes sense in that case. First we need to determine that. That is why I'm asking what the root cause is. It's not at all obvious that this is a problem with calling code at all. Instead, if it's the same problem as the issue I mentioned above, then we just need to fix that instead.

Is this the same issue as #1161708: Problem with function _field_invoke when used on a content type with no field instance?

If we stick to the description of the OP where the Fatal error occurs when rendering a View, then most likely the answer is 'yes'. The View probably tries to render a non-existing field on a bundle that makes part of the Views "query". That's very similar to the title of #1161708.

Comments #10 and 11 of the other issue are useful to trigger the issue and do indeed result in an error message by the #27 patch here, independent from the PHP version.

However, the only point of logging/displaying this would be if it's something that the calling code needs to fix and this helps developers find the bug.

Especially because this doesn't seems an issue on PHP 5.4 and higher. That results in "calling" a non-existing field for a bundle going unnoticed. Less relevant for Views but it might give useful hints for developers. The #27 patch solves this.

We definitely don't want to do a direct drupal_set_message() because the site may have error reporting to the screen turned off. Maybe a trigger_error() or something.

Makes sense. See https://www.drupal.org/node/158043#invisible. If it is decided an error message is desired also for more recent PHP versions (in my opinion yes but I will wait for some consensus), I could see to adapt the patch accordingly.

Thanks.

Patch #27 works for me. In my case, I have removed the drupal_set_message() line.
It would be great if there was a way to know which bundle and field was causing the trouble, and output that information to watchdog. I can't see a way to do that, but that just reflects my lack of PHP knowledge, I think.

For completeness, here is the patch. It is #27 without the drupal_set_message() line.

After spending most of today working on this, I thought I would come back and add a note about what happened in my case.

This was a site that I took over from another developer. On my local machine (PHP 5.6) everything was fine. On a staging server (PHP 5.3) the error appeared.

The patch at #33 fixes the error, but going back over the apache error logs, I was able to find the root cause.

My advice to anyone coming across this issue would be:

Go to your apache error log (on Ubuntu, in /var/log/apache2/) and see if you can find a call to field_view_field in a template.php file.

PHP  28. theme() /var/www/myproject/web/includes/common.inc:5987
PHP  29. myproject_preprocess_node() /var/www/myproject/web/includes/theme.inc:1125
PHP  30. field_view_field() /var/www/myproject/web/sites/all/themes/myproject/template.php:89
PHP  31. _field_invoke_multiple_default() /var/www/myproject/web/modules/field/field.module:884
PHP  32. _field_invoke_multiple() /var/www/myproject/web/modules/field/field.attach.inc:399

In my case, there was a call to field_view_field() which tried to get a field from a content type. This field was not defined on the content type, so that's what caused the error.

$whatever_field = field_view_field('node', $vars['node'], 'field_whatever', array('label' => 'hidden'));

Wrapping the code in an if-statement fixed the problem for me - here, we make sure that field_view_field() is only called if the field is already available for that entity.

if (isset($vars['node']->field_whatever)) {
  $whatever_field = field_view_field('node', $vars['node'], 'field_whatever', array('label' => 'hidden'));
  ...
}

Once I had worked that out, I found I didn't need to patch core, as has been mentioned already in #9 and #10.

I had this issue only on our staging site after we changed tweaked the host. The page would not load and I would get an ajax alert with the same error message on the views settings page. After a day of researching the error and altering the settings I found a simple fix that did the trick.

In the views settings page, go to Format / Settings (first column). Uncheck 'Add views row classes' if there's no value in the 'Row class' textfield above. That's it.

The 'Add views row classes' option was checked by default for me.

Views/Views UI 7.x-3.13

I had this issue only on our staging site after we changed tweaked the host. The page would not load and I would get an ajax alert with the same error message on the views settings page. After a day of researching the error and altering the settings I found a simple fix that did the trick.

In the views settings page, go to Format / Settings (first column). Uncheck 'Add views row classes' if there's no value in the 'Row class' textfield above. That's it.

The 'Add views row classes' option was checked by default for me.

Views/Views UI 7.x-3.13

Hi all,

Same issue as reported here. This works on a client site which is hosted on different infrastructure to our dev setup.

Can confirm the patch in #6 solves the issue.

Cheers

Tom

@blacklabel_tom Great to hear it's working for you. May be you can mark issue as RTBC.

Did we find the root cause for this issue after all? See #30

I read the subsequent comments and it still doesn't look to me like there is any evidence this needs to be fixed in core (except perhaps #1161708: Problem with function _field_invoke when used on a content type with no field instance which is a separate issue).

Also:

+    $message = t('Cannot access empty property in modules/field/field.attach.inc');
+    watchdog('field', $message);

Messages should be passed untranslated, and inline with the watchdog call rather than as a separate variable. They should not be pre-translated since that would result in the administrator seeing the message in someone else's language (when they look at the logs).