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.
Performance
However, 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 that clutter user interfaces and lead to performance issues.
UX
Currently to add a custom block to a Layout the user would have to first navigate to the custom block page, create the block and then navigate back to the layout builder.
Access Control
If we allow inline block creation a user who creates a custom block on the Layout Builder for an access controlled entity probably expects only those that can view the entity that has the Layout to be able to view the custom block. Currently blocks have no connection on an access level to where they are placed so if you listed the block in a View or it was referenced in an Entity Reference value anyone would be able to see it.
Revision
Currently if you placed a block via the Layout Builder there is no connection between the revision of the block and revision of the entity with the Layout. If you updated a custom block all previous revision of the entity with the layout would display the update version.
Deletion
If a custom block is deleted then it would be removed from all placements via the Layout Builder across all revisions.
Proposed resolution
Add the ability for users to create custom non-reusable blocks from within within the Layout Builder. These blocks will be the same entity type as Custom Block provide by the block_content module therefore all the site current block types will be available from within the Layout Builder.
The non-reusable blocks will be only be viewable within the context of the layout that they were placed in. For bundles that are set to create a new revision for each update the changes to custom inline block will be tracked with the parent entities revision.
The new custom inline blocks should be "owned" by the layout that they are placed in in that they should be editable or deleted from outside of the layout builder.
Implementation
Add a new base field to Custom Blocks that determines is 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 normal Views listings. For integration with Layout Builder, we should create a new Block Plugin that stores Custom Block revision IDs and implement an inline form for creating and editing these Custom Blocks.
This issue actually include several concepts that should probably be split out into separate issues.
To determine if end goal is achievable and advisable with this approach lets keep this as a big patch containing the sub tasks until it looks like it is good idea. We won't want to commit small supporting parts if we are going abandon this approach for something like #2948064: Layout Builder should support inline creation of Custom Blocks using entity serialization(currently that issue seems not doable)
Eventually we may want to have separate issues for
- Allow some Content Blocks to be non-reusable(probably in Block Content module eventually)
- Implement generic entity usage tracking to support non-reusable blocks
- Allow inline creation of non-reusable blocks in the Layout Builder (maybe all that would remain for this issue)
Remaining tasks
Write a patch to explore the feasibility of this approach.
User interface changes
n/a
API changes
n/a
Data model changes
n/a