Hello,

I changed the content type name (both ui and data), since this is quite easy in D7. After I went to update the View that was built on this content type I get this error message:

fatal error cannot access empty property in field.attach.inc on line 314

Comments

giorgio79’s picture

Title: fatal error cannot access empty property in field.attach.inc on line 314 after changing content type name included in View » fatal error cannot access empty property in field.attach.inc on line 314 after changing content type name used in View
Status: Active » Fixed

After I cleared the cache it works fine. So I guess we can mark this as fixed.

Status: Fixed » Closed (fixed)

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

killtheliterate’s picture

Status: Closed (fixed) » Active

I've encountered this error as well, and no amount of clearing cache resolved it. There are a few other threads about that make mention of this error during migration of a d6 site to d7, but I've done no migration.

I've gone so far as to manually truncate cache tables, etc...

killtheliterate’s picture

I had a php snippet that seemed to be my culprit, though I don't know why this is throwing the error.

<?php
  if(arg(0) == 'node') {
  $nid = arg(1);
  $node = node_load($nid);
  $subtitle_fetch = field_get_items('node', $node, 'field_sub_title');
  $subtitle = field_view_value('node', $node, 'field_sub_title', $subtitle_fetch[0]);

   if ($subtitle != '') {
     print '<h2 class="subtitle">';
     print render($subtitle);
     print '</h2>';
    }
  }
?>

I thought this was sound, but, tracing this back, it does seem to be a problem with localization handling... Line 314 of field.attach.inc is where a loop gets built for field translation... Which I though using field_view_value was supposed to solve.

---

I seem to making a habit out of this. So, yea, I guess it would make sense that I get an error trying to access an empty property. I ought've checked the content type on the node being loaded, before trying to get values out of a field that may or may not exist. It would have been easy enough to do, but I hadn't thought to look in a tpl for custom stuff I'd been doing.

<?php
if($node->type == 'page') { then do a bunch of shtuff }
?>
Pimmy’s picture

I've posted the same here: http://drupal.org/node/1368444, but here it seems more appropriate, so here it is again:
I get the same error when I try to enable aggregation of more than one content type in Views.
Looking at the code:

foreach ($languages as $langcode) {
  $grouped_items[$field_id][$langcode][$id] = isset($entity->{$field_name}[$langcode]) ? $entity->{$field_name}[$langcode] : array();  // Line 314 causing the error
  // Group the instances and entities corresponding to the current  
  // field.
  $grouped_instances[$field_id][$langcode][$id] = $instance;
  $grouped_entities[$field_id][$langcode][$id] = $entities[$id];
}

I see no relation between languages and what triggers the error (agregation in views).

Clearing the cache makes no difference. Removing one of the content type from the view, or disabling the aggregation makes the problem disappear - but this is not an option for me.

killtheliterate’s picture

@Pimmy

What happens if you change $langcode to 'und'? Seems like maybe you have languages set on a your content types, maybe differently. Problem is likely that nothing is returning for $langcode... That's what caused this issue for me; trying to access stuff that didn't exist.

Pimmy’s picture

Thanks killtheliterate for the prompt response. I hope I understood you correctly and this is how I modified the snipped:

      foreach ($languages as $langcode) {
        if (isset($entity->{$field_name} && isset($entity->{$field_name}[$langcode])) {
          $items = isset($entity->{$field_name}[$langcode]) ? $entity->{$field_name}[$langcode] : array();
        } else {
          $items = $entity->{$field_name}['und']; // I also tried: $items = array();
        }

        $result = $function($entity_type, $entity, $field, $instance, $langcode, $items, $a, $b);
        if (isset($result)) {
          // For hooks with array results, we merge results together.
          // For hooks with scalar results, we collect results in an array.
          if (is_array($result)) {
            $return = array_merge($return, $result);
          }
          else {
            $return[] = $result;
          }
        }

This resulted in an error of the same kind in another part of the code:

Parse error: syntax error, unexpected T_BOOLEAN_AND, expecting ',' or ')' in /home/content/08/8195408/html/modules/field/field.attach.inc on line 197

I have set the language to UK at http://server.com/#overlay=admin/config/regional/settings and nowhere else. The content types are basic CCK ones with Node Reference. Really the only thing that triggers this is the fact that I enable 'Aggregation' on a view pulling data from two content types. If I split the view for only one of the content types, the 'Aggregation' all works fine.

The bad bit is that the hosting is on a shared hosting where I have no option to read the logs - so I cant insert any log statements and debug what is happening.

Thanks,
Pimmy

David_Rothstein’s picture

Note that if you are getting the "cannot access empty property in field.attach.inc" error (especially when using views aggregation) a likely cause is #1461536: Fatal error when using aggregation and a field is not attached to all entities in the view.

I'm not sure that's actually the cause of all the errors discussed in this issue, but I figured it was at least worth linking to it.

killtheliterate’s picture

@pimmy I suggested the 'und' for debug purposes only, as it's a bad thing to use. Just sayin'
Wish I could be more helpful.

Pimmy’s picture

Thanks David, that fixed the error message, however the aggregation still didnt work. I've submitted a ticket (hopefully not a false positive): http://drupal.org/node/1463500

Thanks once again to both of you,

Pimmy

ndvo’s picture

I had a similar issue.
The problem was basically that the access to the node was being denied.

I realized it was due to a hook_node_access implementation that was not filtering by $op, thus denying access to the node as it was being created.
Hope it helps someone.