Custom blocks break layout builder module - Quick Edit could not associate the rendered entity field markup

I'm also seeing this is 8.6.7 on a fresh install with Layout Builder being the only additional module turned on. You can also get the same error by creating a custom block via Layout builder (Layout -> Add Block -> Create custom block).

Does the presence of a custom block break _all_ of the integration? Meaning, can you quickedit any other fields alongside the brokenness.

With the presence of a custom block, quick edit is missing from the contextual links. Removing the custom block restores the quick edit option.

We're also experiencing this issue.

The issue does break the quick edit for everything on the page, removing the block from layout builder restores it. If you put the same block on the page using Block Layout you don't get the error and quick edit works.

I see that block edit in blocks created from Layout Builder didn't save the changes. I'll try to look into permissions but I think that needs to be enabled by default.

Maybe this issues could be related.

This is breaking all of the theming javascript we have on the page.

+1. Confirming issue still exist, even with a fresh umami installation.

@tamparpe Thanks for the detailed description of the provided in #9

There are 2 reasons our tests didn't fail for this

1. We don't have test that uses inline blocks and has user that has permission to access quickedit
2. Even if we had this test our tests don't fail if there is Javascript error on the page. So unless the error broke core's functionality the test would still pass.

   So I created #3091870: Fail Functional Javascript tests that throw Javascript errors

   This is important because the site could have non-core JS on the page that will not run if there is another JS error on the page. I talked with @tamarpe at DrupalCon Amsterdam and I think this the problem that she has been experiencing.

I am uploading 2 patches.

1. 1 with a test that extends \Drupal\Tests\layout_builder\FunctionalJavascript\InlineBlockTest but enables QuickEdit and gives the test users quickedit permission.

   This test will pass because of 2) above.

2. The other will be combined with #3091870: Fail Functional Javascript tests that throw Javascript errors to prove it would fail if we took into account JS errors.

Hi.

I'm uploading a possible solution based on the tests from #10.

The quickedit.module quickedit_entity_view_alter function add the attribute data-quickedit-entity-id to the block ($block['#attributes']['data-quickedit-entity-id']).

Following the debugger, it was called by layout_builder EventSubscriber BlockComponentRenderArray->onBuildRender().

At this function, it adds layout_builder block inside content array render param, but doesn't implement the #attributes array.

So, what happens is that #attributes is not defined on $build render array, but on $build['content'] render array, being totally ignored when rendering our field.

My proposal is to set the $build['#attributes'] with legacy value from $build['content']['#attributes']. I'm doing that on file core/modules/layout_builder/src/EventSubscriber/BlockComponentRenderArray.php at line #120:

      $build = [
        // @todo Move this to BlockBase in https://www.drupal.org/node/2931040.
        '#theme' => 'block',
        '#configuration' => $block->getConfiguration(),
        '#plugin_id' => $block->getPluginId(),
        '#base_plugin_id' => $block->getBaseId(),
        '#derivative_plugin_id' => $block->getDerivativeId(),
        '#weight' => $event->getComponent()->getWeight(),
        '#attributes' => isset($content['#attributes']) ? $content['#attributes'] : [],
        'content' => $content,
      ];

Patch 3072231-12.patch is both tests from #10 and the fix, while patch 3072231-12-plus-3091870-2.patch has also the code from patch #3091870: Fail Functional Javascript tests that throw Javascript errors.

Also adding patch 3072231-13-core-8-7-x.patch for Drupal Core 8.7 (actual stable version).

Adding an 8.8.x version as well

Rerolling a testbot-only version of the patch (with drupalci changes) for branches other than the current development branch is not very helpful.

In the meantime, as #10 shows, this test is not viable without waiting for #3091870: Fail Functional Javascript tests that throw Javascript errors. Postponing on that.

#15 is working for me on Drupal 8.8.1. Thanks!

#15 fixes it for me on Drupal 8.8.1 - Thank you

This is a rerolled of #15

#15 applied successfully on 8.8.2 but didn't on 8.8.3

3072231-20-core-8-8-x-.patch confirmed working with Drupal 8.8.4/8.8.5 too.

Fails on 8.9.0

+1

it is not working for me as well for Drupal 8.9.0 version

I applied that patch to 8.9.0 it seems to work in a way, that it resolves the javascript error and adds the the needed attribute.
But quick edit for blocks in layout builder still does not work.

Here's a reroll against 8.9.1

I felt a bit uncomfortable doing it because I can't make sense of all the deletions made to drupalci.yml, but this is based on the previous patches.

The drupalci.yml changes are just to hack the testbot to only run one particular test. Those don't need to stay in for future rerolls.

The attached patch is a re-roll of #27 (without the drupalci.yml changes) that applies cleanly to 9.1.x.

The attached patch updates the expected render array structures contained in the following tests to include an #attributes element with an empty array to address the test failures in #29:

• BlockComponentRenderArrayTest::testOnBuildRender()
• BlockComponentRenderArrayTest::testOnBuildRenderWithoutPreviewFallbackString()
• SectionRenderTest::testToRenderArray()
• SectionRenderTest::testContextAwareBlock()

Failed to notice the existing coding standards issues with #27, #29. The attached patch addresses the coding standards issues in InlineBlockQuickeditEnabledTest.php

the patches didnt work for me, so I'm guessing there is no working patch for 8.9-x yet...

This will need to get fixed in 9.1.x first.

I have tried this patch #31 for current D9.03 but I still get... so what am I doing wrong? or is something wrong with Radix Theme?

I just use a custom Block where included an Media Image SVG via CKEditor.

Uncaught Error: Quick Edit could not associate the rendered entity field markup (with [data-quickedit-field-id="media/7/thumbnail/en/media_library"]) with the corresponding rendered entity markup: no parent DOM node found with [data-quickedit-entity-id="media/7"]. This is typically caused by the theme's template for this entity type forgetting to print the attributes.

The patch also doesn't do anything for me on 9.0.3. I still get the JS error. I've got a custom block attached to a header of a view as a rendered entity.

@joegraduate please help us as patch is not working for any Drupal 9 version.

Rerolled patch #26 for drupal 8.9.7

The attached patch is a 9.2.x re-roll of #31 that also updates the visibility of the $modules property of the InlineBlockQuickeditEnabledTest class in accordance with this change record: https://www.drupal.org/node/2909426 which hopefully addresses the weird failure now showing up for #31.

I'm not sure whether this should be a separate issue, but closely related is:

1. Add custom inline block to layout builder
2. Quickedit JS makes an AJAX post request to /quickedit/metadata
3. Response is 404, because POST form data includes things that look like this:
   • fields[]: block_content//field_name/en/full
   • entities[]: block_content/

This is occurring because the data-quickedit-field-id and data-quickedit-entity-id include the entity ID, which at this point is null because those custom block entities have not yet been saved.

Seems that the POST requests can be prevented from being sent at all by not adding the attributes if $entity->id() is null. Something like this, perhaps?

diff --git a/core/modules/quickedit/quickedit.module b/core/modules/quickedit/quickedit.module
index 38298d562e..31a627505e 100644
--- a/core/modules/quickedit/quickedit.module
+++ b/core/modules/quickedit/quickedit.module
@@ -134,7 +134,7 @@ function quickedit_preprocess_field(&$variables) {
   /** @var \Drupal\Core\Entity\ContentEntityInterface $entity */
   $entity = $element['#object'];

-  if (!\Drupal::currentUser()->hasPermission('access in-place editing') || ($entity instanceof RevisionableInterface && !$entity->isLatestRevision())) {
+  if (is_null($entity->id()) || !\Drupal::currentUser()->hasPermission('access in-place editing') || ($entity instanceof RevisionableInterface && !$entity->isLatestRevision())) {
     return;
   }

@@ -163,7 +163,7 @@ function quickedit_entity_view_alter(&$build, EntityInterface $entity, EntityVie
   }

   $build['#cache']['contexts'][] = 'user.permissions';
-  if (!\Drupal::currentUser()->hasPermission('access in-place editing') || ($entity instanceof RevisionableInterface && !$entity->isLatestRevision())) {
+  if (is_null($entity->id()) || !\Drupal::currentUser()->hasPermission('access in-place editing') || ($entity instanceof RevisionableInterface && !$entity->isLatestRevision())) {
     return;
   }

I used a paragraph from an paragraph library. I still got this error:

Uncaught Error: Quick Edit could not associate the rendered entity field markup (with [data-quickedit-field-id="paragraphs_library_item/2/paragraphs/de/default"]) with the corresponding rendered entity markup: no parent DOM node found with [data-quickedit-entity-id="paragraphs_library_item/2"]. This is typically caused by the theme's template for this entity type forgetting to print the attributes.

Reworked patch from #37

I'm seeing this error for block_content, media, and paragraphs. I've looked at https://www.drupal.org/project/drupal/issues/3101267 as well. Using a preprocess hook and/or modifying the twig files does fix the issue...however I feel that shouldn't be necessary. The patches here only fix the issue for custom blocks...however the issue still exists for media and paragraphs.

Reworked #37 again

#45 resolved my issue, here is a fixed patch (hopefully)

Per #3072231-16: Custom blocks break layout builder module - Quick Edit could not associate the rendered entity field markup and the resolution of #3091870: Fail Functional Javascript tests that throw Javascript errors, returning this to 'Needs Review' pending tim.plunkett's preferences.

This patch with just the tests should fail. Moving to an MR for the real work with the fix.

Note that this will need to be redone if #3228634: Move tests for integrations between QuickEdit and other modules into QuickEdit so that it can more easily be moved into contrib lands first.

Okay the patch in #48 failed as expected, and the MR branch is green!
Can someone manually test the code in the MR and RTBC the issue?

Looks great!

+1 to RTBC, applied MR as `/diffs.patch` and the error message no longer appears. After enabling QuickEdit, I can edit `block_content` fields via QuickEdit without issue and error message.

Manually tested this and confirmed it does enable quick-edit for LB

However, not sure it works as intended.

Do we have an existing issue for this?

@godotislate can you open a separate issue for that - unrelated to the work here I think

Updating issue credits.

There are several reports here about this enabling editing of custom blocks via quick edit.

I don't think that is the scope here, the scope is fixing the broken JS error.

@tim.plunkett @tedbow as subsystem maintainers - I assume you agree given you both worked on the patch

The MR looks good to me, just waiting for an answer if we have follow-ups for the other reported issues.

#3020876: Contextual links of reusable content blocks are not displayed when rendering entities built via Layout Builder was another issue that added in #attributes. It had a lot more research put into it, judging by the comment added to the code base. I rebased this MR accordingly.

I haven't looked into #55 though...

#39 partly worked for me.

Drupal 9.2.7

Installed patch, cleared chache. At first page load got this on-page error, which didn't show up ever again:

Notice: Undefined index: comment_body in Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions() (line 102 of core\modules\layout_builder\src\Plugin\Derivative\FieldBlockDeriver.php).

And in the console:

Uncaught Error: Quick Edit could not associate the rendered entity field markup (with [data-quickedit-field-id="media/2/field_media_image/ru/full"]) with the corresponding rendered entity markup: no parent DOM node found with [data-quickedit-entity-id="media/2"]. This is typically caused by the theme's template for this entity type forgetting to print the attributes.

However, the patch actually did something ))) Because before the error was different:

Uncaught Error: Quick Edit could not associate the rendered entity field markup (with [data-quickedit-field-id="block_content/13/body/ru/full"]) with the corresponding rendered entity markup: no parent DOM node found with [data-quickedit-entity-id="block_content/13"]. This is typically caused by the theme's template for this entity type forgetting to print the attributes.

So, probably it fixed the custom block issue, but there is still a problem with media.

I have LB page with custom blocks, inline media, background videos and images, slick views carousel.

Attached patch is a re-roll of #39 that should apply cleanly to the latest 9.2.x branch.

Hello @joegraduate.
Your patch gives an error.

'#attributes' => '#attributes' => $content['#attributes'] ?? []
should probably be :
'#attributes' => $content['#attributes'] ?? []

You're right.

I've updated patch.

Okay so work on the dev version of Drupal was happening in the MR and now there are patches for 9.2 that are different. And the MR is not passing tests at the moment.
Please help get the MR back to working against latest Drupal before sidetracking it with backports

There is no 9.4.x at the time of writing so I've rebased the MR against 9.3.x (9.3.0 plus xjm's Back to dev patch) - and added the interdiff to #61. There were no rejects when rebasing and the reject in applying #61 is trivial so I have high confidence everything is good, but it needs more review and testing yet so updating the status to needs review.

Adding S3b0uN3t to the credits since their patch is added into the mix.

Attaching a patch against 9.3.x for those who want it. Attempting to generate an interdiff from #61 failed, sorry.

Ok, now I've been able to get 9.4.x. Rebased without any rejects.

Restored initial MR to 9.3.x and made a new one for 9.4.x. Sorry for the noise - still learning how to handle git branches in this new infrastructure.

Confirming patch #65 is not working well in core 9.3.7 after upgrading from Drupal 8.9.

This is patch #65 updated for 9.5.x. Posting for convenience, mostly my own, but hopefully it helps others ;)

Fixed failed commands on #73
Attached patch against Drupal 10.1.x
Attached reroll patch for Reference

Fix Patch failed to apply for patch #74.
Please review.

Patch #75 no longer applies for D9.5

Per #79, #75 is tested for 10.1.x, so I suspect that is the culprit. Please see #73 for a 9.5 patch.

For contributors: please read comment #3072231-62: Custom blocks break layout builder module - Quick Edit could not associate the rendered entity field markup before contributing. If you are contributing fixes to bring the code in alignment for RTBC, please contribute work into the MR, not into patches (especially those without an interdiff, as in #75).

You do not need to submit a patch to receive contribution credit, so please be mindful of the previous work done in this issue.

Additionally, this is NW because we have a failing test - that is the next step in getting this resolved.

Now quick edit has moved to contrib, should this go in the quickedit contrib issue queue?

Reroll for 9.5.x.

Patch for 10.x and Try to cs issue fix.. or Re-roll patch #82

Fixed failed commands on #83
Attached patch against Drupal 10.1.x

fix failures

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

This seems like it should have it's own test cases.

Is #attributes' => [], now required? Will this break existing sites?