Split out from #2957425: Allow the inline creation of non-reusable Custom Blocks in the layout builder
Problem/Motivation
When you create a Custom Block entity, a Block Plugin definition is derived and is available anywhere Block Plugin definitions are listed. This makes a lot of sense when Custom Blocks are meant to be re-used, for example you may want a "Logo" Custom Block on many pages in different regions.
However when using Custom Blocks within the Layout Builder the current functionality has many problems:
Performance
When using something like Panels or Layout Builder, Custom Blocks are often only meant to be used once. If you're building out hundreds of pages you could end up with thousands of Custom Blocks and lead to performance issues. This blocks would shown on every place you are able to pick a block including the layout builder and the current block place listing.
Proposed resolution
Add a new base field to Custom Blocks that determines if they are re-usable. If a Custom Block is not re-usable, it should not have a derived Block Plugin definition and should not be visible in the default "Custom Block library" View listings.
Non-reusable blocks access will be determined by:
- Access to the block itself, existing logic and
- Access to a new access dependency which the modules using non-reusable blocks are responsible for setting.
Modules using non-reusable blocks should when possible call $block->setAccessDependency() before access is called on the block. The dependency is not saved with the block content entity but called when interacting with the block object.
In the case when $block->setAccessDependency() has not been called before $block->access(), probably because another module is accessing access, the BlockContentAccessControlHandler will fire a new BlockContentGetDependencyEvent that will allow modules to set access the access dependency.
Non-reusable block will be used by the Layout Builder to create inline blocks in #2957425: Allow the inline creation of non-reusable Custom Blocks in the layout builder.
Remaining tasks
Add testing for changes to \Drupal\block_content\BlockContentAccessControlHandler::checkAccess
User interface changes
None this issue will not exposed the creation of the non-reusable blocks.
Non-reusable blocks will be used in #2957425: Allow the inline creation of non-reusable Custom Blocks in the layout builder
API changes
Introduce AccessDependentInterface which simply will have getter and setter methods for an $accessDependency. Access controllers would be responsible for modifying Access to the entity that implements this new interface. \Drupal\block_content\Entity\BlockContent would implement this new interface and if $block->isReusable() === FALSE then \Drupal\block_content\BlockContentAccessControlHandler::checkAccess() will only allow access if access to the $accessDependency is also allowed. This will stop non-reusable blocks from being viewed/edited/deleted outside the Layout Builder or another system that is aware of the AccessDependentInterface. Current blocks and any block that is reusable(the default behavior) will not be affected.
Add a new BlockContentGetDependencyEvent class. This event will be fired by the \Drupal\block_content\BlockContentAccessControlHandler::checkAccess() in the case where the dependency has not been set. The event allows setting of the access dependency.
Data model changes
New reusable field on block_content entity type. The default value would be TRUE so that all existing blocks would function the same as they currently do.