Can't manage Status Messages block in Layout Builder

I had exactly the same issue.

The problem resides on the block--system-messages-block.html.twig template that does not output the contextual links in purpouse to not render the block if there are no messages.

So, the workaround I used to remove the "Message blocks" is to create a file called "block--system-messages-block.html.twig" under your theme "templates" folder and use the default "block.html.twig" as content of the file. Once you have removed the "Message blocks" you should remove the file "block--system-messages-block.html.twig" to have it styled correctly.

Hope it helps ;-)

Here's a patch that might help people with this bug. It updates the block--system-block-messages in Stable template to show contextual links if the messages block is placed using Layout Builder.

There also may be an ugly way to handle moving the Messages block until this issue is fixed if you don't want to apply a patch. You can click the "move" contextual link on a different block in the section. A sidebar will pop up in which you should be able to see the Message block.

UPDATE: The failure is because the patch modifies Stable, which of course is not stable.

I'm also attaching a more ambitious patch that is a much more general and might promote discussion on this bug.

It seems to me that it is useful to know if a block is being rendered in the Layout Builder UI. This bug with the Messages block is one example; there are likely other blocks with this problem either core or contributed. This patch adds a new boolean to the block render array called layout_builder_preview. It can be used in templates directly or it could potentially be used for creating new theme suggestions.

I am working on it.

Solved test case issue, kindly check

Thanks for jumping in @shaktik!

That failed quickedit test seems weird and unrelated to this. Do you think that is related to #3037436: [random test failure] Make QuickEditIntegrationTest more robust and fail proof?

It would be nice to get some conversation going around whether people think the #layout_builder_preview variable would be generally useful for blocks.

I have tested the failer test case on my local after applying the patch and its working fine.

bash-3.2# ./vendor/bin/phpunit -c core/ --filter testArticleNode core/modules/quickedit/tests/src/FunctionalJavascript/QuickEditIntegrationTest.php
PHPUnit 8.5.5 by Sebastian Bergmann and contributors.

Testing Drupal\Tests\quickedit\FunctionalJavascript\QuickEditIntegrationTest
.                                                                   1 / 1 (100%)

Time: 1.12 minutes, Memory: 8.00 MB

OK (1 test, 103 assertions)

but I am not able to understand why is failing on drupal ci. can anyone suggest me.

#15 is a random failure, re-queued.

1. +++ b/core/modules/layout_builder/tests/src/Unit/BlockComponentRenderArrayTest.php
   @@ -120,6 +120,7 @@ public function testOnBuildRender($refinable_dependent_access) {
   +      '#layout_builder_preview' => false
   
   @@ -195,6 +196,7 @@ public function testOnBuildRenderWithoutPreviewFallbackString($refinable_depende
   +      '#layout_builder_preview' => false
   
   @@ -324,6 +326,7 @@ public function testOnBuildRenderInPreview($refinable_dependent_access) {
   +      '#layout_builder_preview' => true
   
   @@ -332,6 +335,7 @@ public function testOnBuildRenderInPreview($refinable_dependent_access) {
   +      '#layout_builder_preview' => true
   
   @@ -383,6 +387,7 @@ public function testOnBuildRenderInPreviewEmptyBuild() {
   +      '#layout_builder_preview' => true
   
   +++ b/core/modules/layout_builder/tests/src/Unit/SectionRenderTest.php
   @@ -115,6 +115,7 @@ public function testToRenderArray() {
   +      '#layout_builder_preview' => false
   
   @@ -198,6 +199,7 @@ public function testToRenderArrayPreview() {
   +      '#layout_builder_preview' => true
   

   • true -> TRUE, false -> FALSE
   • missing , as the last item in an array.

2. +++ b/core/themes/stable/templates/block/block--system-messages-block.html.twig
   @@ -4,10 +4,24 @@
   + * there are no messages. Add contextual links only if in the Layout Builder
   + * UI.
   

   Wrapped too early. It should be one line "there are no messages. Add contextual links only if in the Layout Builder UI."

hi @jungle
made changes please review.

Verified and tested by applying the patch #21.Patch was applied successfully but the issues wasn't fixed yet.Verified and tested on Drupal 9.0.0 and sandbox.

Steps to test -
1. Go to admin site.
2. Go to admin/modules.
3. Enable layout builder
4. Go to admin/structure/block.
5. Place the status messages block to content type.
6. Go to admin/structure/types/manage/article/display/default/layout.
7. Add the messages block.
8. Verify

Patch Applied -

After_Sandbox -

After_Local -

After_Local -

@priyanka.sahni, that video is awesome!

The messages block is showing up, which I think is an improvement. Can it be dragged around?

The placeholder text misbehaves a little bit because the messages block isn't empty. It has content even when it's in the Layout Builder UI. That's different from other blocks. At least I think that's what's going on.

Ugh, this is my fault. I tested my change to the Stable template on a D8 site. In D9 it looks like the Messages block renders using a template in the system module, which the patch does not alter.

Seeing that there's some real interest in this issue now, I think I'm going to write a test for this. That way we'll be defining exactly what the expected behavior is after the patch. Just thinking now, the test should probably check:

1. the ability to drag the Messages block
2. the presence of contextual links for the Messages block
3. the placeholder text for the Messages block

I'll post a couple patches in the next couple days hopefully.

The FAIL patch adds a test to LayoutBuilderTest, a FunctionalJavascript test in layout_builder. The new test tests that a Messages block added to the Layout Builder UI has

1. The correct placeholder text
2. Can be dragged to a different section
3. Can be removed

The other patch includes this new test plus it updates the messages block template in the system module. The interdiff just shows this change.

+++ b/core/modules/layout_builder/tests/src/Unit/SectionRenderTest.php
@@ -115,6 +115,7 @@ public function testToRenderArray() {
+      '#layout_builder_preview' => false

@@ -198,6 +199,7 @@ public function testToRenderArrayPreview() {
+      '#layout_builder_preview' => true

@@ -254,6 +256,7 @@ public function testContextAwareBlock() {
+      '#layout_builder_preview' => false

false -> FALSE, true -> TRUE.

Hi @jungle
Uodated patch please review.

I stumbled upon and issue that might be useful here once it is resolved: https://www.drupal.org/node/3027653

I performed Novice Issue triage on this issue. There are some clear steps to move this step forward.

The latest patch needs to be re-rolled for Drupal 9.2.x.
Additionally we should update the issue summary with the issue summary update. This could also include providing screenshots in the steps to reproduce section of the issue summary. Adding an After screenshot after we get a working patch for 9.2.x would also be needed.

I am testing as a Novice at DrupalCon 2021

I am testing and will edit the issue.

Next, I'll post screenshots of the issue

I removed Needs issue summary update tag for now.

@rhovland is having trouble getting things posted, but wanted to link https://www.drupal.org/project/facets/issues/3027593 as a related issue.

To reproduce the issue, I did the following:
1. Go to admin site
2. Extend> Enable the layout builder module
3. Structure> Block Layout, place Messages (Category: systems) block to content type
4. Go to structure> Content Types> Article> Manage Display> Manage layout
5. Add message block

Just updating that I am stopping my work on this issue today.

Re-rolling the patch

I'm currently attempting to reroll this patch.

Removed part of the patch that references `core/tests/Drupal/KernelTests/Core/Theme/StableDecoupledTest.php`.

Double checked @k_a_l s patch

The test StableDecoupledTest was removed in 9.1.x
https://git.drupalcode.org/project/drupal/-/commit/c509626db3fa0927b2bb3...

It was no longer needed in core so the modifications in the patch have been removed.

diff --git a/core/modules/block/block.module b/core/modules/block/block.module
index ec7e0ed7d8..53f912b87c 100644

@K_a_l removed the chunk in the diff that didn't apply and re-uploaded the patch in #30.

@rhovland applied the patch in #44 based on 9.2.x and re-rolled the patch based on the latest HEAD.

So the patch in #44 is correct to review / test.

Didn't need to move back to Needs work. Also need to remove Needs reroll

Patch #48 Applied cleanly and working as expected , block is visible and able to modified the block . Sharing screenshot for reference.

Verified and tested patch#44. Patch applied successfully and looks good to me

Testing Steps:
1. Go to admin site.
2. Go to admin/modules.
3. Enable layout builder
4. Go to admin/structure/block.
5. Place the 'messages' block to content type.
6. Go to admin/structure/types/manage/article/display/default/layout.
7. Add the messages block.and verify

Testing Results:
When you add the "Messages" system block to layout builder, it creates hidden block. It isn't able to be modified or deleted.: Fixed

Thank you for the additional testing and screenshots, @MeaghanSmith and @Poojita0802 and @Madhu kumar.

After we add screenshots we also want to embed or add them in the issue summary so it is easy for someone triaging and reviewing the issue to see the before and after. The video is especially helpful, and I think that a link to the video should be in the issue summary too. (edit) I would keep Meaghan's before screenshot, add Poojita's video as a link, and add Madhu's after screenshot.

Also after we do that we usually remove the "Needs manual testing" tag. I removed it, but I also added "Needs issue summary update". If someone could come in today and format the issue summary with the After screenshot as well as detailing what the Proposed resolution is that would be great!

When updating the issue summary, also try to answer the other sections. If you're unsure, you can mention in a comment that you weren't sure, but you can also ask in Drupal Slack #contribute or #easy-out-of-the-box and ping the Drupal user who wrote or uploaded the patch.

Today I want to work on the issue summary.

I've updated the proposed solution.

I have made changes to the issue summary.

Thank you for updating the Issue Summary, ojchris37

This looks a lot better now and I think we have enough explanation for the maintainers to commit this.

Thank you all for working on this!

Fixed the fail test, It is related to the "deprecation notices" and move to RTBC as suggested in #65.

Hi All! Great work on this.

I was the one way back when who started the approach where we add the layout_builder_preview variable to Block render arrays. I am convinced this is the wrong approach. It's heavy-handed and seems likely to break tests in the contrib space, the same way it required a lot of tests to be updated in core.

I think a better approach will be to piggy-back off of whatever comes out of #3027653: Allow block and layout plugins to determine if they are being previewed. The current approach there looks really good and seems much less likely to break tests in the contrib space. Assuming patch doesn't change too much, the approach here would be to update the Annotation for the Messages block to include the context_definitions and then update the build function of the Messages block to return different values depending on context. In this approach I think we'd only have to make changes to the Message block plugin and the Message template. That seems like a smoother approach.

Regardless of the approach, the tests we have should be great. We're solving the same problem, after all, regardless of how we solve it.

Here's an issue that just landed that I've been keeping an eye on, anticipating that it would make our issue with the Status Message block easy to solve: #3027653: Allow block and layout plugins to determine if they are being previewed

I mentioned this first in #32

Change record is here: Block and layout plugins can now determine if they are being rendered in preview mode

I think it would be great to see if there's a good way to leverage that new feature to create an elegant fix here.

Trying this with a much smaller patch, thanks to #3027653: Allow block and layout plugins to determine if they are being previewed. Not sure if the test is redundant since this is basically just asserting that a preview fallback string is being used for the messages block; will need a maintainer to render an opinion on this.

@clayfreeman, I think you should be able to repurpose the fail test in #27 (which is named as if it's in the 26th comment. Oops!). That test makes sure you can move the block around, which is really what this issue is about.

Not sure what that failed build is about though.

@danflanagan8 I believe the test failure was a fluke. I did repurpose a portion of that test, but I think it's sufficient to just check that the preview fallback string appears (since the root cause of not being able to manipulate the block is that it has no content).

he root cause of not being able to manipulate the block is that it has no content

I believe the root cause is that the status message block does not render {{ title_prefix }} which means that contextual links don't render as pointed out in #3

Here's what I see after applying the patch in #72. Status message have placeholder text, but no contextual links.

When I hover over the Body block I do get contextual links.

But I guess it's more than just {{ title_prefix }} that we need, because the drag-and-drop functionality relies on the attributes being rendered in the block template, another thing that the status-messages template is missing.

Ah, I see what you mean now. The issue description was deceptively simplistic; it could probably use an update.

I think we should postpone this on #3273317: Add 'in_preview' variable to block and layout templates, which will add the in_preview variable to the block template. I think this issue has a good chance of being committed quickly, then the work here can continue without any scope creep.

@clayfreeman, 100% agree with your idea to postpone. That issue will make this one super easy!

I added a bit to the IS to explain the issue a little more thoroughly.

Blocking issue just got fixed! No longer postponed.

There's a good fail test in #27 that we can test against. I'm not 100% convinced this is really a novice issue, but I'll leave that tag on and hopefully a novice contributor will take on the challenge!

I'm updating the IS with the latest proposed solution.

Included a patch trying to follow the IS, uses the test from #27. Please review!

I'm not sure if it's in scope of this issue or not but when using the olivero theme with the updated template, placeholder content is still displayed when 'Show content preview' is unchecked. This is because the olivero theme uses cores block--system-messages-block.html.twig template. I yanked this from oliveros block.html.twig template and it seemed to sort the issue:

    <div{{ content_attributes.addClass('block__content') }}>
      {{ content }}
    </div>

At some point the olivero theme will need to include an override template so the messages block matches the styling of the other blocks when in preview mode.

Thanks, @jnlar!

This should be a completely new approach compared to patch 71 (on comment #72), so the interdiff is not especially helpful. I think a more helpful interdiff would be relative to the fail test that you are starting with, which is from comment #27. That way the interdiff will show what the fix is. Also it looks like 71 (aka 72) has different test coverage, which makes the interdiff noisy.

I'm removing the Novice tag now.

Cheers for pointing that out @danflanagan8, my bad there. I've attached an interdiff against your failed test patch in comment #27

I have applied patch #85. Patch failed .
Got below errors after applying patch.

Checking patch core/modules/layout_builder/tests/src/FunctionalJavascript/LayoutBuilderTest.php...
error: while searching for:
  }

  /**
   * Tests the Messages block in the Layout Builder UI.
   */
  public function testMessagesBlock() {
    $assert_session = $this->assertSession();
    $page = $this->getSession()->getPage();

    $this->drupalGet('admin/structure/types/manage/bundle_with_section_field/display/default');
    $this->submitForm(['layout[enabled]' => TRUE], 'Save');

    $this->drupalGet("admin/structure/types/manage/bundle_with_section_field/display/default/layout");
    $this->openAddBlockForm('Messages');
    $page->pressButton('Add block');

    $assert_session->assertWaitOnAjaxRequest();
    $assert_session->elementTextContains('css', '.layout__region--content', '"Messages" block');
  }

  /**
   * {@inheritdoc}
   *
    $assert_session->linkNotExists('Add block');
  }

  /**

error: patch failed: core/modules/layout_builder/tests/src/FunctionalJavascript/LayoutBuilderTest.php:396
error: core/modules/layout_builder/tests/src/FunctionalJavascript/LayoutBuilderTest.php: patch does not apply
Checking patch core/modules/system/templates/block--system-messages-block.html.twig...
Checking patch core/themes/stable9/templates/block/block--system-messages-block.html.twig...

can be moved to " Needs Work"

@Bushra Shaikh, the file attached with #85 is not a patch, it's an interdiff. That's why it won't apply.

@jnlar, thank you for the updated interdiff! I have a few comments.

1. I think the following code change can be removed. We should be able to rely on the in_preview variable without having to update the block's build method.

+++ b/core/modules/system/src/Plugin/Block/SystemMessagesBlock.php
@@ -31,7 +31,9 @@ public function defaultConfiguration() {
- return [
+ // Use preview fallback by returning an empty render array in preview mode.
+ // The block cannot be manipulated otherwise.
+ return $this->inPreview ? [] : [

2. I'm the one who posted the fail test in #27 (three years ago!), so this one is my fault. Can you remove this line from the docbloc comment of the new test method?

+   * See https://www.drupal.org/project/drupal/issues/3137995.

Other than that I think it looks great! Unfortunately I won't be able to RTBC because I added the fail test. Once it looks good to me, though, I'll try to find someone to RTBC it. Thanks!

Thanks for the review @danflanagan8,

Regarding 1, I noticed that leaving the blocks build() method as is without $this->inPreview ? [] : [... results in the placeholder content being the message block itself (if it isn't hidden).

If 'Display title' for the messages block is unchecked and 'Show content preview' is checked, and you haven't made changes yet, you won't see anything except for the contextual link icon when you hover over the block in layout builder:

After making any change:

From what I understand returning an empty render array means we'll use the preview fallback opposed to ::generatePlaceholder in StatusMessages which seems to be the cause.

@jnlar, I see what you mean! Placeholder text and also the preview were things I had not considered. I think we may need to add test coverage specifically for the preview. It looks like there's already (a little) coverage for the placeholder text in the new test.

What does the preview look like when using the patch in #83?

@danflanagan8 here's a screenshot of the preview using patch #83

Agreed, would another elementTextContains assertion suffice?

// Part 1: Check for Messages placeholder text.
$assert_session->elementTextContains('css', '.layout__region--content', '"Messages" block');
+ $assert_session->elementTextContains('css', '.layout__region--content', 'Placeholder for the "Messages" block');

Added test coverage for preview placeholder text, removed line in comment mentioned by @danflanagan8 in #88

Hi @jnlar,
I finally found some time to look at this again and actually think about carefully again. I want to summarize where we are here.

1. The modification to the template is all that is required to allow the Messages block to be managed within LB.
2. The modification to SystemMessagesBlock::build() is a UX enhancement for when "Show content preview" is checked.

I might argue that we should defer #2 to a follow-up. The reason I say that is that it might be worth getting a usability review. It's not obvious to me what is the most desirable UX. Here are the two version of preview UX.

A) With the update to SystemMessagesBlock::build() in #93

"Show content preview" unchecked

"Show content preview" checked, no active status message

"Show content preview" checked, with active status message

B) No modification to SystemMessagesBlock::build()

"Show content preview" unchecked

"Show content preview" checked, no active status message

"Show content preview" checked, with active status message

Both of these approaches allow the Messages block to be managed in LB. Remember, the change to the template is all that's needed to restore contextual filters and the attributes required by LB. Changing or not changing SystemMessagesBlock::build() is all a question of preferred UX.

In my opinion, Approach A is probably more usable, but Approach B gives a more-realistic content preview, which is one of the goals of LB. So I don't know which way to go!

If we were to take Approach A and keep moving with the patch in #93, I would say the test coverage needs to check the "Show content preview" box at some point and confirm that the placeholder text remains. During content preview is where the placeholder text is really supposed to appear. I don't think it's quite a bug that the placeholder text appears even when the content preview box is unchecked, but that's different from how the "Links" field behaves, for example.

I'm going to leave this at NR for now.

hi @danflanagan8,

Thanks for the summary, that'll also help bring newcomers up to speed.

I agree, the issue defined in the IS is not being able to manage the Messages block in LB. It isn't obvious to me whether or not #2 is within the scope of the IS.

I'm for deferring #2 with a follow up, more eyes on this would be good.

In my opinion, Approach A is probably more usable, but Approach B gives a more-realistic content preview, which is one of the goals of LB. So I don't know which way to go!

It does give a more realistic content preview, but you can argue that a realistic preview isn't needed for the Messages block in LB, AFAIK every other preview in LB is using placeholder content.

I don't think it's quite a bug that the placeholder text appears even when the content preview box is unchecked, but that's different from how the "Links" field behaves, for example.

I don't think so either, the olivero theme is responsible for that behaviour. The theme wraps a blocks {{ content }} in a div with the block__content class. When "Show content preview" is unchecked it's display is set to none.

In addition

Not sure if this one block deserves it's own test instance.

Could this be added to testLayoutBuilderUi