[Meta] Determine best method of allowing inline content creation Layout Builder

In regards to the UX differences of having different bundle types from existing block types...

In #2974860: Allow inline content creation in layout builder through a single purpose entity type unless we did some magic to sync the fields then they would have different bundles and fields.

I think if we were going to do this we might as well just use the existing Custom Block entity type because the extra complexity and potential bug of trying to sync these field configs is probably more complex that the changes we would have to make to Custom Block entity type to use it.

I am not sure it is actually a feature we want to have the same fields for both inline and "custom" blocks. both cases have pros/cons

1. @johndevman thanks for posting that from the meeting.

   I would see this has more contrib use case personally. If we did #297486: Problem with jquery.innerfade.js in Internet Explorer then a contrib module could provide the syncing on all or some of the Custom Block types, it could an option on each 1.

   We tried to sync in core we would to worry about:

   1. hook_field_storage_config_update_forbid would automatically fire this for the sync field config?
   2. Many other field related hooks. hook_field_widget_form_alter, implementations can check the entity type by $context['items']->getEntity(). So if the intention of an implementation was alter a widget on block entity and it checked this check entity type would not be the same. So have the new entity type that was suppose to be synced the be same as the Custom Block entity all hook implementations like this would have to be updated.

   This kind of problem for me is why I would think syncing should be left to contrib.

2. I thought of another problem with #2957425: Allow the inline creation of non-reusable Custom Blocks in the layout builder block access.

   We have to worry about the case where the site builder either creates view that exposes list of the inline blocks or sets up a entity reference to point to inline blocks.

   Because determining view access will be tricky, based on view access the revision that inline block placed on.
   Right now \Drupal\block_content\BlockContentAccessControlHandler::checkAccess just gives view access if the block is published.

   If I was site builder I would filter new views to not show non-reusable blocks. Will people know to do this and to update there existing views. We could update views via an update hook to add the filter on reusable b/c all current views would be getting reusable blocks anyways.

   But what about views that imported after the update hook. Would we assume they also should be updated? They could have been made before the update hook on another env which means they should get filter or they could have been made after so the filter was intentionally not added.

   As far as entity reference field we can assume there are many existing entity reference fields that are set up to reference custom blocks. So in those you could now have the user be able start to select the non-reusable blocks unless we did something.

   I just think if a user is placing a non-reusable block on layout page they probably have different idea about access vs adding in the custom block library. They would not expect that this block could be selected in an entity reference field on another entity and then render without view access to the entity where the non-reusable block was originally placed.

   Of course there is also the case of placing the block on entity view display.

   All this means that if we use the Custom block entity type we would have update BlockContentAccessControlHandler to have different logic based on if the entity is reusable or not.

   UPDATE: Added patch this #2957425-117: Allow the inline creation of non-reusable Custom Blocks in the layout builder.

We are considering 2 ways of doing the same thing from the use perspective. Though they will have different side-effects the functionality of adding inline block(or block-like) content through Layout Builder will be the same in both cases.

For that reason I am going to create \Drupal\Tests\layout_builder\FunctionalJavascript\InlineBlockTestBase that will be the same in both cases. This way we can be sure we are comparing the same user functionality as it pertains to inline entity blocks:

1. Place and editing blocks
2. Changes made to overrides should not effect defaults
3. Changes made to defaults should not effect existing defaults.
4. Separate overrides should not effect each other.
5. Block entity deletion: blocks should be deleted when the parent.
6. Revisions: previous revision blocks should remain unchanged.
7. If not using revisions the blocks should be deleted if removed on update
8. When layout is canceled blocks added without a layout save should not be saved
9. When reverting a layout override blocks in override should be deleted.

Both the issue have test coverage for these case but since they don't use the same base class we can't positive they will act the same way.

Closing this issue because after 3 weeks of discussions at Layout Initiative meetings and working on the 3 issues that are mentioned in summary #2957425: Allow the inline creation of non-reusable Custom Blocks in the layout builder was determined to be the best method.

Making another entity type behave like Custom Block types would be too complicated and require updates to current custom code.

Maybe I closed this to early

@larowlan the maintainer of the block_content has some reservations about #2976334-37: Allow Custom blocks to be set as non-reusable adding access restriction based on where it was used..

In general if it is general discussion about the best way to accomplish this in layout_builder then we can discuss it here.

For the actual patch in #2976334 we can discuss in that issue.

1. Site Building

   I still think using existing block_content entity type would be the best site building experience.

   People were very excited for field-able blocks in Drupal 8. I think part of this was the fragmentation in Drupal 7 contrib around this problem.

   We had Fieldable Panel Panes, Beans and Boxes. It would be nice if in core we consolidate around 1 type so that site builders could manage the fields for this type of thing in 1 place.

2. Migrations

   Fieldable Panels Panes already has on their project page:

   There will be no port of Fieldable Panels Panes to Drupal 8, custom block types provide all of the functionality that is necessary.

   Bean has:

   As Drupal 8 supports fields on its block entities, this module is not needed for new sites.

   Presumably that means there are already migrations built for this case. Probably the existing entities of these types would be reusable blocks but what would the migration paths migrate the bundles to? Both, if so then would it be the site-builders responsibility to keep them in sync?

Closing again.

Chatted with @larowlan and his now fine with using the Custom Block entity type for this(dependent on some changes I will add to #2976334: Allow Custom blocks to be set as non-reusable adding access restriction based on where it was used. that will simplify the access changes)