Problem/Motivation

We would like to get programatically an entity object of block added in Layout Builder, but since `getEntity` method (/core/modules/layout_builder/src/Plugin/Block/InlineBlock.php:233) is protected, we can only get already rendered object, which doesn't fully cover our needs.

It would be great to make `getEntity` method public, so other developers could easily get added block objects if necessary.

Proposed resolution

Change `getEntity` method visibility from protected to public in `ExtraFieldBlock.php`, `FieldBlock.php` and `InlineBlock.php` files.

Issue fork drupal-3223864

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

skorzh created an issue. See original summary.

skdrupal88’s picture

skdrupal88
Primary language Russian
Location Belarus
commented
Version: 9.1.x-dev » 9.2.x-dev

skorzh opened merge request !944

skdrupal88’s picture

skdrupal88
Primary language Russian
Location Belarus
commented
longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Status: Active » Needs review
Issue tags: -code
tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Assigned: skdrupal88 » tedbow
Issue tags: -Layout Builder +Blocks-Layouts

Can you expand upon what you're doing with the underlying entity? Would be good to understand that better.
Assigning to @tedbow for his opinion, as he wrote the majority of inline blocks.

skdrupal88’s picture

skdrupal88
Primary language Russian
Location Belarus
commented

@tim.plunkett, we need to calculate the number of article words to send to third-party analytics service, so on node update we grab all data from content blocks text fields and calculate the total number.

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented

I think there are backwards compatibility concerns with changing the visibility

Given that these classes are @internal and people should not be extending them if they have extended them and overridden getEntity() then they will get an error because they would have used protected.

We could say since they are @internal we shouldn't care if someone has overridden but from the same logic we should not make a new public method on an @internal class for developers to depend on.

I was wondering if you can get the entity for block/component just from context system and I think you can. This rough but I think it works. It would probably need to be cleaned up. This would work on hook_entity_presave

// in a class using \Drupal\layout_builder\LayoutEntityHelperTrait
$sections = $this->getEntitySections($entity);
$storage = $this->getSectionStorageForEntity($entity);
/** @var \Drupal\Core\Plugin\Context\ContextRepositoryInterface $context_repository */
$context_repository = \Drupal::service('context.repository');
$runtime_contexts = $context_repository->getRuntimeContexts(['@user.current_user_context:current_user']);
$contexts = $context_repository->getAvailableContexts();
foreach ($sections as $section) {
  foreach ($section->getComponents() as $component) {
    $config = $component->get('configuration');
    if (isset($config['context_mapping']['entity'])) {
      $entity_context_mapping = $config['context_mapping']['entity'];
      if ($entity_context_mapping === 'layout_builder.entity') {
        $entity_from_context  = $storage->getContextValue('entity');
      }
      else {
        if (isset($runtime_contexts[$entity_context_mapping])) {
          $entity_from_context = $runtime_contexts[$entity_context_mapping]->getContextValue();
        }
        elseif (isset($contexts[$entity_context_mapping])) {
          $entity_from_context = $contexts[$entity_context_mapping]->getContextValue();
        }
        else {
          // no entity
        }
      }
    }
  }
}
skdrupal88’s picture

skdrupal88
Primary language Russian
Location Belarus
commented

Thanks for the reply @tedbow, I agree with your concerns about the method visibility change, but I also think that we definitely need to provide a simple method to get entity object, and it looks very logical and semantically correct to use method like ->getEntity().

I was really confused that I have an access to the rendered block, but don’t have to the entity.
It’s like if we can have access to the rendered body field, but don’t have an access to the raw value when we work with the entity.

According to the Drupal best practices, developers can have an access to values of child entities via references, like we can get an access to referenced node category with $node->get(‘field_category’)->getValue(). The same way I expect to have an access to the blocks added in layout builder, for example:

$components = $node->layout_builder__layout[0]->section->getComponents();
$plugin = $components[0]->getPlugin();
$block = $plugin->getEntity();

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.1.10 (June 4, 2021) and Drupal 9.2.10 (November 24, 2021) were the last bugfix releases of those minor version series. Drupal 9 bug reports should be targeted for the 9.3.x-dev branch from now on, and new development or disruptive changes should 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.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should 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.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should 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.

smustgrave’s picture

smustgrave commented
Status: Needs review » Needs work
Issue tags: +Needs Review Queue Initiative, +Needs work, +Needs tests

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

From reading the comments seems as though there is still work/discussion to be add

Did not review MR

Whatever is decided will require test coverage.

Version: 9.5.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. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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.