This is not a bug report

The bug report is here: #3125827: Prevent leftover fields from causing errors like "Call to a member function getLabel() after enabling layout_builder".
That issue needs help with reliably reproducing this bug outside of a migration.
This is a support request that includes a workaround patch to help you identify the malformed config on your site.

Original report by adubovskoy

Existing drupal 8 site (upgraded from 8.2.x to 8.3, 8.4, 8.5). Current version 8.5.5 . If I enable layout_builder, then:

Error: Call to a member function getLabel() on null in Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions() (line 111 of /home/agwophqf/public_html/core/modules/layout_builder/src/Plugin/Derivative/FieldBlockDeriver.php) #0 ...

Issue fork drupal-2985882

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

adubovskoy created an issue. See original summary.

tim.plunkett’s picture

I'm not sure how this would ever come about, since it means that entityFieldManager->getFieldMap() is returning fields that don't exist in entityFieldManager->getFieldDefinitions().

But, here's a patch anyway.

Can you reproduce in 8.6?

tim.plunkett’s picture

Status: Needs review » Postponed (maintainer needs more info)
jborgesr’s picture

Hi, I have the same error in 8.5.6, with the patch it works fine. Thank you very much.

tim.plunkett’s picture

kducharm’s picture

@tim.plunkett I was able to reproduce this on 8.6.1 and it failed on $entity_type_id = 'node', $bundle = 'article', and $field_name = 'body'. I tried the patch at http://cgit.drupalcode.org/drupal/commit/?id=e2ffcb5e03 and it still occurred after a cache rebuild - If I put a breakpoint at the "continue" in this patch:

$this->entityFieldManager->getFieldMap()['node']
has a "body" field definition but:
$this->entityFieldManager->getBaseFieldDefinitions('node')
does not on my current project's codebase.

While the patch here gets around it, it would be nice to know why even with the cache tag addition that there is a missing field in the definition. No other field appears to be missing definitions in "article" bundle besides body.

tjtj’s picture

This bit me upgrading from 7 to 8.6.3. Why hasn't it been fixed? Drupal users should not have to run down patches. D8 administration is already too hard.

tim.plunkett’s picture

Version: 8.5.5 » 8.7.x-dev
Issue tags: +Needs tests

This issue is marked Postponed (maintainer needs more info).

Please include more information on how you hit this bug, how someone else can reliably reproduce it, and whether the patch helped.

Only then can we understand it well enough to write test coverage, so that it can be committed.

labboy0276’s picture

I just migrated a small site that had a few content types. I enabled layout builder and I received the error on the ticket when I went to /admin/structure/types . My issues were similar to those in #6. This patch fixed the issue in 8.6.3 as well

tim.plunkett’s picture

lukasss’s picture

I see this. 8.6.5
#2 working for me.
Tnx.

lukasss’s picture

I have a field storage (field.storage.user.field_111), but there is no field (field.field.user.user.field_111), I do not know how this could happen, that's why this error occurs.

andypost’s picture

Status: Postponed (maintainer needs more info) » Needs work

I bet fields can prevent delete its storage on last field deleted, so could be covered with test

tim.plunkett’s picture

@andypost What component should this go in then, as the bug is not related to Layout Builder, only one way of exposing it?

andypost’s picture

IIRC the bug could be replicated
1) create a field storage with persist_with_no_fields: true
2) add and delete field to test entity type
3) make sure that field gone but storage there
4) check with layout builder is no other way catch it with current field_ui

scotwith1t’s picture

Same here with 8.6.5. Patch in #2 fixed for us. Thanks!

tim.plunkett’s picture

Assigned: Unassigned » andypost

#15 isn't quite "steps to reproduce" but could possibly be the basis of some test code.

Sam152’s picture

This happens when deploying groups of configuration that include a new bundle, new fields and a layout builder based display. I haven't been able to replicate this in a test.

andypost’s picture

andypost’s picture

Assigned: andypost » Berdir

That's why \Drupal\Core\Entity\EntityFieldManager::buildFieldStorageDefinitions() does some trick instead of loading storage entities

I bet we need @berdir here

andypost’s picture

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Pancho’s picture

Priority: Normal » Major

Even though layout builder is still considered experimental, this bug renders a site unusable, so is major at the very least. If we can't track down the underlying issue, D8.7 should at least ship with patch #2 as a stop-gap.

Before the fatal error occurs, there is a notice hinting at the culprit:

Notice: Undefined index: field_float in Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions() (line 100 of /var/www/html/testing/web/core/modules/layout_builder/src/Plugin/Derivative/FieldBlockDeriver.php). => Array
[...]
The website encountered an unexpected error. Please try again later.
Error: Call to a member function getLabel() on null in Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions() (line 111 of core/modules/layout_builder/src/Plugin/Derivative/FieldBlockDeriver.php).
[...]

Btw, as most of the others, I hit the error by installing layout_builder. Culprit was a plain float field that btw. is really used in two node types and a view, not only in storage.

As patch #2 at least suppresses the error, I managed to get closer to the underlying bug, which seemed to go away (with or without patch) once I removed the field from the view (which is aggregated, grouped on the field's value column).

Readding the field to the view seemed to bring back the very same error, until applying patch #2 again. This seemed reproducible again and again. However, I'm not so sure about this anymore.

What I'm sure about is that $this->entityFieldManager->getFieldMap()['node'] does include:

'field_float' => array(2)
    'type' => string(5) "float"
    'bundles' => array(2)
        'child' => string(5) "child"
        'parent' => string(6) "parent"

and $this->entityFieldManager->getFieldDefinitions('node', 'child') does so, too:

'field_float' => Drupal\field\Entity\FieldConfig(35)
        contents Available methods (133) 
        protected deleted -> boolFALSE
        protected fieldStorage -> NULL
        protected id -> string(22) "node.child.field_float"
        protected field_name -> string(11) "field_float"
        protected field_type -> string(5) "float"
        protected entity_type -> string(4) "node"
        protected bundle -> string(5) "child"
        protected label -> string(5) "Float"
        protected description -> string(0) ""
        protected settings -> array(4)
            'min' => NULL
            'max' => NULL
            'prefix' => string(0) ""
            'suffix' => string(0) ""
        protected required -> boolFALSE
        protected translatable -> boolFALSE
        protected default_value -> array(0)
        protected default_value_callback -> string(0) ""
        protected itemDefinition -> NULL
        protected constraints -> array(0)
        protected propertyConstraints -> array(0)
        protected originalId -> string(22) "node.child.field_float"
        protected status -> boolTRUE
        protected uuid -> string(36) "86a4ef4c-e699-45aa-807a-7f7a42c333a8"
        private isUninstalling -> boolFALSE
        protected langcode -> string(2) "en"
        protected third_party_settings -> array(0)
        protected _core -> array(0)
        protected trustedData -> boolFALSE
        protected entityTypeId -> string(12) "field_config"
        protected enforceIsNew -> NULL
        protected typedData -> NULL
        protected cacheContexts -> array(1)
            string(28) "languages:language_interface"
        protected cacheTags -> array(0)
        protected cacheMaxAge -> integer-1
        protected _serviceIds -> array(0)
        protected _entityStorages -> array(0)
        protected dependencies -> array(1)
            'config' => array(2)
                string(30) "field.storage.node.field_float"
                string(15) "node.type.child"
        protected isSyncing -> boolFALSE

but $this->entityFieldManager->getFieldDefinitions('node', 'parent') does not have a field_float.

So this might simply have to to something with config fields that are used on several node types?

If you can't reproduce the bug, feel free to tell me how I can further help you. I might find some time to look into it tonight, but can't promise.

Pancho’s picture

Weird.

if (empty($field_definitions[$field_name])) {
dsm("Field name: $field_name");
dsm("Entity type: $entity_type_id");
dsm("Bundle: $bundle");
continue;
}
gives me two config fields that according to getFieldMap() should be defined in the "child" bundle and used as well by the "parent" bundle, but that don't appear in getFieldMap('node', 'parent') and consequently have disappeared from both node form and Field UI:

Field name: field_float
Entity type: node
Bundle: parent

Field name: field_term
Entity type: node
Bundle: parent

I guess it's not going to be easy to track down where this inconsistency may come from. But maybe someone has an idea.

tim.plunkett’s picture

Graber’s picture

I also have such strange field data leftovers, in my case both the field.storage and field.field config definitions are long gone along with the field itself, but looks like something is still left in the db and not purged (drush entup also shows nothing to be updated).

devarch’s picture

I have the same situation as described in the initial report. I've started with a Drupal 8.3 then upgraded through 8.4, 8.5, 8.6 and now I am on 8.7. Seeing that the layout builder is not experimental anymore I wanted to replace all panels customizations with the core functionality, but when I enabled the core Layout builder I got the same error.

Placing some debug code in the FieldBlockDeriver.php, when the error occurs we have the following values (with some context before the error):

bundle=video entity_type_id=media field_name=status
bundle=image entity_type_id=media field_name=uid
bundle=video entity_type_id=media field_name=uid
bundle=image entity_type_id=media field_name=name
bundle=video entity_type_id=media field_name=name
bundle=image entity_type_id=media field_name=thumbnail
bundle=video entity_type_id=media field_name=thumbnail
bundle=image entity_type_id=media field_name=created
bundle=video entity_type_id=media field_name=created
bundle=image entity_type_id=media field_name=changed
bundle=video entity_type_id=media field_name=changed
bundle=image entity_type_id=media field_name=default_langcode
bundle=video entity_type_id=media field_name=default_langcode
bundle=image entity_type_id=media field_name=revision_default
bundle=video entity_type_id=media field_name=revision_default
bundle=image entity_type_id=media field_name=revision_translation_affected
bundle=video entity_type_id=media field_name=revision_translation_affected
bundle=image entity_type_id=media field_name=field_image
bundle=video entity_type_id=media field_name=field_media_video_embed_field
bundle=audio entity_type_id=media field_name=field_media_audio_file
Then the error occurs.

So it seems that for the field_media_audio_file there is no field definition.

I should mention that during the Drupal upgrades I have migrated at some point from the media contributed module to the media in core. Maybe this migration left some residual info.

Applying the patch from #2 allowed me to get over the error, and I have modified it a bit to print all the fields without definitions and here is the list (all of them related to media):

bundle=audio entity_type_id=media field_name=field_media_audio_file
bundle=file entity_type_id=media field_name=field_media_file
bundle=image entity_type_id=media field_name=field_media_image
bundle=remote_video entity_type_id=media field_name=field_media_oembed_video
bundle=video entity_type_id=media field_name=field_media_video_file 

Please let me know if you need me to test something else.

Road Kill’s picture

#2 did not work for me but the culprit for me was the duration field if that help anyone. I can add other field like date or year only field without any errors.

The website encountered an unexpected error. Please try again later.
Error: Class 'Drupal\duration_field\Plugin\Validation\Constraint\GraularityStringInterface' not found in Drupal\duration_field\Plugin\Validation\Constraint\GranularityStringConstraintValidator->isGranularityString() (line 46 of modules/contrib/duration_field/src/Plugin/Validation/Constraint/GranularityStringConstraintValidator.php).

Drupal\duration_field\Plugin\Validation\Constraint\GranularityStringConstraintValidator->isGranularityString('y:m:d:h:i:s') (Line: 28)
Drupal\duration_field\Plugin\Validation\Constraint\GranularityStringConstraintValidator->validate('y:m:d:h:i:s', Object) (Line: 191)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateConstraints('y:m:d:h:i:s', '000000004990ad71000000005aaac006', Array) (Line: 146)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateNode(Object) (Line: 153)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateNode(Object) (Line: 153)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validateNode(Object, Array, 1) (Line: 99)
Drupal\Core\TypedData\Validation\RecursiveContextualValidator->validate(Object, Array, NULL) (Line: 90)
Drupal\Core\TypedData\Validation\RecursiveValidator->validate(Object, Array) (Line: 368)
Drupal\Core\Plugin\Context\ContextDefinition->isSatisfiedBy(Object) (Line: 77)
Drupal\Core\Plugin\Context\ContextHandler->Drupal\Core\Plugin\Context\{closure}(Object)
array_filter(Array, Object) (Line: 78)
Drupal\Core\Plugin\Context\ContextHandler->getMatchingContexts(Array, Object) (Line: 65)
Drupal\Core\Plugin\Context\ContextHandler->checkRequirements(Array, Array) (Line: 31)
Drupal\Core\Plugin\Context\ContextHandler->Drupal\Core\Plugin\Context\{closure}(Object)
array_filter(Array, Object) (Line: 37)
Drupal\Core\Plugin\Context\ContextHandler->filterPluginDefinitionsByContexts(Array, Array) (Line: 92)
Drupal\layout_builder\SectionStorage\SectionStorageManager->findByContext(Array, Object) (Line: 123)
Drupal\layout_builder\InlineBlockEntityOperations->getSectionStorageForEntity(Object) (Line: 38)
Drupal\layout_builder\InlineBlockEntityOperations->isLayoutCompatibleEntity(Object) (Line: 169)
Drupal\layout_builder\InlineBlockEntityOperations->handlePreSave(Object) (Line: 206)
layout_builder_entity_presave(Object, 'field_config')
call_user_func_array('layout_builder_entity_presave', Array) (Line: 403)
Drupal\Core\Extension\ModuleHandler->invokeAll('entity_presave', Array) (Line: 349)
Drupal\Core\Config\Entity\ConfigEntityStorage->invokeHook('presave', Object) (Line: 491)
Drupal\Core\Entity\EntityStorageBase->doPreSave(Object) (Line: 445)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 263)
Drupal\Core\Config\Entity\ConfigEntityStorage->save(Object) (Line: 394)
Drupal\Core\Entity\EntityBase->save() (Line: 613)
Drupal\Core\Config\Entity\ConfigEntityBase->save() (Line: 379)
Drupal\field_ui\Form\FieldStorageAddForm->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 590)
Drupal\Core\Form\FormBuilder->processForm('field_ui_field_storage_add_form', Array, Object) (Line: 319)
Drupal\Core\Form\FormBuilder->buildForm('field_ui_field_storage_add_form', Object) (Line: 93)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Anybody’s picture

Same situation here like for @devarch in #27, but just the other way around. We're using layout_builder since some days successfully. Now we also wanted to migrate from media_entity to media in core and this message appears with a WSOD. #2 brought it alive but we should further look for the reasons. I'll report back as soon as I found something helpful.

jazzfiction’s picture

I am also getting this error. It happened to me because Lighting Layout started requiring Layout Builder. Here are the two log messages that where recorded when was I testing and enabled the module:

Notice: Undefined index: field_testimonial in Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions() (line 101 of core/modules/layout_builder/src/Plugin/Derivative/FieldBlockDeriver.php).
Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions(Array) (Line: 101)
Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives(Array) (Line: 87)
Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions() (Line: 284)
Drupal\Core\Plugin\DefaultPluginManager->findDefinitions() (Line: 175)
Drupal\Core\Plugin\DefaultPluginManager->getDefinitions() (Line: 22)
Drupal\Core\Plugin\DefaultPluginManager->getDefinition('system_breadcrumb_block') (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('system_breadcrumb_block', Array) (Line: 76)
Drupal\Component\Plugin\PluginManagerBase->createInstance('system_breadcrumb_block', Array) (Line: 62)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->initializePlugin('system_breadcrumb_block') (Line: 57)
Drupal\block\BlockPluginCollection->initializePlugin('system_breadcrumb_block') (Line: 80)
Drupal\Component\Plugin\LazyPluginCollection->get('system_breadcrumb_block') (Line: 45)
Drupal\block\BlockPluginCollection->get('system_breadcrumb_block') (Line: 83)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->setConfiguration(Array) (Line: 99)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->addInstanceId('system_breadcrumb_block', Array) (Line: 55)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->__construct(Object, 'system_breadcrumb_block', Array) (Line: 34)
Drupal\block\BlockPluginCollection->__construct(Object, 'system_breadcrumb_block', Array, 'seven_breadcrumbs') (Line: 156)
Drupal\block\Entity\Block->getPluginCollection() (Line: 145)
Drupal\block\Entity\Block->getPlugin() (Line: 118)
Drupal\block\BlockAccessControlHandler->checkAccess(Object, 'view', Object) (Line: 105)
Drupal\Core\Entity\EntityAccessControlHandler->access(Object, 'view', Object, 1) (Line: 369)
Drupal\Core\Entity\EntityBase->access('view', NULL, 1) (Line: 56)
Drupal\block\BlockRepository->getVisibleBlocksPerRegion(Array) (Line: 137)
Drupal\block\Plugin\DisplayVariant\BlockPageVariant->build() (Line: 259)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 156)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 67)
Drupal\simple_oauth\HttpMiddleware\BasicAuthSwap->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
[10-Jul-2019 13:40:52 America/Denver] Error: Call to a member function getLabel() on null in /var/www/html/ekr-site-dev/htdocs/docroot/core/modules/layout_builder/src/Plugin/Derivative/FieldBlockDeriver.php on line 112 #0 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(101): Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions(Array)
#1 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(87): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives(Array)
#2 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(284): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions()
#3 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(175): Drupal\Core\Plugin\DefaultPluginManager->findDefinitions()
#4 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryCachedTrait.php(22): Drupal\Core\Plugin\DefaultPluginManager->getDefinitions()
#5 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Core/Plugin/Factory/ContainerFactory.php(16): Drupal\Core\Plugin\DefaultPluginManager->getDefinition('system_breadcru...')
#6 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Component/Plugin/PluginManagerBase.php(76): Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('system_breadcru...', Array)
#7 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Core/Plugin/DefaultSingleLazyPluginCollection.php(62): Drupal\Component\Plugin\PluginManagerBase->createInstance('system_breadcru...', Array)
#8 /var/www/html/ekr-site-dev/htdocs/docroot/core/modules/block/src/BlockPluginCollection.php(57): Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->initializePlugin('system_breadcru...')
#9 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Component/Plugin/LazyPluginCollection.php(80): Drupal\block\BlockPluginCollection->initializePlugin('system_breadcru...')
#10 /var/www/html/ekr-site-dev/htdocs/docroot/core/modules/block/src/BlockPluginCollection.php(45): Drupal\Component\Plugin\LazyPluginCollection->get('system_breadcru...')
#11 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Core/Plugin/DefaultSingleLazyPluginCollection.php(83): Drupal\block\BlockPluginCollection->get('system_breadcru...')
#12 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Core/Plugin/DefaultSingleLazyPluginCollection.php(99): Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->setConfiguration(Array)
#13 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Core/Plugin/DefaultSingleLazyPluginCollection.php(55): Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->addInstanceId('system_breadcru...', Array)
#14 /var/www/html/ekr-site-dev/htdocs/docroot/core/modules/block/src/BlockPluginCollection.php(34): Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->__construct(Object(Drupal\Core\Block\BlockManager), 'system_breadcru...', Array)
#15 /var/www/html/ekr-site-dev/htdocs/docroot/core/modules/block/src/Entity/Block.php(156): Drupal\block\BlockPluginCollection->__construct(Object(Drupal\Core\Block\BlockManager), 'system_breadcru...', Array, 'seven_breadcrum...')
#16 /var/www/html/ekr-site-dev/htdocs/docroot/core/modules/block/src/Entity/Block.php(145): Drupal\block\Entity\Block->getPluginCollection()
#17 /var/www/html/ekr-site-dev/htdocs/docroot/core/modules/block/src/BlockAccessControlHandler.php(118): Drupal\block\Entity\Block->getPlugin()
#18 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Core/Entity/EntityAccessControlHandler.php(105): Drupal\block\BlockAccessControlHandler->checkAccess(Object(Drupal\block\Entity\Block), 'view', Object(Drupal\Core\Session\AccountProxy))
#19 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Core/Entity/EntityBase.php(369): Drupal\Core\Entity\EntityAccessControlHandler->access(Object(Drupal\block\Entity\Block), 'view', Object(Drupal\Core\Session\AccountProxy), true)
#20 /var/www/html/ekr-site-dev/htdocs/docroot/core/modules/block/src/BlockRepository.php(56): Drupal\Core\Entity\EntityBase->access('view', NULL, true)
#21 /var/www/html/ekr-site-dev/htdocs/docroot/core/modules/block/src/Plugin/DisplayVariant/BlockPageVariant.php(137): Drupal\block\BlockRepository->getVisibleBlocksPerRegion(Array)
#22 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(259): Drupal\block\Plugin\DisplayVariant\BlockPageVariant->build()
#23 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(117): Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch))
#24 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch))
#25 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#26 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#27 /var/www/html/ekr-site-dev/htdocs/vendor/symfony/http-kernel/HttpKernel.php(156): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent))
#28 /var/www/html/ekr-site-dev/htdocs/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#29 /var/www/html/ekr-site-dev/htdocs/docroot/modules/contrib/simple_oauth/src/HttpMiddleware/BasicAuthSwap.php(67): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Drupal\simple_oauth\HttpMiddleware\BasicAuthSwap->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#31 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#32 /var/www/html/ekr-site-dev/htdocs/docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#33 /var/www/html/ekr-site-dev/htdocs/docroot/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#34 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#35 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#36 /var/www/html/ekr-site-dev/htdocs/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#37 /var/www/html/ekr-site-dev/htdocs/docroot/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#38 /var/www/html/ekr-site-dev/htdocs/docroot/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#39 {main}

In looking at the list of entity fields, there is one field_testimonial used in a paragraph that references another paragraph, but nothing for field_testimonial in a node. This site is a migrated clone of another site which does have a Testimonial content type, and that has a field_testimonial. Somewhere, something is referencing a field for a content type that doesn't exist in this site, but remnants of it are still the database somewhere.

I did an experiment. Recreated the missing content type with its associated testimonial field. Once I created it, I then attempted to install Layout Builder. This time the install succeeded. I then uninstalled Layout Builder, deleted the testimonial field and its associated content type, and tried to install Layout Builder again. Again, the install succeeded.

I don't know enough about Drupal's database structure to know what associations or cruft got cleaned up by me doing the experiment. I also didn’t test just tying to add the field testimonial field to one of the existing content types to see if I would have had the same results.

I hope this helps a little.

krima’s picture

I may have found a possible source of the problem.
When I cleaned the cache I had this error: FieldStorageConfigInterface :: getBundles (): entity type: node, bundle: image, field name: body
Eliminating the error, I installed Layout Builder without problems and works properly. Here the solution: https://www.drupal.org/project/drupal/issues/2916266#comment-12301574

Vj’s picture

I am able to reproduce issue with following steps

  1. Clean Drupal8 install then enable layout builder module
  2. Go to admin/structure/types/manage/article/display enable "Use Layout Builder" & "Allow each content item to have its layout customized."
  3. Go to admin/structure/types/manage/article/display click on "manage layout" button and remove all the fields/sections.
  4. Create article, on view its shows WSOD

error in reports log:
Error: Call to a member function getRegionNames() on null in Drupal\layout_builder\QuickEditIntegration->entityViewAlter() (line 134 of /var/www/drupalvm/drupal/web/core/modules/layout_builder/src/QuickEditIntegration.php)

Adding following code in core/modules/layout_builder/src/QuickEditIntegration.php resolves issue for me.

if (empty($layout)) {
          return;
      }
tim.plunkett’s picture

joarferme’s picture

Hi, I have the same error in 8.7.7 when i tried to move from Panelizer to Layout Builder.
After I uninstalled Panelizer the systems works good and when I enable Layout Builder the system crash.
The patch #2 works fine. Thank you very much.

brisath’s picture

New to Drupal 8 after converting a site from 7, and getting white screen after activating Layout Builder on 8.7.7. Is there any non-patch solution? I'm stuck right now and not impressed with Drupal 8 so far.

renguer0’s picture

Same problem here. It's really annyoning that I can't install a module to manage the layout from the site without breaking it (same applies to Paragraphs).

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

tonytheferg’s picture

Same here. Tried to enable layout builder on a site migrated from D7 to D8. Currently running 8.7.8

This error: Error: Call to a member function getLabel() on null in Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions()

There is this notice from what seems to be an orphaned field from Drupal 7 which may be hanging on: Notice: Undefined index: commerce_bundle_unit_quantity in Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions()

For what it is worth, the patch in #2 worked to enable the module. However, when saving a layout, the "you have unsaved changes" warning remains and the layout is not created. Bum deal...

agilman’s picture

#2 works for me, too.

chrisrockwell’s picture

I got this same error on a new install of 8.7.8 *after* creating a module and entity using drupal console, then enabling the module. The patch in #2 solves it.

Mirakolous’s picture

#2 works for me after re-rolling patch for 8.7.10

Edit: Forgot this is a core module and should get patched from drupal root

Mirakolous’s picture

Trying this again...

Mirakolous’s picture

Don't judge me #notspam

mradcliffe’s picture

I also was able to reproduce similar to @ToneLoc's comment #38. This is similar, but not the same, as issues I saw in #3008202: Migrating more than 1 entity reference field instance fails. NULL Field definitions happen frequently for me after Drupal 7 to Drupal 8 field migration - particularly with entity reference fields.

Hacking layout_builder to check if $field_defiintion is NULL and continuing if it was got me a working site again.

I added the Needs issue summary update tag because the issue summary could be updated with some of the examples to reproduce following the issue summary template.

amateescu’s picture

Title: Error: Call to a member function getLabel() after enable layout_builder » Error: Call to a member function getLabel() after enabling layout_builder
Dave Kopecek’s picture

Can confirm that #43 worked for me. THANK YOU @Mirakolous!! Site (8.7.10) was migrated from D6 to D8 around 8.3 and is being refactored with Layout Builder. Error occurred when comment module was enabled.

I'm not confident enough to give it a RTBC since I really don't yet understand the underlying issue, but I give it a big "Thumbs Up"! It made the white-screen go away!

tim.plunkett’s picture

#43 is the same patch as #2 which is 1 year and 4 months old.

There are still not clear steps to reproduce the problem, other than "migrate from a broken state".
Without non-migration based steps, or a clear understanding of what went wrong with the site before migrating, we can't write test coverage.
And without test coverage, this won't be committed.

mradcliffe’s picture

I agree that the patch is a band-aid around some other cause.

However I do not agree that there is necessarily an initial "broken state". Drupal core migrate is one cause of why a field definition may not be in the entity's field definition cache despite having data for that field. There is no broken state with this test failure as having one entity reference field on two bundles is a valid state for a Drupal 7 or Drupal 8 site to be in.

I do also think that defensive coding here might be a good thing because the entity, cache, and migration systems are so complex. There is no guarantee made by EntityFieldManager that a particular field will exist in the return array of field definitions. All that it guarantees is two return states - build from scratch (guaranteed to be right) or get from cache if the field storage definitions on the entity field manager merely exist. If doesn't check consistency. That is probably by design and important for performance.

So the right fix would be to fix the Drupal entity, cache and migration systems, but the simpler work around would be for defensive programming when working with arrays.

ab2211’s picture

Same error here after Update to 8.8.0. Patch #2 helped, but now I have an 500er error. Ok, seems to be an error with the htaccess. So, patch #2 worked fully.

dpi’s picture

Getting this simply after adding a new field + instance. First time the new field is config synced to a new site this error is thrown.

dpi’s picture

Assigned: Berdir » Unassigned
longwave’s picture

Marked #3106756: An unexpected error as duplicate

ravi.shankar’s picture

I have added a re-roll of patch #43. It still needs tests.

Rajendar Reddy’s picture

I've been facing this issue while enabling Layout Builder module on 8.8.1. #53 works for me.

Christopher Riley’s picture

53 took care of an issue I was having as well.

swatichouhan012’s picture

Status: Needs work » Needs review

@ravi.shankar please move issue in Needs review after patch apply.

jlancaster’s picture

Confirming patch #53 fixes issue in D8 8.8.4 after triggering this bug through a drush features-revert.

joshf’s picture

I encountered this error when running `drush updb` after upgrading drupal/core from 8.5.x to 8.7.x. #53 fixed the problem for me. Thanks for the patch @ravi.shankar and @Mirakolous and everyone else.

webdrips’s picture

#53 worked for me for the following error:

Error: Call to a member function getLabel() on null in Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions()

Rajab Natshah’s picture

#53 fixes the issue
Thank you :)

Rajab Natshah’s picture

Status: Needs review » Reviewed & tested by the community
tim.plunkett’s picture

Status: Reviewed & tested by the community » Needs work

It cannot be RTBC as this still needs tests, steps to reproduce, and an issue summary update.
Same as it was in #47.

Also, this should log the broken field, not ignore it forever.

Rajab Natshah’s picture

Issue summary: View changes
Rajab Natshah’s picture

Issue summary: View changes
Rajab Natshah’s picture

Issue summary: View changes
Rajab Natshah’s picture

Issue summary: View changes
tim.plunkett’s picture

@RajabNatshah
When I follow those steps to reproduce, after pressing "Save and manage fields", I am taken to /admin/structure/types/manage/test_content/fields and I see the message "The content type Test Content has been added".
No error. I followed every step as written, and then tried a few other scenarios too. Nothing results in this error for me.

But remember, *me* reproducing the error is not necessary. It's only necessary for an automated test to be written. If I were able to reproduce, I would write it. But anyone could write it.

Rajab Natshah’s picture

Issue summary: View changes
Rajab Natshah’s picture

Thank you Tim for following up.

I do have an Automated Functional Acceptance Testing which captured the issue
https://travis-ci.org/github/Vardot/varbase/jobs/666826158#L1397

You are right I'm not able to reproduce with only Drupal core
It looks like for when we do have languages and content translation

    "drupal/layout_builder_modal": "~1.0",
    "drupal/layout_builder_restrictions": "~2.0",
    "drupal/layout_library": "~1.0",
    "drupal/layout_builder_at": "~2.0",
    "drupal/layout_builder_block_sanitizer": "~1.0",
    "drupal/lb_ux": "~1.0",
    "drupal/bootstrap_layouts": "~5.0"
tim.plunkett’s picture

Can you install a clean version of Drupal, install those modules, and reproduce it with that list?
Then start removing modules from the list, trying each set by itself, until you find the offending module?

But if the whole problem depends on the site you are testing it on (as I suspect), I'm not sure what core can do.

Graber’s picture

This results from field config being broken in db where some field config leftovers are still there while the fields are long gone (and that's the case on a lot of bigger projects developed through earlier versions of Drupal 8). The underlying problem may be even solved now but if someone wants to put time in this, it'd be good to investigate why such leftovers exist and provide an interface to clean up (I did it manually at some point by adding and re-deleting fields that had leftovers identified by adding a debug before the getLabel() is called to get the field name, or even deleting those entries from the key-value table in the db, not sure now which did the trick). The field leftovers don't affect anything else to my knowing so we have just this single bug.

tim.plunkett’s picture

#72 is correct. And yet LB is using the Field APIs as documented, and just so happens to be the only one in core doing so in this particular way.
I'd love to see this fixed at the field level.

devarch’s picture

As I stated in #27 I also have added some logs before getLabel() and it seems that the problems (at least in my situation) comes from the media module, most probably from the migration from the media_module to the media core one, so if that migration was faulted, then a lot of existing sites coming from earlier versions as I did have this problem.

A cleanup idea proposed by @Graber seems a great solution.

renguer0’s picture

I agree. I did come into this problem after deleting some field items when tried to get rid of Paragraphs manually.

tim.plunkett’s picture

Title: Error: Call to a member function getLabel() after enabling layout_builder » Prevent leftover fields from causing errors like "Call to a member function getLabel() after enabling layout_builder"
Component: layout_builder.module » field system
Issue summary: View changes
Status: Needs work » Active
Issue tags: -Needs steps to reproduce, -Needs issue summary update

This is never going to be reproducible, because it's only possible to occur through a failed migration, partial deployment, or from someone directly hacking contrib.

But I can see how any of those 3 scenarios could result in this bug.

I rewrote the issue summary with a new proposal.

Rajab Natshah’s picture

#72 Marcin is right
It could happen with old configs on fresh install too ( in case of installation profiles )
optional and install configs

Rajab Natshah’s picture

I have got two cases to reproduce

It is the Machine name JavaScript generation of the name of the entity type
It is slow if you are very fast and pressed the Save button before it end the error will show up
It is slower now in Drupal 8.8.4 than before

So we only need to wait for AJAX to finish, or not let any Robot or user post while no machine name yet

Correction And I wait for 1 second

@javascript @init @tools @local @development @staging
Scenario: Create Test Content type
  Given I am a logged in user with the "test_super_admin" user
   When I go to "/admin/structure/types/add"
    And I wait
   Then I should see "Add content type"
   When I fill in "Test Content" for "Name"
    And I wait for AJAX to finish
    And I wait for 1 second
    And I press "Save and manage fields"
    And I wait
   Then I should see "The content type Test Content has been added."

@javascript @init @tools @local @development @staging
Scenario: Add Entity Queue Test Queue and use Test Content type
  Given I am a logged in user with the "test_super_admin" user
   When I go to "/admin/structure/entityqueue"
    And I wait
   Then I should see "Add entity queue"
   When I click "Add entity queue"
    And I wait
   Then I should see "Add Entity Queue"
   When I fill in "Test Queue" for "Name"
    And I wait for AJAX to finish
    And I wait for 1 second
    And I click "Entity settings"
    And I wait
   Then I should see "Content type"
   When I check the box "Test Content"
    And I press "Save"
    And I wait
   Then I should see "The entity queue Test Queue has been added."

Failing in Test1

Passing in Test2

It is the HTML input field for Machine name not been present in the form yet

corneliusd’s picture

Just to add my experience, I upgraded a Drupal 7 site to Drupal 8 about 3 months ago and have installed and uninstalled the Layout Builder a few times hoping to use it but encountering similar errors mentioned here. I finally had a strong need to use this module so looked deeper for a fix and found this thread. I'd like to confirm patch in #43 (or #53) got rid of the error for me in 8.8.4. Thanks!

h.paul’s picture

I have tried to apply the patch #53, since I encoutered the same problem. It didn't work for me (drupal 8.8.5); but I'm not sure whether I applied it correctly. I did by composer how described in https://github.com/cweagans/composer-patches/tree/master; in the extra-section I wrote:

"extra": {
    "patches": {
      "drupal/core": {
        "Add startup configuration for PHP server": "https://www.drupal.org/files/issues/2020-01-20/2985882-53.patch"
      }
    }

But I'm not sure whether drupal/core is the correct thing.

Can anybody help me?

corneliusd’s picture

I took the code shown in the patch and just manually applied it to the PHP file directly, replacing the "-" lines with the "+" lines. Probably not the best way and I have to reapply for each upgrade (hoping it'll get fixed permanently some day), but it works.

joshf’s picture

@h.paul your composer.json addition looks right to me; drupal/core is the correct key to use.

The only thing that sticks out as a possible issue is you said you put that new extra block "in the extra-section". Just to clarify, there should only be one level of "extra", at the top level of the composer.json.

tim.plunkett’s picture

Title: Prevent leftover fields from causing errors like "Call to a member function getLabel() after enabling layout_builder" » Workaround for "Call to a member function getLabel() after enabling layout_builder"
Component: field system » layout_builder.module
Category: Bug report » Support request
Issue summary: View changes
Priority: Major » Normal
Issue tags: -Needs tests

Leaving this as a support issue for those concerned with the workaround patch (which has nothing to do with fixing this bug)

Anyone interested in working on a fix for the field system, I opened #3125827: Prevent leftover fields from causing errors like "Call to a member function getLabel() after enabling layout_builder"

devarch’s picture

@tim.plunkett Maybe you know better what are the Drupal procedures and how to classify bugs, BUT to simply brush off a lot of already existing sites that have this problems (granted not from Drupal core fault) it's a very ugly message.

Should I understand the following? "It's not from Drupal core, we don't care if you can upgrade or not to the newer versions, we don't care if you have to permanently patch your code."

As I said earlier, at least in my case, the problem arose most probably from the migration from media-module to the media core one, so I could say it is core related.

If #78 is true, then it IS a core related problem, shouldn't that be fixed? And then again, what about all existing sites affected by #78?

Let's say this bug can happen from bad modules behavior, shouldn't we ask ourselves: why does Drupal core allow them to modify entities and leave them in an "incomplete" state?

Anyway, my 2 cents on the matter.

tim.plunkett’s picture

@devarch
I very much want this bug to be fixed, including for all sites hitting this bug via Layout Builder. In order to do that properly, we need to a new UI to allow site builders to identify misconfigured fields and safely remove them.
That is why I opened a new issue.

I left this issue open so those in need of a fix in the short term can continue to discuss an immediate workaround.
I will expand upon the previous patch, adding a log message to help identify the problematic field.

I only separated the issues to try to let each one progress on its own, instead of trying to stifle the discussion here in favor of a more holistic solution.

I am sorry that I was not clear before about my intentions and that I came across as dismissive of this very real problem.

Anybody’s picture

Thank you very much, Tim. The patch looks good. I'm just wondering if the logged message is clear enough to tell the site admin / developer what to do. Perhaps we should add information what to do or a link for further information, at least to this issue plus notes?

What do you think?

In general RTBC, after discussing the text. I think to log this is a good solution!

tim.plunkett’s picture

I agree we need more text to explain what to do (which as I understand it, is delete the obsolete field_config that is leftover from a migration/upgrade).

But I don't expect this patch to ever be committed. For one thing, this broken field issue is not specific to Layout Builder.
This is a way to get more information about why your site is broken.
Providing a real mechanism to fix it will be accomplished in the other issue I linked above.

renguer0’s picture

Please somebody can explain briefly to us where to read to make a patch that applies auto when we update our core system?

I need to patch in every update and it's really annyoing. Sometimes I forget to do it and I keep around this error for a while.

Thanks for your time. I understand that you need to know how to recreate it in order to merge this patch but we need to use it, commited or not.

cilefen’s picture

renguer0’s picture

@cilefen Thanks. I thought to avoid commit in the php file that patche around here modifies.

I'll take a look into composer-patches too.

dpeamit’s picture

        "patches": {
            "drupal/core": {
                "Workaround for Call to a member function in layout builder":"https://www.drupal.org/files/issues/2020-04-08/2985882-field-85.patch"
            }
        }

Composer update

Freddy Rodriguez’s picture

In my case, this was the initial problem: https://www.drupal.org/project/flexslider/issues/3054938. The mismatched entity and/or field definitions created by other contrib module was breaking the layout_builder on /Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(87): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives(Array)

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

NickDickinsonWilde’s picture

Under some conditions [fresh drush config import of a bunch of field], a cache clear may resolve thing. I don't think that really helps testing, but just in case...

Anybody’s picture

re #92: We for example never used flexslider.

themaurice’s picture

patch #85 tim.plunkett work for me on 8.9.1 thanks

alexmoreno’s picture

Hitting this in Drupal 9 as well. The patch worked like a treat, thanks.

segx’s picture

Ran into this problem when upgrading to v8.9.2. Patch #85 resolved the problem. Thank you!

the_glitch’s picture

patch #85 somewhat fixed it to the point where it no longer white screens but still getting this error.

Tray "Administration menu" opened.The website encountered an unexpected error. Please try again later.
Error: Call to a member function hasOption() on null in layout_builder_system_breadcrumb_alter() (line 336 of core/modules/layout_builder/layout_builder.module).
layout_builder_system_breadcrumb_alter(Object, Object, Array) (Line: 539)
Drupal\Core\Extension\ModuleHandler->alter('system_breadcrumb', Object, Object, Array) (Line: 94)
Drupal\Core\Breadcrumb\BreadcrumbManager->build(Object) (Line: 72)
Drupal\system\Plugin\Block\SystemBreadcrumbBlock->build() (Line: 171)
Drupal\block\BlockViewBuilder::preRender(Array)
call_user_func_array(Array, Array) (Line: 100)
Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_render callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was %s. Support for this callback implementation is deprecated in 8.8.0 and will be removed in Drupal 9.0.0. See https://www.drupal.org/node/2966725', 'silenced_deprecation', 'Drupal\Core\Render\Element\RenderCallbackInterface') (Line: 781)
Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array) (Line: 372)
Drupal\Core\Render\Renderer->doRender(Array, 1) (Line: 200)
Drupal\Core\Render\Renderer->render(Array, 1) (Line: 156)
Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}() (Line: 573)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 157)
Drupal\Core\Render\Renderer->renderPlain(Array) (Line: 171)
Drupal\Core\Render\Renderer->renderPlaceholder('callback=Drupal%5Cblock%5CBlockViewBuilder%3A%3AlazyBuilder&args%5B0%5D=bartik_breadcrumbs&args%5B1%5D=full&args%5B2%5D&token=AQwnsJzk-z-aWB62OCFrGFR2_gLN2DESzAd8gEN1SCI', Array) (Line: 693)
Drupal\big_pipe\Render\BigPipe->renderPlaceholder('callback=Drupal%5Cblock%5CBlockViewBuilder%3A%3AlazyBuilder&args%5B0%5D=bartik_breadcrumbs&args%5B1%5D=full&args%5B2%5D&token=AQwnsJzk-z-aWB62OCFrGFR2_gLN2DESzAd8gEN1SCI', Array) (Line: 547)
Drupal\big_pipe\Render\BigPipe->sendPlaceholders(Array, Array, Object) (Line: 305)
Drupal\big_pipe\Render\BigPipe->sendContent(Object) (Line: 112)
Drupal\big_pipe\Render\BigPipeResponse->sendContent() (Line: 374)
Symfony\Component\HttpFoundation\Response->send() (Line: 20)
tim.plunkett’s picture

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

kattekrab’s picture

Well ullo! I just updated to 9.0.9 and thought it was long past time to check out layout builder.

And BAM! down went my site. Fortunately @cafuego has done some fabbo ops automation for me, so this is not a big deal.

I'll try the patch in #85 and report back.

kattekrab’s picture

Unfortunately the patch won't apply for me, so it looks like I'll have to do more digging to uncover what's causing the issue.
So I guess that means no layout builder for me for me for now.

After installing patch utility, #85 works a treat!

tim.plunkett’s picture

@kattekrab Glad it didn't derail you too much! Can you check your logs? It should have information on which field is causing the problem.

NWOM’s picture

#85 worked amazingly. Thank you! Should we mark this issue as Needs Work or Needs Review since a patch is attached?

tim.plunkett’s picture

This patch is a workaround. See #83 for more.

ouissla’s picture

I had the issue on a website migrated from D7 to D8. I implemented #85 and added a bit of debugging to understand what fields were causing the issue:

kint($bundle);
kint($field_name);

My issues were taxonomy term fields that had not been imported properly. The data was missing. So I deleted the fields from the UI (I can recreate them manually later, and re-import the data if needed). This doesn't fix the issue though as there are still configs in the database referring to those fields, so I then backed up the database, search for those references, and deleted the relevant configs.

I cleared the cache. No issue. I removed the patch, cleared cache and crossed fingers. And it now seems to be working again.

Here you go that's my story. Hope this helps.

zterry95’s picture

#85 patch works on drupal 8.9.

design.er’s picture

#85 patch works perfectly on Drupal 9.1.4.

I agree with #70:
These errors appeared for the first time when I enabled UI and content translation. Before that everything was fine.
I also used the very same Layout Builder setup (modules and fields) on other monolingual projects and never had these errors.

Thank you for your excellent work!
Hopefully we'll see this patch in core soon. :)

berliner’s picture

I found the same issue on a site I migrated from D7 to D9 and my issue was with outdated info in these entries of the key_value table: entity.definitions.bundle_field_map

This issue solved it #2916266: How to fix "non-existent config entity name returned by FieldStorageConfigInterface::getBundles()" .

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

kwfinken’s picture

I have no idea how to reproduce the problem, it just appeared the first time I tried to enable layout builder on a year old site.

I applied patch 85 and it worked perfectly on drupal 8.9.14.

PetDu’s picture

Having the same error too. About reproducing; Im migrating a D7 site to D9. Problems started with the "non-existent config entity name returned by FieldStorageConfigInterface::getBundles()". Or maybe better said that was a strange thing after the migration. The bundle that causes it is the comment_node_simpleads_campaign on the content type SimpleAds. A module that the old D7 didnt use anymore. Deleting the content type that was created after migration didn't help. So I wanted to take a look at that error later and enabled Layout builder.

That gave me the error from this issue

Rest of the site was completly fresh. Only imported the nodes and comments from the D7 site.

Will try the patch

kim.pepper’s picture

Issue tags: +#pnx-sprint
Rajab Natshah’s picture

Status: Active » Needs review
tim.plunkett’s picture

This is not a bug report, it's a support request. This issue has a patch to help those who just want the bug to stop occurring on their site. Anyone that can provide steps to reproduce that start with "Install Drupal", please contribute that over in #3125827: Prevent leftover fields from causing errors like "Call to a member function getLabel() after enabling layout_builder".

Rajab Natshah’s picture

Noted;
Thank you Tim for clearing the path for this issue.
I thought your patch would had been committed to Drupal 9.2.0
Moving the conversion to #3125827: Prevent leftover fields from causing errors like "Call to a member function getLabel() after enabling layout_builder"

kattekrab’s picture

Mmmm. Looks like the patch no longer applies.

tim.plunkett’s picture

@kattekrab, I just checked patch in #85 against both 8.9.x and 9.3.x and it applies cleanly. Which version did you have trouble with?

Also reminder: this is just a workaround/debugging patch for this support request. The linked bug report still needs help!

cafuego’s picture

Sorry @tim.plunkett, my bad. Composer was throwing patch errors at me, which went away after I threw away my lock file. The patch does apply to 9.2.1 and fixes the problem.

lordzik’s picture

Patch from #85 worked and applied cleanly on D9.2.6 and solved big problems with field migration from D7!
I thing it should be commited ASAP.

lordzik’s picture

Status: Active » Reviewed & tested by the community
tim.plunkett’s picture

Status: Reviewed & tested by the community » Active

As I said in #120 and also before that:

this is just a workaround/debugging patch for this support request. The linked bug report still needs help!

BramDriesen’s picture

The workaround also solved the issue for me. Subbed on both issues.

dorianwinterfeld’s picture

I am on a D9.2.6 site, newly migrated from D7. I am having the same issue with Layout Builder. Is there a plan to fix this bug in the near future?

tim.plunkett’s picture

Issue summary: View changes
dorianwinterfeld’s picture

I used the patch from #85 and it works like a charm, but I have a question. From looking at the patch, it should write to a log with the null field name, "Field %field_name exists but is missing...". This would greatly help resolve any errors in the database. But when I look at recent log messages I don't see anything like that error message. Am I missing something?

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

hswong3i made their first commit to this issue’s fork.

hswong3i’s picture

Status: Active » Needs review

PR created from #85

tim.plunkett’s picture

No need for a MR as this is just a patch people can reference while waiting for someone to help debug the actual issue.

hstoellinger’s picture

I have the same problem when upgrading from D 9.3.0 (fully functional) to D 9.3.2. I get the error already and invariably when simply displaying the start page. The weird thing is that - while this happens on my "staging" system, it does not happen on my testing system (which is more complete...). At first I thought it had to do with a file field introduced on the staging (9.3.0) system but NOT on the testing system (no actual file uploaded yet in the staging system!). But the problem persisted on D 9.3.2 after removing the file field through the GUI.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

ayush9598’s picture

Assigned: Unassigned » ayush9598
FileSize
1.79 KB

Adding patch for Drupal 9.3.14

Webbeh’s picture

Assigned: ayush9598 » Unassigned

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

jamsilver’s picture

We've seen this issue appear when using Cacheflush module with one of its sub-modules enabled that defines an extra base field definition in a hook_entity_base_field_info() #3264415: Mismatched entity and/or field definitions

Still don't fully understand what's going wrong there, but the patch here fixes the immediate fatal error.

fonant’s picture

Patch #142 works nicely to fix this error for me, on a site migrated from D7 to D9.

Error only occurring for me after the latest Drupal 9 update to 9.4.8. Before that the site was working fine.

jacov’s picture

+1

Patch #142 worked for me, Drupal 9.4.8

this was not a problem previously.

(not sure if it was related, but right before this, i experienced an error with payment module and it's deps: plugin, currency, payment_paypal.
so maybe left over from those modules changed something)

jacov’s picture

after patch, watchdog reveals the culprit that triggered this bug:

Field commerce_payment_method.paypal_checkout.card_exp_year exists but is missing a corresponding field definition and may be misconfigured.

again,
voting to roll in Patch #142 as critical

Ankit.Gupta’s picture

kim.pepper’s picture

Status: Needs review » Needs work

Ankit.Gupta has reposted the exact same patch someone else posted in multiple issues. Unchecking the suggested credit box and setting back to NW.

interlated’s picture

I applied #153.

Still getting the error at line 113

Call to a member function getLabel() on null in
Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions() (line 113 of
/srv/web/electrifyingbradfield.org/web/core/modules/layout_builder/src/Plugin/Derivative/FieldBlockDerive
r.php) #0
/srv/web/electrifyingbradfield.org/web/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDeco
rator.php(101): Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions()
#1

Sorry - I don't think the patch applied properly

longwave’s picture

I've just run into this in production, and it caused a downtime incident as this error was triggering on all pages for logged in users.

it's only possible to occur through a failed migration, partial deployment, or from someone directly hacking contrib.

As far as I can see, none of these apply to my situation. There had been no deployments for several days and no unusual config or other changes recently that I could see. The issue then went away after clearing cache via Drush, so I can only surmise that there was cache corruption or a similar issue that meant the field definition was somehow missing.

As this appears to be a common point of failure for a number of users, I think it is OK to add protection here to avoid a fatal error at this point, even if we don't currently know root cause (or there could be multiple root causes).

jim.shreds’s picture

Running into this on a fresh 9.5.3 install migration while running upgrade_d7_block import within the --tag=Configuration and --execute-dependencies workflow.

error now on line 113

Error: Call to a member function getLabel() on null in /app/web/core/modules/layout_builder/src/Plugin/Derivative/FieldBlockDeriver.php on line 113 #0 /app/web/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(101): Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions(Array)

kdmdrupal’s picture

I have hit this issue as well when running drush cim for Drupal 9.5.2 to verify migration process steps.

[warning] Undefined array key "body" FieldBlockDeriver.php:102

Error: Call to a member function getLabel() on null in /web/core/modules/layout_builder/src/Plugin/Derivative/FieldBlockDeriver.php on line 113 #0 /web/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(101): Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions()

We have been developing and trying to apply our changes. Any suggestions?

Freddy Rodriguez’s picture

#153 Worked:
D9.5.4
PHP 8.1.16

kdmdrupal’s picture

Freddy I got the patch to work for 9.5.2 via composer update --lock [painful because it remove Drupal 9.5.2 core and then I had to run command again to install 9.5.2 back]. The drush cim worked afters and our changes were applied. Some errors, but it was due missing components which need to be imported into migration verification sandbox.

NOTE: I would of git apply but the layout_builder didn't have the directory/class for were the patch was being applied.

I will update our Drupal repo to the last version of 9.5.x and run again to make sure all goes smooth next time.

Thank you again for your assistance.

Shrutidkadam’s picture

#153 Worked for me. Saved my time Thanks.

Spokje’s picture

Status: Needs work » Reviewed & tested by the community

Ok, going for broke here...

Looking at #156 where @longwave states:

As this appears to be a common point of failure for a number of users, I think it is OK to add protection here to avoid a fatal error at this point, even if we don't currently know root cause (or there could be multiple root causes).

and seeing that patch #153 seems to provide such a fatal CLUNK avoidance for many people and the code does look like it does, I'm going to mark this RTBC.

tim.plunkett’s picture

Would have been nice if any of the people commenting here had helped to work on #3125827: Prevent leftover fields from causing errors like "Call to a member function getLabel() after enabling layout_builder" instead.

longwave’s picture

Status: Reviewed & tested by the community » Fixed

Discussed this with @catch. Given that numerous people have hit this issue since Drupal 8.5, and after several years we don't have a real fix for it, we think that committing this workaround that at least prevents a fatal error is the pragmatic thing to do. I tried to credit everyone who either helped with any aspect of the actual bug, or reported that the fix worked for them.

Committed and pushed 4b2afe955d to 10.1.x and ba543b96b2 to 10.0.x and b05f3fa775 to 9.5.x. Thanks!

  • longwave committed ba543b96 on 10.0.x
    Issue #2985882 by tim.plunkett, Mirakolous, ravi.shankar, ayush9598,...

  • longwave committed 4b2afe95 on 10.1.x
    Issue #2985882 by tim.plunkett, Mirakolous, ravi.shankar, ayush9598,...

  • longwave committed b05f3fa7 on 9.5.x
    Issue #2985882 by tim.plunkett, Mirakolous, ravi.shankar, ayush9598,...
catch’s picture

We should also explore #2940755-54: block_content block derivatives do not scale to thousands of block_content entities, not directly related to the cause of the bug but would have prevented this being a site down issue and an improvement for various other reasons.

Status: Fixed » Closed (fixed)

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