Remove block.module dependency from block_content

Believe this will be covered in https://www.drupal.org/project/drupal/issues/1975064 and https://www.drupal.org/project/ideas/issues/3318110

Now that we have moved block_content we may be able to remove the dependency.

So tested removing block as a dependency and can already see failures happening.

Seems like it would be more effort to remove block. There's also a preDelete call on the entity

    parent::preDelete($storage, $entities);

    /** @var \Drupal\block_content\BlockContentInterface $block */
    foreach ($entities as $block) {
      foreach ($block->getInstances() as $instance) {
        $instance->delete();
      }
    }

Which seems dependent on block.

Going to say this works as designed if anyone disagrees please reopen explaining why

Thanks!

I think it should still be possible to remove the dependency on block.module, it just may need a bit of refactoring. The \Drupal\block_content\BlockContentInterface::getInstances method (used in preDelete) provides special handling for block.module but completely ignores layout builder. It probably makes more sense to have a separate service for this integration, and the block instance deletion should probably be implemented in a hook. In other words, the BlockContent entity should have no awareness of Block entities.

Lets see if anyone picks it up.

We haven't addressed #11 and #12 yet.

Which leads me to believe we're missing test coverage for that when block.module is disabled.

\Drupal\block_content\Entity\BlockContent::getInstances should hard fail when the block entity-type doesn't exist.

There's also a reference to block.admin_library in block_content.links.action.yml - it would be good to confirm that doesn't cause any side-effects.

block_content_add_action:
  route_name: block_content.add_page
  title: 'Add content block'
  appears_on:
    - block.admin_library ## here
    - entity.block_content.collection
  class: \Drupal\block_content\Plugin\Menu\LocalAction\BlockContentAddLocalAction

Working on this...

The BlockContentViewBuilder is also tightly coupled to Block module.

And more info in #2666578: Block Content entities have no Contextual links when rendered outside of Block config entity

More coupling in BlockContentForm https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/block...

Created a new MR @ https://git.drupalcode.org/project/drupal/-/merge_requests/12156

• Generally a lot of reduction and dependency on Block between the two modules, and especially in tests.
• A new small service for usage.
• A new core test module to test navigation blocks, without needing block.module. See also #3524985: Reduce dependency on block.module in tests.

Implementation notes

Clarifying title: its block module (not block config or theme_hook:block).

I think though we're not "removing" a dependency, but rather block or block content are conditionally enhancing the other module depending on install state.

-

Updated issue summary a bit.

I've gone through the MR quite thoroughly and generally +1 this overall approach although it is quite complicated and may be hard for some devs to grok, especially the compiler pass stuff (queue many "why isn't this working?!")

My main concerns are:
1. The administer_blocks_permission_test module, although very minor it just doesn't feel right to add a duplicate permission, this is a big nit picky though
2. navigation_variant_test - now tests that just needed 1 block get all the additional elements rendered. Again this may be minor. I haven't ever looked into DisplayVariant plugins before though so thanks for the learning :)

Thanks, some actionables there for me.

Left some questions on the MR

A couple q's for @larowlan. Remaining open threads I dont see as actionable/my implementation notes.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.