PHP notice for single value image field configured with a default image (no image present) and a hidden label

Not sure if this is the right fix but it's a fix. Thanks for the report @jonasdk!

While notices can be annoying sometimes, they are often a sign of an actual bug somewhere else in the system. Did you checked how this happens?
Can we check for that condition earlier so it never gets passed in? Given

foreach ($entity->get($name) as $item) {
            $item->_attributes = array();
          }

we should be able to check for a specific interface here.

Agreed @dawehner, this definitely needs more digging but the patch and steps to reproduce hopefully show where to start digging :)

Hmm a bit further in the same function, this happens

    $variables['items'][$delta]['attributes'] = !empty($element['#items'][$delta]->_attributes) ? new Attribute($element['#items'][$delta]->_attributes) : clone($default_attributes);

So I guess we can just do !empty($element['#items'][0]->_attributes) here. Or we have to declare an empty attribute property more upstream in the code somewhere, which in some way sounds sane too, but maybe a little 'overheadish' ?

/me shakes fist at the "fallback image" feature, long-standing pita :-)

So the thing here is that the field *is* empty, so $element['#items'][0] is NULL.
Typically, in such cases the formatters return nothing, and there is no render array for the field to begin with (so the field template and template_preprocess_field() do not run at all)

But formatters do have the possibility to run and return something for empty fields, and that's how the "fallback image" works.
In this case, there is a render array for the field, with :

'#theme' => 'field',
'#items' => a FieldItemList with no items,
'0' => the render array returned by the formatter...

This case where $element[0] exists while not corresponding to an actual item, is like totally not the most common case, and can be overlooked :-/

Note that template_preprocess_field() has an empty() check on $element['#items'][$delta]->_attributes a couple lines below, so we might as well fix this by doing the same check here ?

Also, ImageFieldDefaultImagesTest is supposed to test the "fallback image" behavior, but it doesn't actually render the fields, it just builds the render array, and checks that $render[$field_name][0] contains the expected data :

$article_built = $this->drupalBuildEntityView($article = $node_storage->load($article->id()));
$this->assertEqual(
  $article_built[$field_name][0]['#item']->target_id,
  $default_images['field']->id()
);

This doesn't render template_preprocess_field(), and thus doesn't detect the issue.

Weird, I would have thought that this would be enough to test the bug, but this seems to pass.
WebTestBase::drupalGet() is supposed to show notices and trigger a fail on them, right ?

I have the same issue. Test and review

drupal 8.0.1
any modules.
PHP7
i have notice:

Notice: Trying to get property of non-object in template_preprocess_field() (line 1523 of core/includes/theme.inc)

patch 2604220-fallback_image_notice-test-only-9.patch dont help me

@yched usually it does report notices from what I recall.

'fixing' the tests - the label isn't hidden by default in the view display :)

Oh d'oh, thanks @swentel ! - I forgot that the fail was only triggered by the label being hidden...

Just adding a comment to the test then, since it's not exactly self-explanatory why we do this :-)

Then I guess this should be RTBCable ?

Looks good to me, thanks!

works for me

I dropped the reference back to this issue - comment is self-explanatory and git blame gets you back here if you need it.

Otherwise looks great so committed/pushed to 8.1.x and cherry-picked to 8.0.x, thanks!