Call to undefined method isLayoutBuilderEnabled()

This a problem with layout builder or layout builder library?

Will need a test case for core to show this problem.

Will leave in PNMI for a few more months before closing if no follow up.

This has been PNMI for 6 months now with no further issue reports, and we have no steps to reproduce with just core. Closing this issue now, if someone can replicate this with just core feel free to reopen.

@DanielVeza we faced the issue recently on several projects, with the patch #7 having resolved it.

Steps to reproduce will still need to be added to issue summary.

Bugs require test coverage.

Could we please get a stacktrace as well?

I am seeing a similar issue occur. Occasionally when the cache clears (its not consistently happening), the entire site layout breaks and the PHP logs have this error:

Uncaught PHP Exception Error: "Call to undefined method Drupal\Core\Entity\Entity\EntityViewDisplay::isOverridable()" at /var/www/html/docroot/core/modules/layout_builder/src/Plugin/SectionStorage/DefaultsSectionStorage.php line 312

The error can persist through a few cache clears until it finally resolves itself. It should be noted we are using Memcache on Acquia, and this only happens in the production environment and never dev or stage.

The only LB related contributed modules we have are:

• layout_builder_context
• layout_builder_styles
• layout_builder_iframe_modal
• layout_builder_restrictions

This issue can then cascade down and cause other errors that are not real, like other core classes not existing (when they do). Once the cache is completely purged and rebuilt, its fine.

Happened again today, even with the patch above for isOverridable and isLayoutBuilderEnabled. Only this time, no logs.

Our only other action here is removing Memcache on Acquia entirely and seeing if it persists.

This issue is still happening at random, even with Memcache disabled.

Should this even be possible at that point in the code in Layout Builder?

Uncaught PHP Exception Error: "Call to undefined method Drupal\Core\Entity\Entity\EntityViewDisplay::isOverridable()" at /var/www/html/docroot/core/modules/layout_builder/src/Plugin/SectionStorage/DefaultsSectionStorage.php line 312

That method is defined as:

/**
 * {@inheritdoc}
 */
public function isOverridable() {
  $display = $this->getDisplay();

  return $this->getDisplay()->isOverridable();
}

getDisplay:

  /**
   * Gets the entity storing the defaults.
   *
   * @return \Drupal\layout_builder\Entity\LayoutEntityDisplayInterface
   *   The entity storing the defaults.
   */
  protected function getDisplay() {
    return $this->getSectionList();
  }

It says it should return an instance of LayoutEntityDisplayInterface, instead it returns an instance of EntityViewDisplay. Under what conditions could that happen? Trying to trace calls to isOverridable does not really produce much.

SectionStorage defines its context definition as an entity view display:

* @SectionStorage(
 *   id = "defaults",
 *   weight = 20,
 *   context_definitions = {
 *     "display" = @ContextDefinition("entity:entity_view_display"),
 *     "view_mode" = @ContextDefinition("string", default_value = "default"),
 *   },
 * )

This is where the trail runs cold for me. Does anyone know how or when EntityViewDisplay could be returned instead of an expected LayoutEntityDisplayInterface object that triggers the error?

What's the stack trace of the exception? Whatever it is, it's happening before layout_builder_entity_type_alter() has run, which shouldn't be possible.

@kevinquillen This may be unrelated, but the code you've posted for DefaultsSectionStorage::isOverridable is different to cores. Is there a chance you have a patch that may be causing issues?

Sorry, that was an error as I was trying a few things. Everything is removed now and back to

  /**
   * {@inheritdoc}
   */
  public function isOverridable() {
    return $this->getDisplay()->isOverridable();
  }

I may have some tangentially related info here. We recently found that due to how layout builder works (prior to Drupal 10.3), the accumulation of derived field blocks resulted in a single cache item in `cache_discovery` having a size of over 6mb.

This _may_ result in extreme performance problems for memcache users, because the default config won't store individual items over 1mb in size.

Just a theory, but such a large, virtually uncatchable, record could explain a lot of the "this should not be able to happen under normal circumstances" responses to this issue. Systems break down in wild ways when the underlying infrastructure doesn't behave as expected.

I'm curious if this happens in 10.3+ with most derived field blocks disabled so the block plugins CID falls below 1mb?

I will add that we found this specific issue and error to happen far, far less with the application of this patch:

https://www.drupal.org/project/drupal/issues/3207813#comment-14380171 🐛 ModuleHandler skips all hook implementations when invoked before the module files have been loaded Needs review

We then moved storage back from the database cache to memcache - but what Luke says in #20 is still true.

I also found a way to replicate this issue:

1. Clear the site cache
2. Request random urls in the frontend of the site at the same time (literally within 1-3 seconds of cache clear initiation).

I was able to get the behavior 90% of the time, which is why this was so hard to track down in prod. It was once in a blue moon where the caches would clear as site traffic was happening at the same time to a degree that would cause this. But if this is the case I do not think this is specifically a Layout Builder issue but something in core as the above patch alludes to, it just happens to affect Layout Builder.

These may be related:

1. #2765271: Rationalize use of the 'discovery' cache bin, since it's stored in the limited size APCu by default →
2. 🐛 Multilingual config cached in "config" cache bin; quickly reaches APCu memory limits Needs work
3. 🐛 Reduce the number of field blocks created for entities (possibly to zero) Fixed

This thread seems close to the issue at hand:

https://www.drupal.org/project/shield/issues/3277210#comment-15083125 🐛 Shield middleware invokes hooks before modules are loaded, corrupting module_implements cache Needs work

Potentially related issue on the same note as #22, albeit not in Middleware, but a different service constructor.

Hello everyone,

I’ve been experiencing an issue related to Layout Builder on my site:

Error: Call to undefined method Drupal\Core\Entity\Entity\EntityViewDisplay::isLayoutBuilderEnabled() in Drupal\layout_builder\Plugin\SectionStorage\DefaultsSectionStorage->isLayoutBuilderEnabled() (line 341 of docroot/core/modules/layout_builder/src/Plugin/SectionStorage/DefaultsSectionStorage.php).

To address this, I applied the patch (in #7). However, after applying the patch, I am now encountering a new error (same as #16):
Error: Call to undefined method Drupal\Core\Entity\Entity\EntityViewDisplay::isOverridable() in Drupal\layout_builder\Plugin\SectionStorage\DefaultsSectionStorage->isOverridable() (line 318 of docroot/core/modules/layout_builder/src/Plugin/SectionStorage/DefaultsSectionStorage.php).

My Drupal version is 10.3.1 with Layout Builder enabled. My site only has one content type using Layout Builder and does not heavily rely on this module.

Has anyone else faced a similar issue after applying this patch? If so, how did you resolve it? Any insights or suggestions would be greatly appreciated.

Thanks in advance for your help!