Problem:

Every computed field added to a bundle using hook_entity_bundle_field_info() will be ignored by the FieldBlockDeriver, and computed fields will not be listed in the content fields section when editing the layout of the current bundle type.

Causes:

The getDerivativeDefinitions method of Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver constructs its field_map for a given entity type using getFieldMap wich doesn't trigger every fields related hooks.
Later in the code, the method getFieldDefinitions($entity_type_id, $bundle) which triggers all fields related hooks is used, but the results of this method are narrowed to previousey listed fields only

$field_definition = $this->entityFieldManager->getFieldDefinitions($entity_type_id, $bundle)[$field_name];

Possible Fix:

Complete the entity_field_map, with fields declared using hook_entity_bundle_field_info()

Possible other problem:

There could be the same issue for extra fields declared using hook_entity_extra_field_info()

CommentFileSizeAuthor
#21 layoutbuilder-bundlecomputedfieldsfix-3034979-21-11.x.patch3.9 KBclaudiu.cristea
#3 layoutbuilder-bundlecomputedfieldsfix-3034979-3-8.6x.patch4.04 KBmuldos
#2 layoutbuilder-bundlecomputedfieldsfix-3034979-1-8.6x.patch4.48 KBmuldos
#2 layoutbuilder-bundlecomputedfieldsfix-3034979-1-8.7x.patch4.04 KBmuldos

Comments

muldos created an issue. See original summary.

muldos’s picture

muldos commented
StatusFileSize
new layoutbuilder-bundlecomputedfieldsfix-3034979-1-8.7x.patch4.04 KB
new layoutbuilder-bundlecomputedfieldsfix-3034979-1-8.6x.patch4.48 KB

patches provided

muldos’s picture

muldos commented
StatusFileSize
new layoutbuilder-bundlecomputedfieldsfix-3034979-3-8.6x.patch4.04 KB

fix the 8.6 patch

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Issue tags: +Needs tests

Thanks for tracking this down.
I'm of the opinion that this is a bug in getFieldMap() itself, not something that LB should be handling itself.

muldos’s picture

muldos commented

I agree that if getFieldMap() was calling every fields related hooks, it would solve the problem too.
But getFieldMap could have been written the way it is by design as a comment suggest 

       // In the second step, the per-bundle fields are added, based on the
        // persistent bundle field map stored in a key value collection. This
        // data is managed in the EntityManager::onFieldDefinitionCreate()
        // and EntityManager::onFieldDefinitionDelete() methods. Rebuilding this
        // information in the same way as base fields would not scale, as the
        // time to query would grow exponentially with more fields and bundles.
        // A cache would be deleted during cache clears, which is the only time
        // it is needed, so a key value collection is used.

(https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...)
So maybe author(s) of EntityFieldManager were considering that to get a comprehensive list of per bundle fields, other methods should be used.

Also as the default display manager handles bundle computed fields properly because it is using getFieldDefinitions($entity_type_id, $bundle) observing fields disappeared when switching to layout builder can be seen as a layout builder's bug by the end users, and that's also why I have done the fix here.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
commented

It seems to me that we have potentially two issues here:

  • EntityFieldManager::getFieldMap() should definitely include definitions provided through hook_entity_bundle_field_info(). I'm wondering whether the issue is that computed issues are not "created" and thus not registered in the entity.definitions.bundle_field_map key-value collection.
  • it seems that pseudo-fields defined via hook_entity_extra_field_info() are definitely being left out here. I'm not sure whether this is by design but I guess this could represent a UX issue, since site builders might not be able to tell the difference between a regular field and an extra field.

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.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Issue tags: +Blocks-Layouts

As I said in #4, I think there is a bug in getFieldMap, see also #2985882: Workaround for "Call to a member function getLabel() after enabling layout_builder"

Re #6.2 there is also now an ExtraFieldBlockDeriver which is separate.

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.

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.

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.

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.

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.

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.

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.

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

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

musa.thomas’s picture

musa.thomas
Primary language French
Location France 🇫🇷
commented

any update about this ?
I do a test and extra field work perfectly but computed field are stille not available inside layout builder

claudiu.cristea’s picture

claudiu.cristea
Primary language Romanian
Location Arad 🇷🇴
commented

As there is an ExtraFieldBlockDeriver why not a new ComputedFieldBlockDeriver? Because I think there are zero chances that ::getFieldMap() to be fixed

crzdev’s picture

crzdev commented

I would prefer to have a single collector to avoid the possibility of having different ids in case it is finally integrated into the getFieldMap method, in addition to not making the editing to editors more complex than it already is (by having another different category).
If that happens, as code makes an array merge, i think no other change will be required than removing deprecated code (no massive update should be necessary, in any case, display, overrides & other like section library...).

I've been trying to use "hook_entity_field_storage_info", "hook_entity_bundle_field_info" && "\Drupal::service('field_definition.listener')->onFieldDefinitionCreate($bundle_definition);" into "hook_entity_bundle_create" & this patch is no necessary but that generates other problems like field table removed when a bundle field is used more than once. That was based into "entity_schema_test_entity_field_storage_info".

We have been using #patch with core ^9.5 && ^10 for a while & is working perfectly (VLSuite). So only pending step whould be test coverage.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Status: Active » Closed (duplicate)
Related issues: +#3045509: EntityFieldManager key/value field map gets out of sync, doesn't recognise bundle fields

Why do we think we cannot fix ::getFieldMap() 🤔

Let's fix that in #3045509: EntityFieldManager key/value field map gets out of sync, doesn't recognise bundle fields 😊.

claudiu.cristea’s picture

claudiu.cristea
Primary language Romanian
Location Arad 🇷🇴
commented
StatusFileSize
new layoutbuilder-bundlecomputedfieldsfix-3034979-21-11.x.patch3.9 KB

Patch for 11.x