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 ...
Comment | File | Size | Author |
---|---|---|---|
#153 | 2985882-field-153.patch | 1.79 KB | Ankit.Gupta |
| |||
#142 | 2985882-field-142.patch | 1.79 KB | ayush9598 |
Issue fork drupal-2985882
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:
Comments
Comment #2
tim.plunkettI'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?
Comment #3
tim.plunkettComment #4
jborgesr CreditAttribution: jborgesr commentedHi, I have the same error in 8.5.6, with the patch it works fine. Thank you very much.
Comment #5
tim.plunkettSee also #2994398: Not properly clearing EntityFieldManager's fieldMap leads to fatals, often after migration or bundle creation
Comment #6
kducharm CreditAttribution: kducharm at CivicActions commented@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.
Comment #7
tjtj CreditAttribution: tjtj commentedThis 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.
Comment #8
tim.plunkettThis 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.
Comment #9
labboy0276 CreditAttribution: labboy0276 at Tandem commentedI 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
Comment #10
tim.plunkettComment #11
lukasss CreditAttribution: lukasss as a volunteer commentedI see this. 8.6.5
#2 working for me.
Tnx.
Comment #12
lukasss CreditAttribution: lukasss as a volunteer commentedI 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.
Comment #13
andypostI bet fields can prevent delete its storage on last field deleted, so could be covered with test
Comment #14
tim.plunkett@andypost What component should this go in then, as the bug is not related to Layout Builder, only one way of exposing it?
Comment #15
andypostIIRC 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
Comment #16
scotwith1tSame here with 8.6.5. Patch in #2 fixed for us. Thanks!
Comment #17
tim.plunkett#15 isn't quite "steps to reproduce" but could possibly be the basis of some test code.
Comment #18
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedThis 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.
Comment #19
andypostI will dig on it, the concept were added in #1426804: Allow field storages to be persisted when they have no fields.
Comment #20
andypostThat's why
\Drupal\Core\Entity\EntityFieldManager::buildFieldStorageDefinitions()
does some trick instead of loading storage entitiesI bet we need @berdir here
Comment #21
andypostComment #23
PanchoEven 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:
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:and
$this->entityFieldManager->getFieldDefinitions('node', 'child')
does so, too: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.
Comment #24
PanchoWeird.
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:
I guess it's not going to be easy to track down where this inconsistency may come from. But maybe someone has an idea.
Comment #25
tim.plunkettSee also #3034979-6: Layout builder doesn't support bundle computed field
Comment #26
Graber CreditAttribution: Graber as a volunteer commentedI 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).
Comment #27
devarch CreditAttribution: devarch as a volunteer commentedI 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):
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):
Please let me know if you need me to test something else.
Comment #28
Road Kill CreditAttribution: Road Kill commented#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)
Comment #29
AnybodySame 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.
Comment #30
jazzfiction CreditAttribution: jazzfiction as a volunteer commentedI 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:
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.
Comment #31
krima CreditAttribution: krima commentedI 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
Comment #32
Vj CreditAttribution: Vj as a volunteer commentedI am able to reproduce issue with following steps
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.
Comment #33
tim.plunkett#32 that is describing an unrelated bug that has been fixed in 8.8: #3065474: An error occurs when viewing an entity after removing all layout sections and Quickedit module enabled
Comment #34
joarferme CreditAttribution: joarferme commentedHi, 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.
Comment #35
brisath CreditAttribution: brisath as a volunteer commentedNew 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.
Comment #36
renguer0 CreditAttribution: renguer0 as a volunteer commentedSame 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).
Comment #38
tonytheferg CreditAttribution: tonytheferg commentedSame 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...
Comment #39
agilman CreditAttribution: agilman as a volunteer commented#2 works for me, too.
Comment #40
chrisrockwell CreditAttribution: chrisrockwell commentedI 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.
Comment #41
Mirakolous CreditAttribution: Mirakolous at Kanopi Studios commented#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
Comment #42
Mirakolous CreditAttribution: Mirakolous at Kanopi Studios commentedTrying this again...
Comment #43
Mirakolous CreditAttribution: Mirakolous at Kanopi Studios commentedDon't judge me #notspam
Comment #44
mradcliffeI 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.
Comment #45
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedComment #46
Dave KopecekCan 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!
Comment #47
tim.plunkett#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.
Comment #48
mradcliffeI 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.
Comment #49
ab2211 CreditAttribution: ab2211 commentedSame 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.
Comment #50
dpiGetting this simply after adding a new field + instance. First time the new field is config synced to a new site this error is thrown.
Comment #51
dpiComment #52
longwaveMarked #3106756: An unexpected error as duplicate
Comment #53
ravi.shankar CreditAttribution: ravi.shankar at OpenSense Labs commentedI have added a re-roll of patch #43. It still needs tests.
Comment #54
Rajendar Reddy CreditAttribution: Rajendar Reddy commentedI've been facing this issue while enabling Layout Builder module on 8.8.1. #53 works for me.
Comment #55
Christopher Riley CreditAttribution: Christopher Riley commented53 took care of an issue I was having as well.
Comment #56
swatichouhan012 CreditAttribution: swatichouhan012 at Valuebound for Valuebound commented@ravi.shankar please move issue in Needs review after patch apply.
Comment #57
jlancaster CreditAttribution: jlancaster commentedConfirming patch #53 fixes issue in D8 8.8.4 after triggering this bug through a drush features-revert.
Comment #58
joshf CreditAttribution: joshf commentedI 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.
Comment #59
webdrips CreditAttribution: webdrips commented#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()
Comment #61
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commented#53 fixes the issue
Thank you :)
Comment #62
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #63
tim.plunkettIt 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.
Comment #64
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #65
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #66
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #67
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #68
tim.plunkett@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.
Comment #69
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #70
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedThank 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
Comment #71
tim.plunkettCan 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.
Comment #72
Graber CreditAttribution: Graber as a volunteer commentedThis 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.
Comment #73
tim.plunkett#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.
Comment #74
devarch CreditAttribution: devarch as a volunteer commentedAs 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.
Comment #75
renguer0 CreditAttribution: renguer0 as a volunteer commentedI agree. I did come into this problem after deleting some field items when tried to get rid of Paragraphs manually.
Comment #76
tim.plunkettThis 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.
Comment #77
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commented#72 Marcin is right
It could happen with old configs on fresh install too ( in case of installation profiles )
optional and install configs
Comment #78
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedI 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
Failing in Test1
Passing in Test2
It is the HTML input field for Machine name not been present in the form yet
Comment #79
corneliusd CreditAttribution: corneliusd commentedJust 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!
Comment #80
h.paul CreditAttribution: h.paul as a volunteer commentedI 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:
But I'm not sure whether drupal/core is the correct thing.
Can anybody help me?
Comment #81
corneliusd CreditAttribution: corneliusd commentedI 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.
Comment #82
joshf CreditAttribution: joshf commented@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.Comment #83
tim.plunkettLeaving 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"
Comment #84
devarch CreditAttribution: devarch as a volunteer commented@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.
Comment #85
tim.plunkett@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.
Comment #86
AnybodyThank 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!
Comment #87
tim.plunkettI 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.
Comment #88
renguer0 CreditAttribution: renguer0 as a volunteer commentedPlease 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.
Comment #89
cilefen CreditAttribution: cilefen commented@renguer0:
I use https://github.com/cweagans/composer-patches.
Comment #90
renguer0 CreditAttribution: renguer0 as a volunteer commented@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.
Comment #91
dpeamit CreditAttribution: dpeamit commentedComposer update
Comment #92
Freddy RodriguezIn 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)
Comment #94
NickDickinsonWildeUnder 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...
Comment #95
Anybodyre #92: We for example never used flexslider.
Comment #96
themaurice CreditAttribution: themaurice as a volunteer commentedpatch #85 tim.plunkett work for me on 8.9.1 thanks
Comment #97
alexmoreno CreditAttribution: alexmoreno commentedHitting this in Drupal 9 as well. The patch worked like a treat, thanks.
Comment #98
segx CreditAttribution: segx commentedRan into this problem when upgrading to v8.9.2. Patch #85 resolved the problem. Thank you!
Comment #99
the_glitch CreditAttribution: the_glitch commentedpatch #85 somewhat fixed it to the point where it no longer white screens but still getting this error.
Comment #100
tim.plunkett#99, that's an unrelated bug. See #3104980-2: layout_builder_system_breadcrumb_alter doesn't check for a null route object for a patch
Comment #102
kattekrab CreditAttribution: kattekrab as a volunteer commentedWell 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.
Comment #103
kattekrab CreditAttribution: kattekrab as a volunteer commentedUnfortunately 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!
Comment #104
tim.plunkett@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.
Comment #105
NWOM CreditAttribution: NWOM commented#85 worked amazingly. Thank you! Should we mark this issue as Needs Work or Needs Review since a patch is attached?
Comment #106
tim.plunkettThis patch is a workaround. See #83 for more.
Comment #107
ouissla CreditAttribution: ouissla commentedI 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:
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.
Comment #108
zterry95 CreditAttribution: zterry95 at DAVYIN Internet Solutions / 戴文信息科技有限公司 commented#85 patch works on drupal 8.9.
Comment #109
design.er CreditAttribution: design.er commented#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. :)
Comment #110
berliner CreditAttribution: berliner commentedI 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()" .
Comment #113
kwfinken CreditAttribution: kwfinken at Michigan State University for Michigan State University commentedI 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.
Comment #114
PetDu CreditAttribution: PetDu commentedHaving 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
Comment #115
kim.pepperComment #116
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedComment #117
tim.plunkettThis 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".
Comment #118
Rajab Natshah CreditAttribution: Rajab Natshah at Vardot commentedNoted;
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"
Comment #119
kattekrab CreditAttribution: kattekrab as a volunteer commentedMmmm. Looks like the patch no longer applies.
Comment #120
tim.plunkett@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!
Comment #121
cafuego CreditAttribution: cafuego at United Nations commentedSorry @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.
Comment #122
lordzik CreditAttribution: lordzik commentedPatch 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.
Comment #123
lordzik CreditAttribution: lordzik commentedComment #124
tim.plunkettAs I said in #120 and also before that:
Comment #125
BramDriesenThe workaround also solved the issue for me. Subbed on both issues.
Comment #126
dorianwinterfeld CreditAttribution: dorianwinterfeld as a volunteer and commentedI 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?
Comment #127
tim.plunkettComment #128
dorianwinterfeld CreditAttribution: dorianwinterfeld as a volunteer and commentedI 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?
Comment #132
hswong3i CreditAttribution: hswong3i at PantaRei Design Limited (Hong Kong) commentedPR created from #85
Comment #133
tim.plunkettNo need for a MR as this is just a patch people can reference while waiting for someone to help debug the actual issue.
Comment #134
hstoellinger CreditAttribution: hstoellinger commentedI 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.
Comment #142
ayush9598 CreditAttribution: ayush9598 commentedAdding patch for Drupal 9.3.14
Comment #143
WebbehComment #149
jamsilver CreditAttribution: jamsilver commentedWe'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 definitionsStill don't fully understand what's going wrong there, but the patch here fixes the immediate fatal error.
Comment #150
fonant CreditAttribution: fonant at Fonant Ltd commentedPatch #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.
Comment #151
jacov CreditAttribution: jacov as a volunteer commented+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)
Comment #152
jacov CreditAttribution: jacov as a volunteer commentedafter 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
Comment #153
Ankit.Gupta CreditAttribution: Ankit.Gupta at Dotsquares Ltd. commentedComment #154
kim.pepperAnkit.Gupta has reposted the exact same patch someone else posted in multiple issues. Unchecking the suggested credit box and setting back to NW.
Comment #155
interlated CreditAttribution: interlated as a volunteer commentedI 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
Comment #156
longwaveI'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.
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).
Comment #157
jim.shreds CreditAttribution: jim.shreds commentedRunning 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)
Comment #158
kdmdrupal CreditAttribution: kdmdrupal commentedI 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?
Comment #159
Freddy Rodriguez#153 Worked:
D9.5.4
PHP 8.1.16
Comment #160
kdmdrupal CreditAttribution: kdmdrupal commentedFreddy 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.
Comment #161
Shrutidkadam CreditAttribution: Shrutidkadam commented#153 Worked for me. Saved my time Thanks.
Comment #162
SpokjeOk, going for broke here...
Looking at #156 where @longwave states:
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.
Comment #163
tim.plunkettWould 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.
Comment #164
longwaveDiscussed 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!
Comment #168
catchWe 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.