Problem/Motivation

#3432874: Replace "Expose all fields as blocks to Layout Builder" configuration with a feature flag module makes it so that block plugins for fields are not created unless at least one bundle from an entity type has a layout builder entity view display enabled.

When enabling layout builder on an entity view display for the first time, layout builder creates the default layout and places block plugins for each field on the display. This generates warnings like this in the logs:

The "field_block:taxonomy_term:test:description" was not found

This is coming from BlockManager::handlePluginNotFound.

Nothing breaks and things work as expected, but these log messages can be alarming.

Steps to reproduce

  1. Turn on dblog
  2. Enable layout builder module
  3. Enable layout builder for an entity view display for one of the default content types. Note the content type's existing traditional entity view display must have at least one field set to be displayed already.
  4. Look at dblog report and see the warning messages

or

  1. drush si --yes demo_umami
  2. Observe warnings like 'The "field_block:node:page:body" was not found' and 'The "extra_field_block:node:page:links" was not found'.

Proposed resolution

Not sure. But I suspect we need to invalidate the block plugin cache somewhere between enabling layout builder view display and layout builder placing the field block plugins in a layout.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3478773

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:

About issue forks

Comments

bkosborne created an issue. See original summary.

quietone’s picture

quietone commented
Version: 11.0.x-dev » 11.x-dev
penyaskito’s picture

penyaskito
he/him
Primary language Spanish
Location 🧑🏽‍🌾 Seville 💃 Andalusia, UTC+2 🇪🇺
commented

This might not be only entity view displays, but any entity using layout builder.

See #3488796: [warning] The "system_menu_block:welcome" block plugin was not found. Easiest way to reproduce is ddev drush si --yes demo_umami

kristen pol’s picture

kristen pol
she/her
Primary language English
Location Santa Cruz, CA, USA
commented

Given this will affect Drupal CMS until we switch to XB and it makes the system look buggy, can we figure out a way to try to suppress these somehow soon? Even a hacky way?

#3495181: "Block plugin not found" warnings during install

kristen pol’s picture

kristen pol
she/her
Primary language English
Location Santa Cruz, CA, USA
commented
Related issues: +#3495181: "Block plugin not found" warnings during install

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

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented
Status: Active » Needs work

I wrote a test for this and found the cause -- the issue is the parent::preSave() call in \Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay::preSave(), which invokes some inline block-related logic (specifically, \Drupal\layout_builder\Hook\LayoutBuilderHooks::entityPresave()) that expects all the block plugins in the section list to be instantiate-able, but the errant field block is not defined yet, because the block cache seemingly hasn't been cleared.

Except that it has been cleared. LB clears it whenever a field is created (in \Drupal\layout_builder\Hook\LayoutBuilderHooks::fieldConfigInsert()), which my test is very explicitly doing. You'd expect that would cause the block to become available right away...but you'd be wrong, because \Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver::getFieldMap() is only exposing fields used by entity view displays that are using Layout Builder. The problem is...the view display hasn't been saved yet; we're still in the middle of pre-saving it!

So I think that's the problem right there. I'm not sure what the correct solution is here because this is some rather loopy, self-reflexive logic. But at least we have a test now so we'll know we fixed it.

phenaproxima opened merge request !10872

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Related issues: +#3129179: Provide some way to rebuild the persistent bundle field map
benjifisher’s picture

benjifisher
he/him or they/them
Primary language English
Location Boston area
commented
Issue summary: View changes

I am adding the STR from Comment #3 to the issue summary. I have noticed the same thing.

chandeepkhosa’s picture

chandeepkhosa commented

@kristen pol

Given this will affect Drupal CMS until we switch to XB and it makes the system look buggy, can we figure out a way to try to suppress these somehow soon? Even a hacky way?

I agree this would be really great to be fixed soon, as this could scare off less experienced developers looking at Drupal and Drupal CMS for the first time, and they will think that something has gone wrong.

In case it is helpful, here is the output from a fresh site install of Drupal CMS 1.1.0 (which in turn uses drupal/core-recommended 11.1.6) using Pygmy for a site I am preparing to launch on lagoon/amazee.io

➜ docker compose exec cli bash -c 'drush -y si && drush -y cr'
 You are about to:
 * DROP all tables in your 'drupal' database.

 // Do you want to continue?: yes.                                                                                      

 [notice] Starting Drupal installation. This takes a while.
 [notice] Performed install task: install_select_language
 [notice] Performed install task: install_select_profile
 [notice] Performed install task: install_load_profile
 [notice] Performed install task: install_verify_requirements
 [notice] Performed install task: \Drupal\RecipeKit\Installer\Form\RecipesForm
 [notice] Performed install task: \Drupal\RecipeKit\Installer\Form\SiteNameForm
 [notice] Performed install task: install_settings_form
 [notice] Performed install task: install_verify_database_ready
 [notice] Performed install task: install_base_system
 [notice] Performed install task: install_bootstrap_full
 [notice] Performed install task: install_install_profile
 [notice] Performed install task: install_configure_form
 [notice] <em class="placeholder">Publish state</em> hidden for: Media types (Document, Document, Image, Image, SVG Image, SVG Image)
 [notice] <em class="placeholder">Unpublish state</em> hidden for: Media types (Document, Document, Image, Image, SVG Image, SVG Image)
 [warning] The "field_block:node:page:field_content" block plugin was not found
 [warning] The "extra_field_block:node:page:content_moderation_control" block plugin was not found
 [warning] The "field_block:node:page:field_featured_image" block plugin was not found
 [warning] The "field_block:node:page:field_tags" block plugin was not found
 [warning] The "extra_field_block:node:page:content_moderation_control" block plugin was not found
 [warning] The "extra_field_block:node:page:content_moderation_control" block plugin was not found
 [notice] Performed install task: install_profile_modules
 [notice] Performed install task: install_profile_themes
 [notice] Performed install task: uninstall_profile
 [notice] Performed install task: install_finished
 [success] Installation complete.  User name: admin  User password: d8PhBLqsmW
 [success] Cache rebuild complete.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.