Problem/Motivation
Steps to reproduce:
- Standard installation of Drupal 8
- Configure the Image field on the Article content type to add a default image
- Create an article node with no image
- Navigate to the article node
- See a PHP notice:
Notice: Trying to get property of non-object in template_preprocess_field() (line 1523 of core/includes/theme.inc).
Proposed resolution
The most obvious solution is to add back the is_object() check removed in #2550225: quickedit_test_entity_view_alter() creates a non compliant field render array, but there may be a more correct solution.
Remaining tasks
Patch
Tests
Review
User interface changes
n/a
API changes
n/a
Data model changes
n/a
Original report by @jonasdk
I have article content type with an image and I have assigned a default value to the image under Manage fields. I started to get the error (in the bottom of this text) in my printout when loading a page that haven't had a image assigned to its node. When I assigned an image to the node the error message disappears.
The strange thing is that I can see that it is related to the label in Manage display being hidden. When I set it to any other settings Above, Inline or Visually hidden the error message disappears to. Is this a freak error on my setup or something that other have seen?
Notice: Trying to get property of non-object in template_preprocess_field() (line 1526 of core/includes/theme.inc).
template_preprocess_field(Array, 'field', Array)
Drupal\Core\Theme\ThemeManager->render('field', Array)
Drupal\Core\Render\Renderer->doRender(Array)
Drupal\Core\Render\Renderer->doRender(Array, )
Drupal\Core\Render\Renderer->render(Array)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1)
__TwigTemplate_a02dce0f9b24214a75ff925dd6dc1741e87fd96dd320e87a8a727ae08c036877->doDisplay(Array, Array)
Twig_Template->displayWithErrorHandling(Array, Array)
Twig_Template->display(Array)
Twig_Template->render(Array)
twig_render_template('themes/custom/THEMENAME/templates/content/node.html.twig', Array)
Drupal\Core\Theme\ThemeManager->render('node', Array)
Drupal\Core\Render\Renderer->doRender(Array, )
Drupal\Core\Render\Renderer->render(Array, )
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}()
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1)
Drupal\page_cache\StackMiddleware\PageCache->fetch(Object, 1, 1)
Drupal\page_cache\StackMiddleware\PageCache->lookup(Object, 1, 1)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1)
Stack\StackedHttpKernel->handle(Object, 1, 1)
Drupal\Core\DrupalKernel->handle(Object)
Comment | File | Size | Author |
---|---|---|---|
#15 | 2604220-fallback_image_notice-15.patch | 1.69 KB | yched |
#3 | default_image_with-2604220-3.patch | 629 bytes | star-szr |
#7 | 2604220-fallback_image_notice-7.patch | 639 bytes | yched |
#9 | 2604220-fallback_image_notice-test-only-9.patch | 666 bytes | yched |
#13 | 2604220-13.patch | 1.55 KB | swentel |
Comments
Comment #2
jonasdk CreditAttribution: jonasdk as a volunteer commentedPS. my node.html.twig is taken from the core theme classy and I have removed the part about meta data, apart from that everything have been left alone (even the comments).
Comment #3
star-szrNot sure if this is the right fix but it's a fix. Thanks for the report @jonasdk!
Comment #4
dawehnerWhile 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
we should be able to check for a specific interface here.
Comment #5
star-szrAgreed @dawehner, this definitely needs more digging but the patch and steps to reproduce hopefully show where to start digging :)
Comment #6
swentel CreditAttribution: swentel commentedHmm a bit further in the same function, this happens
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' ?
Comment #7
yched CreditAttribution: yched commented/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 :
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 ?Comment #8
yched CreditAttribution: yched commentedAlso, 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 :
This doesn't render template_preprocess_field(), and thus doesn't detect the issue.
Comment #9
yched CreditAttribution: yched commentedWeird, 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 ?
Comment #10
Jonathan Lauer CreditAttribution: Jonathan Lauer commentedI have the same issue. Test and review
Comment #11
fomenkoandrey CreditAttribution: fomenkoandrey commenteddrupal 8.0.1
any modules.
PHP7
i have notice:
patch 2604220-fallback_image_notice-test-only-9.patch dont help me
Comment #12
joelpittet@yched usually it does report notices from what I recall.
Comment #13
swentel CreditAttribution: swentel commented'fixing' the tests - the label isn't hidden by default in the view display :)
Comment #15
yched CreditAttribution: yched commentedOh 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 ?
Comment #16
star-szrLooks good to me, thanks!
Comment #17
fomenkoandrey CreditAttribution: fomenkoandrey commentedworks for me
Comment #18
catchI 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!