Layout builder doesn't support bundle computed field

Created on 22 February 2019, over 5 years ago
Updated 2 July 2024, 5 months ago

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()

πŸ› Bug report
Status

Closed: duplicate

Version

11.0 πŸ”₯

Component
Layout builderΒ  β†’

Last updated about 12 hours ago

Created by

πŸ‡«πŸ‡·France muldos

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

  • Blocks-Layouts

    Blocks and Layouts Initiative. See the #2811175 Add layouts to Drupal issue.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡«πŸ‡·France musa.thomas France πŸ‡«πŸ‡·

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

  • πŸ‡·πŸ‡΄Romania claudiu.cristea Arad πŸ‡·πŸ‡΄

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

  • 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.

  • Status changed to Closed: duplicate 8 months ago
  • πŸ‡§πŸ‡ͺBelgium wim leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί

    Why do we think we cannot fix ::getFieldMap() πŸ€”

    Let's fix that in #3045509: EntityFieldManager::getFieldMap() doesn't show bundle fields β†’ 😊.

  • πŸ‡·πŸ‡΄Romania claudiu.cristea Arad πŸ‡·πŸ‡΄

    Patch for 11.x

Production build 0.71.5 2024