Provide a way to opt-out of inline blocks in layout builder based on context

This would be much easier if we added a method to SectionStorageInterface and we let the section storage decide if it wants inline blocks or not. As that would break BC, not sure if the best way is to add a new interface instead.

We would make SectionStorageBase implement that interface and provide the current behavior as default.

Is that our best option?

Added inlineBlocksAllowedInContext which would fulfill layout builder restrictions requirements and dashboards/dashboard.

However for layout builder restrictions to work without overriding the ChooseBlockController controller, it would need to swap the section storage class with hook_entity_type_alter, This might be worse than actually swapping the controller. So a hook might be the best alternative,

This might be looked as an unnecessary indirection, but only found twice a hook or alter in a controller in core: hook_system_themes_page_alter and hook_help.

And this way a module providing a section storage can opt-out without having to implement any hooks.

Updated issue summary with proposed resolution in the MR. Clarified problem/motivation.

Created 📌 [PP-1] Use hook instead of overriding controllers (#3351758) Postponed . Patch is green locally for layout_builder_restrictions with these changes.

This is ready for review.

Feel free to move back to NR if I got this wrong.

But testing on 10.1.x
Turned layout builder on and enabled for basic page content type
added

function layout_builder_layout_builder_allowed_inline_blocks_alter(array &$inline_blocks, SectionStorageInterface $section_storage, array $context) {
  // Don't allow custom basic blocks.
  if (($index = array_search('inline_block:basic', $inline_blocks)) !== FALSE) {
    unset($inline_blocks[$index]);
  }
}

just for testing with xdebug on.
In layout builder when I click add block
This hook gets called 11 times with the variables never changing.

That expected?

Good question.

That hook ends up called for each category, as getBlockLinks() is called once per category.
We cannot assume if there are or not inline blocks in a given category, or if all the inline blocks are in the same category, as someone could modify the categories in hook_plugin_filter_TYPE__CONSUMER_alter (aka hook_plugin_filter_block__layout_builder_alter).

We could do something as:

  protected function getBlockLinks(SectionStorageInterface $section_storage, int $delta, $region, array $blocks) {
    $links = [];
    $hasBlockLinks = array_reduce($blocks, function ($found, $item) {
      return $found || $item['id'] === 'inline_block';
    });
    $allowed_inline_blocks = [];
    if ($hasBlockLinks) {
      $allowed_inline_blocks = $section_storage->inlineBlocksAllowedInContext($delta, $region);
    }

    foreach ($blocks as $block_id => $block) {
      if ($block['id'] === 'inline_block' && !in_array($block_id, $allowed_inline_blocks)) {
        continue;
      }

To check that in each category and prevent some calls. However I'm not sure if that's premature optimization. Being fair I don't expect many implementations on the hook aside of layout_builder_restrictions, given that now any custom section storage could implement the inlineBlocksAllowedInContext method itself with this patch.

Also, in most cases (or at least layout_builder_restrictions) will only process config on their hook implementation, and the config objects will be in memory between calls.

Is there a way to tell which category I’m in? Or if this API is meant to disable inline blocks across the board?

You can check $block['category'] for each block definition.

In the hook, you could load all the blocks and use the categories for filtering which ones you want to allow. In any case the plugin system has caching mechanisms.

Take into account that this would be used only for restricting inline blocks creation (or which bundles you want to allow).
For the general use case of "other" blocks there is already hook_plugin_filter_TYPE__CONSUMER_alter (hook_plugin_filter_block__layout_builder_alter).

Would it be easier and simpler to just check what the results of $this->blockManager->getFilteredDefinitions() and see if there are any inline blocks available as a result? We're already calling it in \Drupal\layout_builder\Controller\ChooseBlockController::build(), so it would be fairly easy to link those up rather than adding a new API for inlineBlocksAllowedInContext()?