Inline blocks shouldn't be editable via the normal block content UI

My understanding is that inline blocks were designed to be used with one and only one host entity. This is evidenced by some of the reasons listed in the issue description. That said, I think there is significant value is being able to edit inline blocks outside of Layout Builder. Contextual links is a good example. When contextual links are enabled with #3020876: Contextual links of reusable content blocks are not displayed when rendering entities built via Layout Builder, a user can hover over a block and access an edit link without leaving the current view mode. That's a real UX improvement.

I'd reframe this issue from 'Editing inline blocks outside of Layout Builder causes undesired behavior and thus must be prohibited' to 'Are there benefits to editing inline blocks outside of Layout Builder and, if so, how can the undesired behavior be fixed?'.

As a content editor I don't care whether or not the block has been created inline or is reusable, and I probably don't even know the difference between the two. I just want my contextual links to "Edit" the block, no matter how or where it was originally created. The architectural nuances should not get in the way of a cohesive and understandable UI. My 2 cents.

I'd reframe this issue from 'Editing inline blocks outside of Layout Builder causes undesired behavior and thus must be prohibited' to 'Are there benefits to editing inline blocks outside of Layout Builder and, if so, how can the undesired behavior be fixed?'.

I don't think there will be any reasonable way this can be allowed and these issues can be remedied. Any change to an inline block means some revision of the host entity must be updated to point to some other revision of the inline block. It's not possible to save a revision of the host entity, without the user being granted access to do so and without the same user making explicit choices.

For example, consider a moderated page with layout builder and inline blocks. If I modify an inline block outside of layout builder:

• Does the change appear on the published or draft version of the content?
• Does the content stay in a draft state or change to some other state?
• What happens if the content changes made to the host entity no longer create an entity that passes validation?
• What happens if the user doesn't have access to create additional revision in a draft state?

The same kind of questions apply to non-moderated content and decisions users usually make on entity forms like "should this be a new revision" and "what should be the revision log message for this revision".

Overall, I don't think specifically loading an inline block in it's own form outside of layout builder could be done correctly, with no data integrity or access bypass issues without enormous effort for a marginal gain.

Why not instead create contextual links that open the layout builder form, then launch the configuration screen for that inline block? Roughly the the same experience, with the added benefit of having all the above problems disappear and you also get layout builders preview facility.

I think we should remain open to the idea of reusable inline blocks. From the editor's point of view, they can edit the block in a place it's being used. The alternative to make them use the custom block library, which requires the 'administer blocks' permission, which I don't give editors for obvious reasons.

I don't think there will be any reasonable way this can be allowed and these issues can be remedied. Any change to an inline block means some revision of the host entity must be updated to point to some other revision of the inline block. It's not possible to save a revision of the host entity, without the user being granted access to do so and without the same user making explicit choices.

This was solved in D7 with Fieldable Panels Panes. A pane can be designated as either reusable or not. After creation, there's no changing that designation. If it's non-reusable, then everything works pretty much as Layout Builder and Inline Blocks works now. They're tied together. If it's reusable, then the host entity's reference is to whatever the current published revision of the pane happens to be; it's not tied to a specific revision ID. As a result, there's no need to update a host entity when the reusuable pane is updated - no matter where it's updated.

I created a contrib (Layout Builder Inline Block Quick Edit) module that tries to face this problem. It "overwrites" the block revisions with the latest block revisions on load for draft layout entities and activates the contextual links. The idea behind is not to update the host entity when a new block revision is created, but to load the right revision in dynamic manner on load.

Quick edit checks, if a new revision is needed, before saving.

It is quite hacky and more a technical preview - but maybe it could be a solution in order to delegate the revision loading to contrib.

Why not instead create contextual links that open the layout builder form, then launch the configuration screen for that inline block? Roughly the the same experience, with the added benefit of having all the above problems disappear and you also get layout builders preview facility.

This would definitely be a good/better editor experience. If contextual links are allowed on inline blocks (currently they are not, due to this issue) the edit link could (or should in my opinion) open the layout builder form and the inline blocks' edit form.

I thought I'd see if I could do a proof of concept but I realised just how much layout builder code there is and while I managed to get a hard coded example up and running I wasn't able to have something flexible worth offering as a patch. Probably someone who knows LB inside out needs to take a look at implementing this.

The things I noted are:

1. There might need to be a new contextual_links group with just the update route in it (maybe renamed to edit) so only that link shows up and not the other LB move or delete links.
2. The normal block edit link should be overwritten by the layout builder one
3. The quickedit link should remain as it works well

At the very least, from a user's perspective, the block's quick edit link should be available but not the block edit link. Then an ideal feature update would be to include the edit link but have it opening the layout builder on the block edit/update form.

I got this started from the editing side.

With the issue fork, you can add ?edit=UUID-FOR-THE-BLOCK-TO-EDIT, and layout builder will open the right block form on load.

I'm not sure what it will take to link to this, but if we can get contextual links added, it should work.
Looking for feedback on the approach and query parameter name.

I think the ability to edit inline blocks from the front end makes the most sense for UX. I would like to see contextual links that bring up a modal. 90% of the time I'm an admin editing the latest revision and I want to save and create a revision according to the "create revision by default" setting. There may need to be some configuration options, and a confirmation form to make decisions about things depending on what state it's in. It sounds like there are a pile of technical reasons why this is hard, but it would be great to start structuring the basics and work out the edge cases over time.

Should the issue title be changed? I think it should now be "Add contextual link to inline blocks to edit in layout builder".

This issue component is set as block_content.module, but I think this applies to all inline blocks in layout builder.

Since this could be a behavior change from some, probably will need a CR I would assume. Since we are denying something that was previously allowed.

CR reads fine to me.

Ran test only change and got

1) Drupal\Tests\layout_builder\FunctionalJavascript\InlineBlockTest::testDeletion
Failed asserting that an object is empty.
/builds/issue/drupal-3075308/core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockTest.php:464
2) Drupal\Tests\layout_builder\FunctionalJavascript\InlineBlockTest::testAccess
Behat\Mink\Exception\ResponseTextException: The text "You are not authorized to access this page" was not found anywhere in the text of the current page.
/builds/issue/drupal-3075308/vendor/behat/mink/src/WebAssert.php:907
/builds/issue/drupal-3075308/vendor/behat/mink/src/WebAssert.php:293
/builds/issue/drupal-3075308/core/tests/Drupal/Tests/WebAssert.php:981
/builds/issue/drupal-3075308/core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockTest.php:515
FAILURES!
Tests: 11, Assertions: 230, Failures: 2.
Exiting with EXIT_CODE=1

Manually test on an Umami install I had
1. In the article content type Full content layout builder I added a test block
2. I went to /admin/content/block/5 where I can see the block and make edits
3. Added MR
4. That route is no longer accessible

Change looks good to me.

This makes sense to me, tagging needs follow-up for the idea of contextual links from the block going back to the layout builder edit page. But also I wonder what XB/Canvas is going to end up doing with things like that whether for embedded entities or SDC content.

Committed/pushed to 11.x, thanks!

Think this commit might have broken HEAD:

There was 1 PHPUnit test runner deprecation:
    
    1) Metadata found in doc-comment for class Drupal\Tests\block_content\Functional\BlockContentRouteAccessTest. Metadata in doc-comments is deprecated and will no longer be supported in PHPUnit 12. Update your test code to use attributes instead.

https://git.drupalcode.org/project/drupal/-/merge_requests/13214 to fix the deprecation of the test annotation.

This broke HEAD; unit tests are not passing because of the deprecation. The follow-up MR needs to be merged tout-de-suite.

critical while head testing is broken

Thanks for the quick MR. Committed/pushed to 11.x, thanks!