10.3 upgrade now missing status-message theme suggestions

I looked through every change record for that release. https://www.drupal.org/node/3304793 stands out as possibly relevant. Could you investigate that?

Performing a git bisect on a Git checkout of Drupal Core between the release tag you were on and the release tag that introduced the regression will very quickly find the regression commit.

I noticed this too. I'm not sure how expanding the core theme suggestions for block view modes would remove the hook entirely for theme suggestions for the status_messages.

It may not be the cause. As I mentioned git bisect will identify the issue quickly.

#3456525: status message notification twig file name changed

I've enabled twig debug in Drupal 10.3.x on the standard profile, install the system test module and used drush php to do \Drupal::state()->set('system_test.front_page_output', 1); and visited the front page.... I see

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'status_messages' -->
<!-- BEGIN OUTPUT from 'core/themes/olivero/templates/misc/status-messages.html.twig' -->

If I change core/themes/olivero/templates/misc/status-messages.html.twig then it affects the output.

So as I far as I can see this is working and has not changed.

I tried what you suggested, and I am not getting any suggestions. I even went to manually update the Olivero twig template (just adding text of 'Hello World'), clearing caches, and still nothing.

This was done with a new minimal install, no custom modules.

I tried with

1. Drupal 10.3.0 composer installation
2. Standard profile installation
3. Tried with Olivero and Claro both the themes

Can't see the file status-messages.html.twig in TWIG debug output.

Tried to add some HTML etc. and clearing cache nothing worked.

Getting the same issue.

status-messages.html.twig is not being suggested.

I'm getting the same as #10

I'm using a subtheme which of a conrib theme. After updating to 10.3 the styling disappeared because the template is not being suggested.

I am experiencing the same issue after updating to Drupal 10.3

status-messages.html.twig is not being suggested.

I'm using a custom theme that I made.

Same here. I'm using a custom theme that has Classy as the base theme.

I'm having this issue with a subtheme of Radix.

Could this https://www.drupal.org/project/drupal/issues/3270083 be related I tried to make the changes as per but still not getting applied, however, If I dump <?PHP $templates = drupal_find_theme_templates($existing, '.html.twig', $path); ?> when the status message is displayed it returns the template name in the array.

array:109 [▼
  "textarea" => array:2 [▶]
  "checkboxes" => array:2 [▶]
  "field_multiple_value_form" => array:2 [▶]
  "input" => array:2 [▶]
  "radios" => array:2 [▶]
  "toolbar" => array:2 [▶]
  "menu__toolbar" => array:4 [▶]
  "menu_local_task" => array:2 [▶]
  "views_view_table" => array:2 [▶]
  "views_ui_expose_filter_form" => array:2 [▶]
  "views_mini_pager" => array:2 [▶]
  "views_ui_display_tab_setting" => array:2 [▶]
  "views_ui_display_tab_bucket" => array:2 [▶]
  "views_ui_build_group_filter_form" => array:2 [▶]
  "admin_page" => array:2 [▶]
  "admin_block_content" => array:2 [▶]
  "system_modules_details" => array:2 [▶]
  "tablesort_indicator" => array:2 [▶]
  "indentation" => array:2 [▶]
  "search_result" => array:2 [▶]
  "node" => array:2 [▶]
  "mark" => array:2 [▶]
  "page_title" => array:2 [▶]
  "comment" => array:2 [▶]
  "taxonomy_term" => array:2 [▶]
  "username" => array:2 [▶]
  "user" => array:2 [▶]
  "menu" => array:2 [▶]
  "block__system_branding_block" => array:4 [▶]
  "block" => array:2 [▶]
  "block__system_menu_block" => array:4 [▶]
  "views_view_row_rss" => array:2 [▶]
  "views_view_summary_unformatted" => array:2 [▶]
  "views_view_summary" => array:2 [▶]
  "views_view_grouping" => array:2 [▶]
  "views_view" => array:2 [▶]
  "filter_caption" => array:2 [▶]
  "image" => array:2 [▶]
  "field__node__title" => array:4 [▶]
  "link_formatter_link_separate" => array:2 [▶]
  "field__node__uid" => array:4 [▶]
  "file_video" => array:2 [▶]
  "field__comment" => array:4 [▶]
  "field" => array:2 [▶]
  "file_audio" => array:2 [▶]
  "time" => array:2 [▶]
  "field__node__created" => array:4 [▶]
  "help_section" => array:2 [▶]
  "progress_bar" => array:2 [▶]
  "item_list" => array:2 [▶]
  "table" => array:2 [▶]
  "region" => array:2 [▶]
  "html" => array:2 [▶]
  "image_widget" => array:2 [▶]
  "file_widget_multiple" => array:2 [▶]
  "file_managed_file" => array:2 [▶]
  "filter_tips" => array:2 [▶]
  "filter_guidelines" => array:2 [▶]
  "file_link" => array:2 [▶]
  "status_messages" => array:2 [▼
    "template" => "status-messages"
    "path" => "core/themes/claro/templates/misc"
  ]
  "status_report_general_info" => array:2 [▶]
  "off_canvas_page_wrapper" => array:2 [▶]
  "maintenance_page" => array:2 [▶]
  "datetime_wrapper" => array:2 [▶]
  "form_element_label" => array:2 [▶]
  "block_content_add_list" => array:2 [▶]
  "breadcrumb" => array:2 [▶]
  "status_report_counter" => array:2 [▶]
  "form_element" => array:2 [▶]
  "entity_add_list" => array:2 [▶]
  "menu_local_tasks" => array:2 [▶]
  "install_page" => array:2 [▶]
  "fieldset" => array:2 [▶]
  "datetime_form" => array:2 [▶]
  "status_report_page" => array:2 [▶]
  "node_edit_form" => array:2 [▶]
  "system_themes_page" => array:2 [▶]
  "status_report_grouped" => array:2 [▶]
  "pager" => array:2 [▶]
  "views_exposed_form" => array:2 [▶]
  "node_add_list" => array:2 [▶]
  "details" => array:2 [▶]
  "page" => array:2 [▶]
  "text_format_wrapper" => array:2 [▶]
  "menu_link_form" => array:2 [▶]
  "block__local_tasks_block" => array:4 [▶]
  "block__search_form_block" => array:4 [▶]
  "block__local_actions_block" => array:4 [▶]
  "region__breadcrumb" => array:4 [▶]
  "links__node" => array:4 [▶]
  "links__media_library_menu" => array:4 [▶]
  "item_list__media_library_add_form_media_list" => array:4 [▶]
  "item_list__search_results" => array:4 [▶]
  "maintenance_page__front" => array:4 [▶]
  "menu_local_task__views_ui" => array:4 [▶]
  "fieldset__media_library_widget" => array:4 [▶]
  "details__vertical_tabs" => array:4 [▶]
  "details__media_library_add_form_selected_media" => array:4 [▶]
  "container__text_format_filter_help" => array:4 [▶]
  "container__text_format_filter_wrapper" => array:4 [▶]
  "container__text_format_filter_guidelines" => array:4 [▶]
  "container__media_library_widget_selection" => array:4 [▶]
  "container__media_library_content" => array:4 [▶]
  "field__text" => array:4 [▶]
  "field__text_long" => array:4 [▶]
  "field__text_with_summary" => array:4 [▶]
  "views_ui_view_preview_section__exposed" => array:4 [▶]
  "views_view__media_library" => array:4 [▶]
  "views_view_unformatted__media_library" => array:4 [▶]
]

Applying the patch from that thread didn't solve the issue which appears to about sorting them.

I do have an error in my twig about invalid naming.

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'region' -->
<!-- FILE NAME SUGGESTIONS:
   ✅ region--nowrap.html.twig
   ▪️ region--pre-content.html.twig
   ▪️ region.html.twig
-->
<!-- BEGIN OUTPUT from 'themes/contrib/bootstrap_barrio/templates/layout/region--nowrap.html.twig' -->
  

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'block' -->
<!-- FILE NAME SUGGESTIONS:
   ▪️ block--system-messages-block--pre-content.html.twig
   ▪️ block--system--pre-content.html.twig
   ▪️ block--pre-content--partshub-messages.html.twig
   ▪️ block--pre-content.html.twig
   ▪️ block--partshub-messages.html.twig
   ✅ block--system-messages-block.html.twig
   ▪️ block--system.html.twig
   ▪️ block.html.twig
-->
<!-- INVALID FILE NAME SUGGESTIONS:
   See https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Render!theme.api.php/function/hook_theme_suggestions_alter
   
-->
<!-- BEGIN OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->

use Drupal\Core\Render\Element\StatusMessages;

function yourtheme_preprocess_block__system_messages_block(&$variables)
{
  $variables['content'] = StatusMessages::renderMessages();
}

My current fix is like this, but this will only fix from using core into radix, it didn't go through my custom template.

My Gin admin theme seems to work fine.

If I remove the status message block from the frontend theme then messages still display but in the content region (still un styled) is this normal behaviour?

If I start from 10.3.x and do:

composer require drush/drush
vendor/bin/drush si -y -v standard
vendor/bin/drush en system_test -y
vendor/bin/drush ev "\Drupal::state()->set('system_test.front_page_output', 1);"

Here's the HTML I get for the status message that appears.

<div class="region region--highlighted grid-full layout--pass--content-medium">
    <!-- START RENDERER -->
<!-- CACHE-HIT: No -->
<!-- CACHE TAGS:
   * block_view
   * config:block.block.olivero_messages
-->
<!-- CACHE CONTEXTS:
   * languages:language_interface
   * theme
   * user.permissions
-->
<!-- CACHE KEYS:
   * entity_view
   * block
   * olivero_messages
-->
<!-- CACHE MAX-AGE: -1 -->
<!-- PRE-BUBBLING CACHE TAGS:
   * block_view
   * config:block.block.olivero_messages
-->
<!-- PRE-BUBBLING CACHE CONTEXTS:
   * languages:language_interface
   * theme
   * user.permissions
-->
<!-- PRE-BUBBLING CACHE KEYS:
   * entity_view
   * block
   * olivero_messages
-->
<!-- PRE-BUBBLING CACHE MAX-AGE: -1 -->
<!-- RENDERING TIME: 0.000603199 -->


<!-- THEME DEBUG -->
<!-- THEME HOOK: 'block' -->
<!-- FILE NAME SUGGESTIONS:
   ▪️ block--highlighted--id--olivero-messages.html.twig
   ▪️ block--highlighted--plugin-id--system-messages-block.html.twig
   ▪️ block--highlighted.html.twig
   ▪️ block--olivero-messages.html.twig
   ✅ block--system-messages-block.html.twig
   ▪️ block--system.html.twig
   ▪️ block.html.twig
-->
<!-- BEGIN OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->
<div data-drupal-messages-fallback="" class="hidden messages-list"></div>

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'status_messages' -->
<!-- 💡 BEGIN CUSTOM TEMPLATE OUTPUT from 'core/themes/olivero/templates/misc/status-messages.html.twig' -->


<div data-drupal-messages="" class="messages-list">
  <div class="messages__wrapper layout-container">
          
      <div class="messages-list__item messages messages--status" data-drupal-selector="messages" role="contentinfo" aria-label="Status message" data-once="messages">
        <div class="messages__container" data-drupal-selector="messages-container">
                      <div class="messages__header">
            <h2 class="visually-hidden">Status message</h2>
              <div class="messages__icon">
                                  <svg xmlns="http://www.w3.org/2000/svg" width="32px" height="32px" viewBox="0 0 32 32">
  <path d="M26.8,12.6c0,0.4-0.1,0.7-0.4,0.9L15.1,24.9c-0.2,0.2-0.6,0.4-1,0.4c-0.3,0-0.7-0.1-0.9-0.4l-7.5-7.5c-0.2-0.2-0.4-0.6-0.4-0.9c0-0.4,0.1-0.7,0.4-1l1.9-1.9c0.2-0.2,0.6-0.4,0.9-0.4c0.4,0,0.7,0.1,0.9,0.4l4.7,4.7l8.5-8.5c0.2-0.2,0.6-0.4,0.9-0.4c0.4,0,0.7,0.1,0.9,0.4l1.9,1.9C26.6,11.9,26.8,12.3,26.8,12.6z M32,16c0-8.8-7.2-16-16-16C7.2,0,0,7.2,0,16c0,8.8,7.2,16,16,16C24.8,32,32,24.8,32,16z"></path>
</svg>
                              </div>
            </div>
                    <div class="messages__content">
                          On front page.
                      </div>
        <div class="messages__button"><button type="button" class="messages__close"><span class="visually-hidden">Close message</span></button></div></div>
      </div>
                  </div>
</div>

TEST
TEST
TEST!

<!-- END CUSTOM TEMPLATE OUTPUT from 'core/themes/olivero/templates/misc/status-messages.html.twig' -->



<!-- END OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->


<!-- END RENDERER -->
  </div>

I set a breakpoint in \Drupal\Core\Render\Renderer::doRender(). When the SystemMessagesBlock is being rendered, StatusMessages::renderMessages() is never called. Here is the block's $elements array:

Array
(
    [#theme] => block
    [#attributes] => Array()
    [#contextual_links] => Array
        (
            [block] => Array
                (
                    [route_parameters] => Array
                        (
                            [block] => my_custom_theme_messages
                        )
                )
        )
    [#weight] => -4
    [#configuration] => Array
        (
            [id] => system_messages_block
            [label] => Status messages
            [label_display] => 0
            [provider] => system
        )
    [#plugin_id] => system_messages_block
    [#base_plugin_id] => system_messages_block
    [#derivative_plugin_id] => 
    [#id] => my_custom_theme_messages
    [#pre_render] => Array
        (
            [0] => Drupal\block\BlockViewBuilder::preRender
        )
    [#cache] => Array
        (
            [contexts] => Array
                (
                    [0] => languages:language_interface
                    [1] => theme
                    [2] => user.permissions
                )
            [tags] => Array
                (
                    [0] => block_view
                    [1] => config:block.block.my_custom_theme_messages
                )
            [max-age] => -1
            [keys] => Array
                (
                    [0] => entity_view
                    [1] => block
                    [2] => my_custom_theme_messages
                )
        )
    [#attached] => Array()
    [#lazy_builder_built] => 1
    [content] => Array
        (
            [#type] => status_messages
            [#include_fallback] => 1
        )
    [#children] => 
)

Note that it has

    [content] => Array
        (
            [#type] => status_messages
            [#include_fallback] => 1
        )

The theme is [#theme] => block, so the theme suggestions are only suggestions for theming a block, not for theming status messages. Still, this shouldn't be causing the issue. The block has the same content in 10.2.

If I set a breakpoint in 10.2, StatusMessages::renderMessages() is called. So the render placeholder element's callback is not being properly called in 10.3 somehow?

@solideogloria Could you perform a git bisect on a Git checkout of Drupal Core to definitively identify the commit that changed behavior?

RE: https://www.drupal.org/project/drupal/issues/3456176#comment-15654990

@alexpott Could you please include more complete steps? I am not able to enable the system_test module...

Unable to install modules system_test due to missing modules system_test.

@cilefen Bisected. First time using that; it's really nice!

2172d1009cec0e8f908a51fb2c99a1eb06b8b6da is the first bad commit
commit 2172d1009cec0e8f908a51fb2c99a1eb06b8b6da
Author: Alex Pott <alex.a.pott@googlemail.com>
Date:   Thu Feb 22 08:52:28 2024 +0000

    Issue #3379885 by catch, Wim Leers: Use MessagesCommand in BigPipe to remove special casing of the messages placeholder
    
    (cherry picked from commit 44c345dd9b8e2e1fb7131868a5d8b27c57e5b8e3)

 core/modules/big_pipe/big_pipe.services.yml        |  2 +-
 core/modules/big_pipe/src/Render/BigPipe.php       | 79 +++++-----------------
 .../big_pipe/tests/src/Functional/BigPipeTest.php  |  8 +--
 .../FunctionalJavascript/BigPipeRegressionTest.php |  9 ++-
 .../tests/src/Unit/Render/FiberPlaceholderTest.php |  4 +-
 .../tests/src/Unit/Render/ManyPlaceholderTest.php  |  4 +-
 6 files changed, 32 insertions(+), 74 deletions(-)

Issue: #3379885: Use MessagesCommand in BigPipe to remove special casing of the messages placeholder

First bad commit: 2172d1009cec0e8f908a51fb2c99a1eb06b8b6da

Bad commit at the relevant file: core/modules/big_pipe/src/Render/BigPipe.php

Adding the git bisection details to the issue summary.

Hi!

Experiencing the same error here with a theme based on Radix5.

This is the output I get on the theme:

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'region' -->
<!-- FILE NAME SUGGESTIONS:
   ▪️ region--notifications.html.twig
   ✅ region.html.twig
-->
<!-- BEGIN OUTPUT from 'themes/contrib/radix/templates/region/region.html.twig' -->
  <!-- START RENDERER -->
<!-- CACHE-HIT: No -->
<!-- CACHE TAGS:
   * block_view
   * config:block.block.egm_theme_messages
-->
<!-- CACHE CONTEXTS:
   * url.site
   * languages:language_interface
   * theme
   * user.permissions
-->
<!-- CACHE KEYS:
   * entity_view
   * block
   * egm_theme_messages
-->
<!-- CACHE MAX-AGE: -1 -->
<!-- PRE-BUBBLING CACHE TAGS:
   * block_view
   * config:block.block.egm_theme_messages
-->
<!-- PRE-BUBBLING CACHE CONTEXTS:
   * url.site
   * languages:language_interface
   * theme
   * user.permissions
-->
<!-- PRE-BUBBLING CACHE KEYS:
   * entity_view
   * block
   * egm_theme_messages
-->
<!-- PRE-BUBBLING CACHE MAX-AGE: -1 -->
<!-- RENDERING TIME: 0.003482819 -->

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'block' -->
<!-- FILE NAME SUGGESTIONS:
   ▪️ block--egm-theme-messages.html.twig
   ✅ block--system-messages-block.html.twig
   ▪️ block--system.html.twig
   ▪️ block.html.twig
-->
<!-- BEGIN OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->
<div class="" data-drupal-messages=""><div class="messages__wrapper"><div class="messages messages--status" role="status" data-drupal-message-id="status-516592592779658" data-drupal-message-type="status" aria-label="Status message">All caches cleared.</div></div></div>

<!-- END OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->
<!-- END RENDERER -->
<!-- END OUTPUT from 'themes/contrib/radix/templates/region/region.html.twig' -->

Now, if i use the code of #17 in my theme:

use Drupal\Core\Render\Element\StatusMessages;

function mytheme_preprocess_block__system_messages_block(&$variables)
{
  $variables['content'] = StatusMessages::renderMessages();
}

, the output changes to:

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'region' -->
<!-- FILE NAME SUGGESTIONS:
   ▪️ region--notifications.html.twig
   ✅ region.html.twig
-->
<!-- BEGIN OUTPUT from 'themes/contrib/radix/templates/region/region.html.twig' -->
  <!-- START RENDERER -->
<!-- CACHE-HIT: No -->
<!-- CACHE TAGS:
   * block_view
   * config:block.block.egm_theme_messages
-->
<!-- CACHE CONTEXTS:
   * url.site
   * languages:language_interface
   * theme
   * user.permissions
-->
<!-- CACHE KEYS:
   * entity_view
   * block
   * egm_theme_messages
-->
<!-- CACHE MAX-AGE: -1 -->
<!-- PRE-BUBBLING CACHE TAGS:
   * block_view
   * config:block.block.egm_theme_messages
-->
<!-- PRE-BUBBLING CACHE CONTEXTS:
   * url.site
   * languages:language_interface
   * theme
   * user.permissions
-->
<!-- PRE-BUBBLING CACHE KEYS:
   * entity_view
   * block
   * egm_theme_messages
-->
<!-- PRE-BUBBLING CACHE MAX-AGE: -1 -->
<!-- RENDERING TIME: 0.008680820 -->
<!-- THEME DEBUG -->
<!-- THEME HOOK: 'block' -->
<!-- FILE NAME SUGGESTIONS:
   ▪️ block--egm-theme-messages.html.twig
   ✅ block--system-messages-block.html.twig
   ▪️ block--system.html.twig
   ▪️ block.html.twig
-->
<!-- BEGIN OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->
<!-- THEME DEBUG -->
<!-- THEME HOOK: 'status_messages' -->
<!-- BEGIN OUTPUT from 'themes/contrib/radix/templates/misc/status-messages.html.twig' -->

<div role="region" aria-label="Status message">
   <div class="alert alert-success alert-dismissible" role="alert">
      All caches cleared.
      <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
  </div>
</div>

<!-- END OUTPUT from 'themes/contrib/radix/templates/misc/status-messages.html.twig' -->
<!-- END OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->
<!-- END RENDERER -->
<!-- END OUTPUT from 'themes/contrib/radix/templates/region/region.html.twig' -->

and the message is rendered as it used to be

A workaround might also be to disable BigPipe, since the issue arises there.

If in the class @solideogloria is mentioning (core/modules/big_pipe/src/Render/BigPipe.php), i comment (i know i should not, #17 works for me, i am not an expert of core but i have just tried):

          // Delete all messages that were generated during the rendering of this
          // placeholder, to render them in a BigPipe-optimized way.
          // $messages = $this->messenger->deleteAll();
          // foreach ($messages as $type => $type_messages) {
          //   foreach ($type_messages as $message) {
          //     $ajax_response->addCommand(new MessageCommand($message, NULL, ['type' => $type], FALSE));
          //   }
          // }

(but as mentioned, try first #17 as a workaround as i have written in #29 it works for me)

the output is good and hey, it takes even less time (0.00482 segs vs 0.00868 segs):

...
<!-- RENDERING TIME: 0.004825830 -->
<!-- THEME DEBUG -->
<!-- THEME HOOK: 'block' -->
<!-- FILE NAME SUGGESTIONS:
   ▪️ block--egm-theme-messages.html.twig
   ✅ block--system-messages-block.html.twig
   ▪️ block--system.html.twig
   ▪️ block.html.twig
-->
<!-- BEGIN OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->
<div data-drupal-messages-fallback="" class="hidden"></div>

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'status_messages' -->
<!-- BEGIN OUTPUT from 'themes/contrib/radix/templates/misc/status-messages.html.twig' -->

<div role="region" aria-label="Status message">
  <div class="alert alert-success alert-dismissible" role="alert">
      All caches cleared.
      <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
  </div>
</div>

<!-- END OUTPUT from 'themes/contrib/radix/templates/misc/status-messages.html.twig' -->
<!-- END OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->
<!-- END RENDERER -->

I've the same issue with Bootstrap Barrio subtheme, but only with the status messages green. With alert messages I see the right output in red.

If I try to do the "solution" of #31 the issue is solved, but I know it is only a bad way.

Removing the following code makes it work normally I assume when it deletes the messages it stops using templates/misc/status-messages.html.twig' file

          // Delete all messages that were generated during the rendering of this
          // placeholder, to render them in a BigPipe-optimized way.
          $messages = $this->messenger->deleteAll();
          foreach ($messages as $type => $type_messages) {
            foreach ($type_messages as $message) {
              $ajax_response->addCommand(new MessageCommand($message, NULL, ['type' => $type], FALSE));
            }
          }

MessageCommand utilizes message.js for constructing the message (message_list) which restricts customization via template files when bigpipe is exploited for message rendering.

Possibly having a placeholder solely for the message string, instead of the rendering message, could make template customization possible.

Ah, I forgot to mention that, it seems claro/gin themes are not affected (i believe big_pipe also works in admin mode but i am not sure about that)

claro/gin use different hooks and libraries for handle messages (hook_preprocess_status_messages and hook_element_info_alter), so that might be it fails on certain hooks??

Pretty sure this is a pre-existing issue in Drupal core's AJAX messages command which has been exposed by the big pipe change. I've opened #3457518: The AJAX messages command should render messages using the twig template to fix it properly. Postponing this issue on that one. If there turns out to be something else going on here, we can unpostpone.

#34 Not really, Gin uses its own message.js to render AJAX messages; that's why it didn't change. However, if we debug the Twig file, we will see that it doesn't use templates/misc/status-messages.html.twig when BigPipe is enabled (AJAX message).

Uninstalling Big Pipe fixed the issue for me so this is a temporary workaround.

I confirm.
Works when I uninstalled the Big Pipe module.
Should this be fixed from Big Pipe, or in custom components?

@Rajab Natshah see #3457518: The AJAX messages command should render messages using the twig template which I opened just a couple of comments above.

Noted;
Thanks, catch, I had a look at it.
Exploring our options for a better general fix for this.
Our best option could be a general fix by fixing Big Pip or the message in system ( not to do this fix in 20, 100+ projects ).

Tested with Olivero + Big Pipe ( it's working )

Looking at the code of Trusted Callback in Olivero to check for

/**
 * Implements hook_element_info_alter().
 */
function olivero_element_info_alter(&$info) {
  if (array_key_exists('text_format', $info)) {
    $info['text_format']['#pre_render'][] = [OliveroPreRender::class, 'textFormat'];
  }

  if (isset($info['status_messages'])) {
    $info['status_messages']['#pre_render'][] = [OliveroPreRender::class, 'messagePlaceholder'];
  }
}

And class OliveroPreRender implements TrustedCallbackInterface {

Maybe it was fixed in Olivero in some way.
I noticed that many things needs a Trusted Callback in Drupal ~10.3.0 and Drupal ~11

Moving the conversation to #3457518: The AJAX messages command should render messages using the twig template

... I'm not sure that's the whole of the issue. I override/redefine Drupal.theme.message in my custom theme so that the rendered HTML for Ajax matches my theme's template file. However, it's not getting called by these Ajax messages.

If I copy BigPipe.php's changes to 10.2.7 so that the messages template isn't used and they are sent with Ajax, my custom Drupal.theme.message is called in Drupal 10.2.7 for other Ajax messages, but not for these Ajax messages sent by BigPipe. Same in 10.3.x.

If you test with a controller (along with the rest of the controller, and a button or something that uses it):

  public function test(Request $request): AjaxResponse {
    $response = new AjaxResponse();
    $response->addCommand(new MessageCommand('Test.', NULL, ['type' => 'error']));
    $response->addCommand(new MessageCommand('Test 2.', NULL, ['type' => 'status']));
    return $response;
  }

And override Drupal.theme.message:

  Drupal.theme.message = ({ text }, { type, id }) => {
    console.log('Custom theme Ajax message!');

    const messagesTypes = Drupal.Message.getMessageTypeLabels();
    const messageWrapper = document.createElement('div');

    messageWrapper.setAttribute('class', `messages messages--${type}`);
    messageWrapper.setAttribute(
      'role',
      type === 'error' || type === 'warning' ? 'alert' : 'status',
    );
    messageWrapper.setAttribute('data-drupal-message-id', id);
    messageWrapper.setAttribute('data-drupal-message-type', type);

    messageWrapper.setAttribute('aria-label', messagesTypes[type]);

    messageWrapper.innerHTML = `${text}`;

    return messageWrapper;
  }

The override is called for the controller's Ajax response, but not for BigPipe's Ajax response.

As another note, only the last Ajax MessageCommand is rendered. I think it recreates/replaces the messages wrapper, removing all prior messages.

I'm positing this here in case anyone just wants the status messages to be color-coded and minimally themed.

The quick fix (and one I can live with) is to copy the content of web/core/themes/starter_kit/css/components/messages.css into your custom theme. I also had to uncheck the "Aggregate CSS files" and "Aggregate JavaScript files" at admin/config/development/performance, save, clear caches, then recheck the boxes and save again before the changes took effect.

+1 subscribe

For those who are looking to do a temporary "fix" by bypassing the code in the updated BigPipe.php file (as mentioned in #17 and #31), I've created a patch that comments out that piece of code. Testing this, Big Pipe still works and the theme hook for status-messages comes back, and this should only be used as a temp. fix / workaround until it can be fixed correctly.

This patch will help you upgrade to 10.3.

#45 works for me on Drupal 10.3. Thanks.

#45 works for me. I have been checking this issue for the whole 1 day. Thanks

#45 worked as a workaround for my subtheme of radix v5. In my case, the messages receive no special CSS styling, making them almost unnoticeable. Saying the markup and theming "differs from theme default" is putting it mildly. Bumping to Major since it meets the criterion, "Interfere with normal site visitors' use of the site".

#45 workaround works for me, too.

I have done a bit more testing in some of the sites i have:

Workaround on #17 works for the sub-themes made with bootstrap@3, radix@v4 & radix@v5.
Radix@v6 works fine without #17 (actually, with #17 it causes duplicated messages)
With #17 in the sites i have tested it, workaround #45 has not been necessary, but i think also #45 is less theme-dependant and prompt to errors in some cases.

My previous test is wrong, so i will do #45 and radix6, as it seems i have some issues there with #17

The patch in #45 did the trick and I could reinstall BigPipe. Thank you for the workaround!

The patch in #45 also works for me.

I'm postponing this on #3457518: The AJAX messages command should render messages using the twig template again - that will resolve the issue that people are experiencing here. Fine to continue discussing workarounds here, but to actually fix it, we need to change how AJAX messages get rendered.

The actual issue is #3396318: AJAX MessageCommand markup and styling differs from Theme default, since the other was closed as a duplicate.

#45 NOT works for me on Drupal 10.3. Thanks.

I want to add:

1. I have uninstalled the BigPipe module and the notifications do not work either.

2. But the notifications of my personal code of the modules I create do not work. Yes, system notifications work, they all work.

3. A curious thing is that when I add to my code example "\drupal::messenger()->addStatus('Hello world');" of notifications a syntax error, the notification does appear and the error is also written to the log. I understand that it sounds strange but detect it.

4. All Drupal modules that customize notifications stopped working with drupal 10.3. I have reviewed everything and an issue is open in all of them.

Thank you I wait for the solution.

Hello.

I inform you that works without any patch.

I am using olivero and gin drupal themes, core notifications works well. But:

For my custom code to work, type:

\Drupal::messenger()->addStatus(t('Dear %user, Welcome to our %site',['%user' => 'admin', '%site' => 'Drupal Learn']));

\Drupal::messenger()->addStatus(Markup::create('Duplicate Markup / string.'), TRUE);

exit(); <---

I have added only the exit() function, stop script.

I know it is not a correct solution, but in my functionality it works well for me.

I don't know why when adding exit(), after the notification functions works well.

Without exit(), custom notifications do not work. None, but with exit() at the end of the notifications function work.

I hope it is resolved correctly.

Gracias

@ady1503 You must be doing something wrong in your modules. You definitely shouldn't be adding exit() after those calls, as it will prevent any other code from running.

Consider opening a separate issue, as your problem is likely something else.

@solideogloria

Yes you're right.

But for me it works perfectly.

Because my notifications are to control access and number of content added. And stopping the script is not a problem.

I do redirect and then project the notification to inform the user that they do not have permission or have exceeded the number of allowed content.

I wanted to inform, if this is a reason for finding the drupal core problem, when it is solved I will return to the normal code.

Thank you.

#45 work for me too.

#45 worked, Thanks.

The proper fix for sites experiencing this is:

1. If you have a custom theme, then implement Drupal.theme.message in your theme, there are examples of how to do this in both Claro and Olivero themes in core. Umami does not do this but #3100083: Add js message theme override to match Umami message markup is the issue to add that, and will show the kind of changes necessary.

2. If you're using a contributed theme, open an issue against that theme's issue queue to add JavaScript messages support.

I've updated the issue summary with instructions. If we do #3396318: AJAX MessageCommand markup and styling differs from Theme default, that will mitigate this for themes that don't style JavaScript messages (because the messages would be rendered in PHP), but there could still be edge cases where sites see unthemed messages.

@catch I already implement Drupal.theme.message, and that doesn't fix the issue, because the function isn't being called for the BigPipe messages, but the function was called and worked for messages created with Ajax in other places of my site prior to 10.3. Only commenting out that BigPipe code with #45 fixes it.

I make refactoring of mi code to

  \Drupal::messenger()->addStatus(t('Dear %user, Welcome to our %site',['%user' => 'admin', '%site' => 'Drupal Learn']));
  // Prepare the goto Url.
  $url = Url::fromRoute('<front>');
  $response = new RedirectResponse($url->toString());
  $request = \Drupal::request();
  // Save the session so things like messages get saved.
  $request->getSession()->save();
  $response->prepare($request);
  // Make sure to trigger kernel events.
  \Drupal::service('kernel')->terminate($request, $response);
  $response->send();

and mi notifications works without patch 45, with theme gin and olivero.

source: https://blog.birk-jensen.dk/drupal-http-redirection-from-anywhere
https://www.drupal.org/node/2023537

@ady1503, as far as i tested, those themes are not affected by this issue, at least not to me. Olivero implements its own drupal.messages override (if i am not wrong)

Bootstrap, radix.. those yes (at least to me)

Best solution is to add to your theme preprocess andikanio #17

#17 works for me fine on Drupal 10.3.1.
Thanks.

+1 #17.

After half a day of investigation I ended up here as well.

hook_theme_suggestions_HOOK_alter and hook_preprocess_HOOK work as expected after this is called

Ok now I am also seeing message added twice after page reload. Message is appended with ajax message

e.g.

<div class="messages messages--status" role="status" data-drupal-message-id="status-812605616874536" data-drupal-message-type="status" aria-label="Status message">Antibot (views_exposed_form): disabled</div>

This looks like it is added in ajax.js e.g.

    message(ajax, response) {
      const messages = new Drupal.Message(
        document.querySelector(response.messageWrapperQuerySelector),
      );
      if (response.clearPrevious) {
        messages.clear();
      }
      messages.add(response.message, response.messageOptions);
    },

If you clear cache, the message only appears once on page load, then it will appear twice.

Disabling Big Pipe stops the message being added twice. Actually disabling bigpipe seems to fix the problem.

Even with big pipe being disabled, message is displayed multiple times when pages loads via ajax (olivero). Actually this could be problem with the notification. Will investigate that first.

Message/Notification seems to persist. i.e. is shown again even if the message/notification is manually closed.

#45 workaround works for me, too.

Creating a custom preprocess hook for system_messages_block as shown in #17 worked for me, but I ran into caching problems with the messages block. The message output would get cached and it would display the cached message every time.

I had to set the cache max-age to 0 for this to actually be usable. Did anyone else encounter this too?

I ended up needing to do this:

use Drupal\Core\Render\Element\StatusMessages;

function yourtheme_preprocess_block__system_messages_block(&$variables) {
  $variables['content'] = StatusMessages::renderMessages();
  $variables['#cache']['max-age'] = 0;
}

The best solution for me was to use solution #17, adding a preprocess in my custom theme and adding the following code along with that solution: $variables['#cache']['max-age'] = 0;

OK, so I wasn't the only one. That's exactly what I did as well. I guess the workaround in #17 wasn't complete. If anyone is having issues with messages getting cached and frozen, you'll need to use the code in #72 until there's a proper fix for this.

FWIW, the patch in #45 worked in the sense that my system messages came back, but I also had the issue with the cached messages using that as well so I rolled back that patch and am only going with the preprocess function as the workaround.

+1 for the workaround in #72.

On my dev site that had these in the settings:

$settings['cache']['bins']['render'] = 'cache.backend.null';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';

Everything seemed fine with just #17. When it went through to the staging site, I saw the "All caches cleared" message on every page. So I added the line in #72 which seems to work so far on local even when I commented out those lines in the settings file, but I'll update this if it turns out to not fix it on the real staging.

Ryan, setting your cache bins to null in your settings disables page caching, which is basically like setting cache.max-age = 0 to everything on the site. That's handy for the dev site, but you won't want that on your production site. If that was what you had resorted to, you don't want to do that as your workaround.

Yup great job on the caching tweak. I feel like this could be added to the sub theme as a tiny default tweak?

@hyperlinked

Sorry, poor wording on my part. I meant that I had those cache bins as null on local/dev, not on staging or production.

Your explanation makes sense for why I was seeing the constant alert on staging (still has the default cache bin) but not on local/dev (null cache bin site-wide).

I have now followed the lead of #72, which if I'm understanding correctly means no caching of alert messages, but maintains the caching everywhere else.

Here is how we did it and how it can be done with the new way described by catch #63.
https://www.drupal.org/project/uswds_base/issues/3465493
My example is for a USWDS theme but you can replace those classes with those you had on status-messages.html.twig

@bernardm28's approach is the correct one here.

This isn't actually a new way to theme status messages, it's been in core since 2019 and Drupal 8.8 https://www.drupal.org/node/3086403. Any status message created via AJAX has used this mechanism since then. The difference in Drupal 10.3 is that BigPipe also started to use the same mechanism, which means it's used a lot more often.

@solideogloria if you definitely have this working for other AJAX status messages but not in big pipe, please open a new issue about that - it ought to be impossible for it to be different, because it's all executed via the same JavaScript API.

@catch would there be any harm in the forseeable future with fixing this via the workaround in #72 for a non-contrib legacy theme?

@catch It appears that messages that I was already adding via Ajax are rendered/themed properly without patching BigPipe. But the messages that are added using $this->messenger()->addMessage() (e.g. in a Block's build() function) are not.

namespace Drupal\theme_helper\Plugin\Block;

use Drupal\Core\Block\BlockBase;

/**
 * A theme test block.
 *
 * @Block(
 *   id = "theme_test",
 *   admin_label = @Translation("Theme Test"),
 *   category = @Translation("Development")
 * )
 */
class ThemeTestBlock extends BlockBase {

  /**
   * {@inheritdoc}
   */
  public function build(): array {
    $this->messenger()->addMessage($this->t('This is an info <a href="#">message</a>.'), 'info');
    $this->messenger()->addMessage($this->t('This is a success <a href="#">message</a>.'));
    $this->messenger()->addStatus($this->t('This is another success <a href="#">message</a>.'));
    $this->messenger()->addWarning($this->t('This is a warning <a href="#">message</a>.'));
    $this->messenger()->addError($this->t('This is an error <a href="#">message</a>.'));
    return [];
  }

}

When I use this block with patching BigPipe, I can see an Info message (a new type of message supported by the Webform module), as well as other standard messages that fit my theme. When I remove the patch, I get an error

Error: The message type, info, is not present in Drupal.Message.getMessageTypeLabels().

(I tried to override getMessageTypeLabels, but couldn't. My overriding function is never called.)

And if I comment out that message line, the messages display but not with my overriden theme function Drupal.theme.message being called in my custom theme, so it doesn't fit my theme's style.

Edit: I noticed that the Drupal variable is being converted when my TypeScript is compiled. I'll need to look into this and see if that's a cause.

Edit 2: Nope. TypeScript's build process shouldn't affect this at all.

@solideogloria can you try this without the info message from webform? This sounds like the webform info message is incompatible with Ajax rendering which would be a webform issue.

When having the messages styled through status-message.html.twig it grouped messages of the same type into a list. Is it still possible to do this via message.js as from reading the code it calls Drupal.theme('message', { text: message }, options), for each message then appends it to the element messages__wrapper. I would like to keep the old format to save my screen from being cluttered with multiple alert elements if there are multiple messages to be displayed.

The postponed issue is in, what are the next steps here? I can't see a proposed solution in the IS and the MR is empty.

@acbramley the only way to make status messages the same for ajax vs. non-ajax responses for all themes would be to do #3396318: AJAX MessageCommand markup and styling differs from Theme default, that would mean rendering the messages in PHP, then adding that HTML via AJAX, instead of adding the message string/type in MessagesCommand and then doing the rendering in js. The mis-match happens when themes don't implement js theming of messages.

I postponed this issue on that one in #35 but that apparently didn't help to focus efforts over there.

@catch that's a shame, I think this is going to bite quite a few people on 10.3 and the new way of implementing it in JS is not obvious at all.

Perhaps we could at least warn people if they've got an overridden status messages twig template that it's not going to do anything and direct them to documentation on how to do it properly

@acbramley it's not actually new, it was added in Drupal 8.8, but agree it's not obvious at all.

Another option would be to revert the big pipe change from 10.3 and 11.0 and try to get the other issue into the next minor.

@catch Ah yeah sorry, new as in having a customised status-messages.html.twig twig template in your theme does not work anymore

I've also just found some very strange behaviour where the new JS themed messages are not being used for anonymous users. Both for webform submissions and even password reset submissions they're unthemed.

We're using the same method as Olivero so I'm not sure what's going on here.

When logged in everything works fine.

Has anyone succeeded in applying the modified #17 patch whilst keeping bigpipe enabled?

Seems on my install at least that the steps are
1.) Disable bigpipe
2.) Add the preprocess hook

use Drupal\Core\Render\Element\StatusMessages;

function yourtheme_preprocess_block__system_messages_block(&$variables) {
  $variables['content'] = StatusMessages::renderMessages();
  $variables['#cache']['max-age'] = 0;
}

These update problems of Drupal are so annoying that I'm at the point where I'm going to quit. There is no documentation on the subject. Why would they make such a change without consulting the community. I am not updating any site because of this issue.

We use this in a custom theme without disabling bigpipe

use Drupal\Core\Render\Element\StatusMessages;

function yourtheme_preprocess_block__system_messages_block(&$variables) {
  $variables['content'] = StatusMessages::renderMessages();
  $variables['#cache']['max-age'] = 0;
}

Resolved issues for us.

@glynster thanks for this information

@glynster Thanks. Working now

Before applying patch my mark up is like this with big pipe enabled (looking good but status message is output multiple times, one on top of the other):

<!-- 💡 BEGIN CUSTOM TEMPLATE OUTPUT from 'themes/custom/sl2/templates/misc/status-messages.html.twig' -->
<svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
  <symbol id="check-circle-fill" viewBox="0 0 16 16">
    <path d="M16 8A8 8 0 1 1 0 8a8 8 0 0 1 16 0zm-3.97-3.03a.75.75 0 0 0-1.08.022L7.477 9.417 5.384 7.323a.75.75 0 0 0-1.06 1.06L6.97 11.03a.75.75 0 0 0 1.079-.02l3.992-4.99a.75.75 0 0 0-.01-1.05z"></path>
  </symbol>
  <symbol id="info-fill" viewBox="0 0 16 16">
    <path d="M8 16A8 8 0 1 0 8 0a8 8 0 0 0 0 16zm.93-9.412-1 4.705c-.07.34.029.533.304.533.194 0 .487-.07.686-.246l-.088.416c-.287.346-.92.598-1.465.598-.703 0-1.002-.422-.808-1.319l.738-3.468c.064-.293.006-.399-.287-.47l-.451-.081.082-.381 2.29-.287zM8 5.5a1 1 0 1 1 0-2 1 1 0 0 1 0 2z"></path>
  </symbol>
  <symbol id="exclamation-triangle-fill" viewBox="0 0 16 16">
    <path d="M8.982 1.566a1.13 1.13 0 0 0-1.96 0L.165 13.233c-.457.778.091 1.767.98 1.767h13.713c.889 0 1.438-.99.98-1.767L8.982 1.566zM8 5c.535 0 .954.462.9.995l-.35 3.507a.552.552 0 0 1-1.1 0L7.1 5.995A.905.905 0 0 1 8 5zm.002 6a1 1 0 1 1 0 2 1 1 0 0 1 0-2z"></path>
  </symbol>
</svg>
<div data-drupal-messages="">
    
  <div aria-label="Status message" class="alert alert-dismissible fade show col-12 d-flex align-items-center alert-success" role="status" data-drupal-selector="messages">
          <svg class="bi flex-shrink-0 me-4" role="img" aria-label="Success:"><use xlink:href="#check-circle-fill"></use></svg>
        <div>
      <h2 id="message-status-title--IRzqPL_UGPQ" class="alert-heading">
        Status message
      </h2>
      <hr>
                        Antibot (views_exposed_form): enabled
                  </div>
    <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
  </div>
</div>
<div aria-label="Status message" class="alert alert-dismissible fade show col-12 d-flex align-items-center alert-success" role="status" data-drupal-selector="messages">
          <svg class="bi flex-shrink-0 me-4" role="img" aria-label="Success:"><use xlink:href="#check-circle-fill"></use></svg>
        <div>
      <h2 id="message-status-title--IRzqPL_UGPQ" class="alert-heading">
        Status message
      </h2>
      <hr>
                        Antibot (views_exposed_form): enabled
                  </div>
    <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
  </div>
<svg class="bi flex-shrink-0 me-4" role="img" aria-label="Success:"><use xlink:href="#check-circle-fill"></use></svg>
<div>
      <h2 id="message-status-title--IRzqPL_UGPQ" class="alert-heading">
        Status message
      </h2>
      <hr>
                        Antibot (views_exposed_form): enabled
                  </div>
<button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
<div aria-label="Status message" class="alert alert-dismissible fade show col-12 d-flex align-items-center alert-success" role="status" data-drupal-selector="messages">
          <svg class="bi flex-shrink-0 me-4" role="img" aria-label="Success:"><use xlink:href="#check-circle-fill"></use></svg>
        <div>
      <h2 id="message-status-title--IRzqPL_UGPQ" class="alert-heading">
        Status message
      </h2>
      <hr>
                        Antibot (views_exposed_form): enabled
                  </div>
    <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
  </div>
<div data-drupal-messages="">
    
  <div aria-label="Status message" class="alert alert-dismissible fade show col-12 d-flex align-items-center alert-success" role="status" data-drupal-selector="messages">
          <svg class="bi flex-shrink-0 me-4" role="img" aria-label="Success:"><use xlink:href="#check-circle-fill"></use></svg>
        <div>
      <h2 id="message-status-title--IRzqPL_UGPQ" class="alert-heading">
        Status message
      </h2>
      <hr>
                        Antibot (views_exposed_form): enabled
                  </div>
    <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
  </div>
</div>
<!-- END CUSTOM TEMPLATE OUTPUT from 'themes/custom/sl2/templates/misc/status-messages.html.twig' -->

After patch message is output once multiple time and markup is like so (not looking good - see attached). This also shows output being output multiple times!

<!-- BEGIN OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->
<div class="" data-drupal-messages="">
  <div class="messages__wrapper">
    <div class="messages messages--status" role="status" data-drupal-message-id="status-893981933143464" data-drupal-message-type="status" aria-label="Status message">Antibot (views_exposed_form): enabled</div>
   </div>
</div>

  <div class="messages__wrapper">
    <div class="messages messages--status" role="status" data-drupal-message-id="status-893981933143464" data-drupal-message-type="status" aria-label="Status message">Antibot (views_exposed_form): enabled</div>
  </div>

  <div class="messages messages--status" role="status" data-drupal-message-id="status-893981933143464" data-drupal-message-type="status" aria-label="Status message">Antibot (views_exposed_form): enabled</div>

  <div class="messages__wrapper">
    <div class="messages messages--status" role="status" data-drupal-message-id="status-893981933143464" data-drupal-message-type="status" aria-label="Status message">Antibot (views_exposed_form): enabled</div>
  </div>

  <div class="" data-drupal-messages="">
    <div class="messages__wrapper">
      <div class="messages messages--status" role="status" data-drupal-message-id="status-893981933143464" data-drupal-message-type="status" aria-label="Status message">Antibot (views_exposed_form): enabled</div>
    </div>
  </div>

</div>
<!-- END OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->

In this example antibot notice is output to status message.

If I disable Bigpipe and remove the patch output is like so. Status message is not still repeated but output still looks good, but the curious thing is when I copy from the browser markup does still appear to be applied twice multiple times!

<!-- END OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->
<!-- BEGIN OUTPUT from 'core/modules/system/templates/block--system-messages-block.html.twig' -->
<div data-drupal-messages-fallback="" class="hidden"></div>
<!-- THEME DEBUG -->
<!-- THEME HOOK: 'status_messages' -->
<!-- 💡 BEGIN CUSTOM TEMPLATE OUTPUT from 'themes/custom/sl2/templates/misc/status-messages.html.twig' -->
<svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
  <symbol id="check-circle-fill" viewBox="0 0 16 16">
    <path d="M16 8A8 8 0 1 1 0 8a8 8 0 0 1 16 0zm-3.97-3.03a.75.75 0 0 0-1.08.022L7.477 9.417 5.384 7.323a.75.75 0 0 0-1.06 1.06L6.97 11.03a.75.75 0 0 0 1.079-.02l3.992-4.99a.75.75 0 0 0-.01-1.05z"></path>
  </symbol>
  <symbol id="info-fill" viewBox="0 0 16 16">
    <path d="M8 16A8 8 0 1 0 8 0a8 8 0 0 0 0 16zm.93-9.412-1 4.705c-.07.34.029.533.304.533.194 0 .487-.07.686-.246l-.088.416c-.287.346-.92.598-1.465.598-.703 0-1.002-.422-.808-1.319l.738-3.468c.064-.293.006-.399-.287-.47l-.451-.081.082-.381 2.29-.287zM8 5.5a1 1 0 1 1 0-2 1 1 0 0 1 0 2z"></path>
  </symbol>
  <symbol id="exclamation-triangle-fill" viewBox="0 0 16 16">
    <path d="M8.982 1.566a1.13 1.13 0 0 0-1.96 0L.165 13.233c-.457.778.091 1.767.98 1.767h13.713c.889 0 1.438-.99.98-1.767L8.982 1.566zM8 5c.535 0 .954.462.9.995l-.35 3.507a.552.552 0 0 1-1.1 0L7.1 5.995A.905.905 0 0 1 8 5zm.002 6a1 1 0 1 1 0 2 1 1 0 0 1 0-2z"></path>
  </symbol>
</svg>
<div data-drupal-messages="">
    
  <div aria-label="Status message" class="alert alert-dismissible fade show col-12 d-flex align-items-center alert-success" role="status" data-drupal-selector="messages">
          <svg class="bi flex-shrink-0 me-4" role="img" aria-label="Success:"><use xlink:href="#check-circle-fill"></use></svg>
        <div>
      <h2 id="message-status-title" class="alert-heading">
        Status message
      </h2>
      <hr>
                        Antibot (views_exposed_form): enabled
                  </div>
    <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
  </div>
</div>
<div aria-label="Status message" class="alert alert-dismissible fade show col-12 d-flex align-items-center alert-success" role="status" data-drupal-selector="messages">
          <svg class="bi flex-shrink-0 me-4" role="img" aria-label="Success:"><use xlink:href="#check-circle-fill"></use></svg>
        <div>
      <h2 id="message-status-title" class="alert-heading">
        Status message
      </h2>
      <hr>
                        Antibot (views_exposed_form): enabled
                  </div>
    <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
  </div>
<div data-drupal-messages="">
    
  <div aria-label="Status message" class="alert alert-dismissible fade show col-12 d-flex align-items-center alert-success" role="status" data-drupal-selector="messages">
          <svg class="bi flex-shrink-0 me-4" role="img" aria-label="Success:"><use xlink:href="#check-circle-fill"></use></svg>
        <div>
      <h2 id="message-status-title" class="alert-heading">
        Status message
      </h2>
      <hr>
                        Antibot (views_exposed_form): enabled
                  </div>
    <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
  </div>
</div>
<!-- END CUSTOM TEMPLATE OUTPUT from 'themes/custom/sl2/templates/misc/status-messages.html.twig' -->

10.2 with Bigpipe disabled (and show form id on antibot settings):

<div class="highlighted">
        <aside class="container section clearfix">
            <div data-drupal-messages-fallback="" class="hidden"></div>
<svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
  <symbol id="check-circle-fill" viewBox="0 0 16 16">
    <path d="M16 8A8 8 0 1 1 0 8a8 8 0 0 1 16 0zm-3.97-3.03a.75.75 0 0 0-1.08.022L7.477 9.417 5.384 7.323a.75.75 0 0 0-1.06 1.06L6.97 11.03a.75.75 0 0 0 1.079-.02l3.992-4.99a.75.75 0 0 0-.01-1.05z"></path>
  </symbol>
  <symbol id="info-fill" viewBox="0 0 16 16">
    <path d="M8 16A8 8 0 1 0 8 0a8 8 0 0 0 0 16zm.93-9.412-1 4.705c-.07.34.029.533.304.533.194 0 .487-.07.686-.246l-.088.416c-.287.346-.92.598-1.465.598-.703 0-1.002-.422-.808-1.319l.738-3.468c.064-.293.006-.399-.287-.47l-.451-.081.082-.381 2.29-.287zM8 5.5a1 1 0 1 1 0-2 1 1 0 0 1 0 2z"></path>
  </symbol>
  <symbol id="exclamation-triangle-fill" viewBox="0 0 16 16">
    <path d="M8.982 1.566a1.13 1.13 0 0 0-1.96 0L.165 13.233c-.457.778.091 1.767.98 1.767h13.713c.889 0 1.438-.99.98-1.767L8.982 1.566zM8 5c.535 0 .954.462.9.995l-.35 3.507a.552.552 0 0 1-1.1 0L7.1 5.995A.905.905 0 0 1 8 5zm.002 6a1 1 0 1 1 0 2 1 1 0 0 1 0-2z"></path>
  </symbol>
</svg>

<div data-drupal-messages="">
    
  <div aria-label="Status message" class="alert alert-dismissible fade show col-12 d-flex align-items-center alert-success" role="status" data-drupal-selector="messages">
          <svg class="bi flex-shrink-0 me-4" role="img" aria-label="Success:"><use xlink:href="#check-circle-fill"></use></svg>
        <div>
      <h2 id="message-status-title" class="alert-heading">
        Status message
      </h2>
      <hr>
                        Antibot (views_exposed_form): disabled
                  </div>
    <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
  </div>
</div>



        </aside>
      </div>

10.2.7 with big pipe enabled:

<div class="highlighted">
        <aside class="container section clearfix">
            <div data-drupal-messages-fallback="" class="hidden"></div>
<svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
  <symbol id="check-circle-fill" viewBox="0 0 16 16">
    <path d="M16 8A8 8 0 1 1 0 8a8 8 0 0 1 16 0zm-3.97-3.03a.75.75 0 0 0-1.08.022L7.477 9.417 5.384 7.323a.75.75 0 0 0-1.06 1.06L6.97 11.03a.75.75 0 0 0 1.079-.02l3.992-4.99a.75.75 0 0 0-.01-1.05z"></path>
  </symbol>
  <symbol id="info-fill" viewBox="0 0 16 16">
    <path d="M8 16A8 8 0 1 0 8 0a8 8 0 0 0 0 16zm.93-9.412-1 4.705c-.07.34.029.533.304.533.194 0 .487-.07.686-.246l-.088.416c-.287.346-.92.598-1.465.598-.703 0-1.002-.422-.808-1.319l.738-3.468c.064-.293.006-.399-.287-.47l-.451-.081.082-.381 2.29-.287zM8 5.5a1 1 0 1 1 0-2 1 1 0 0 1 0 2z"></path>
  </symbol>
  <symbol id="exclamation-triangle-fill" viewBox="0 0 16 16">
    <path d="M8.982 1.566a1.13 1.13 0 0 0-1.96 0L.165 13.233c-.457.778.091 1.767.98 1.767h13.713c.889 0 1.438-.99.98-1.767L8.982 1.566zM8 5c.535 0 .954.462.9.995l-.35 3.507a.552.552 0 0 1-1.1 0L7.1 5.995A.905.905 0 0 1 8 5zm.002 6a1 1 0 1 1 0 2 1 1 0 0 1 0-2z"></path>
  </symbol>
</svg>

<div data-drupal-messages="">
    
  <div aria-label="Status message" class="alert alert-dismissible fade show col-12 d-flex align-items-center alert-success" role="status" data-drupal-selector="messages">
          <svg class="bi flex-shrink-0 me-4" role="img" aria-label="Success:"><use xlink:href="#check-circle-fill"></use></svg>
        <div>
      <h2 id="message-status-title" class="alert-heading">
        Status message
      </h2>
      <hr>
                        Antibot (views_exposed_form): disabled
                  </div>
    <button type="button" class="btn-close" data-bs-dismiss="alert" aria-label="Close"></button>
  </div>
</div>



        </aside>
      </div>

Screenshot with big pipe disabled.

attached picture shows 10.2.7 with and without big pipe enabled works without outputting markup multiple times and is also styled.

Apologies for all the noise but to clarify I think I am conflating a few issues here.

@glynster solution does resolve the theme hook suggestion issue for me after upgrading to 10.3 with Bigpipe enabled.

The other things i noticed when looking into this issue is that the initial notification (on page load is shown in the Status messages block. For me this is out put in my notification region. Subsequent ajax loaded notifications do not appear in the same region. For me they are getting injected in the view (views-view.html.twig) or content area for example. This could be an issue here or with views load more that I am using here. Not sure. Same in 10.2.x My expectation is notifications should be output in the same block or region as specified in your site.

I have added (another) screenshot that shows the output being added twice to message on initial page load notification. After that it only seems to get loaded once. Setting cache max age to 0 using THEME_preprocess_HOOK seems to address that issue.

Re #97 - any chance you could remove that HTML and add it as an attachment instead to reduce the noise? It's quite hard to parse as is anyway

Thanks @acbramley

It is useful to see the output side by side but I will consider uploading markup as attachments in the future as per your recommendation.

The problem I see with this approach (patch) is that there is also an issue with core Oliveiro theme afaict. Please see attached screenshots.

In Oliveiro Initial status message is shown in correct place on page load in this case is also has the following markup:

<div class="messages-list__item messages messages--status" data-drupal-selector="messages" role="status" aria-labelledby="status-590833649505219-title" data-drupal-message-id="status-590833649505219" data-drupal-message-type="status" data-once="messages">

Notice that both aria-labelledby and data-drupal-message-id have the following token attached 590833649505219

The markup for the second message that is injected does not have this token markup also looks a little different:

<div class="messages-list__item messages messages--status" data-drupal-selector="messages" role="contentinfo" aria-label="Status message" data-once="messages">

We can see also role is contentinfo rather that status so I a little confused about that.

In Olivero the message notification keeps on injecting and error is found in the console log. See attached.

So to summarise in Oliveiro:

1. Status message loads in correct place (block and region) only after cache clear on initial page load
2. Subsequent status messages are injected in the content region?
3. Multiple status messages loading continuously
4. Ajax loading spinner does not go away.
5. Error in the console - see below

ResizeObserver loop completed with undelivered notifications.

Tested in Safari, Chrome and Firefox.

Perhaps I should open up another issue(s) for some of these?

Problem with Olivero seems to happen even with Bigpipe disabled.

Tested in Stark and seems to work fine with and without Bigpipe enabled. Message notifications are un-styled in Stark though.

Perhaps the issue in Olivero is a different one as I think the implementation around message notifications is different there. e.g. it has its own messages.js and message-theme.js which also seem to have dependency on navigation-utils.js

I have raised issue for Olivero here:

https://www.drupal.org/project/drupal/issues/3469942#comment-15741587

It's a shame that there appears is no easy way in core to see how message notifications should be implemented.

Turns out even Olivero does seem to need this fix/patch for theme suggestions. Please see related issue for more info.

There is quite a lot happening here with how notifications are styled depending on:

1. the role or status of the alert/message (status, error, warning, info?)
2. if BigPipe is enabled (alerts are grouped together only if Bigpipe enabled?!)
3. If there are single or multiple alerts (depends is container is tagged with contentinfo or status role
4. if views is enabled, they can be output to multiple regions?! (notification sits in main notification region and block on page load while additional notifications are output in the content region)

I actually came across alerts a while ago when looking at theming migrate tools UI and the limitation of the current traffic light system (red, green, amber). If any one is interested there is also figma design there as well.

https://www.drupal.org/project/drupal/issues/3437924

The good news is i seem to be able to apply https://www.drupal.org/project/drupal/issues/3456176#comment-15738200 in versions of Drupal prior to 10.3 without any noticeable side affects. This means I can avoid having to do a major release for any theme to address issue or changes introduced with 10.3 release.

Certainly upgrading to 10.3 without applying these changes can lead to un-styled alerts and message notifications.

I've also just found some very strange behaviour where the new JS themed messages are not being used for anonymous users. Both for webform submissions and even password reset submissions they're unthemed.

We're using the same method as Olivero so I'm not sure what's going on here.

When logged in everything works fine.

@acbramley, If you turn on the Twig debug information, can you see what template is used for the status message?

According to my test with Drupal 11, the message showing to authenticated user is rendered from the core/modules/system/templates/block--system-messages-block.html.twig template.

Meanwhile, the message showing to anonymous users is rendered from the core/themes/olivero/templates/misc/status-messages.html.twig template, which is the front theme on my test site. In your case, it might be from your custom theme.

I think that’s why the results differ between anonymous and authenticated users.

By the way, with Drupal 10.2, the them's status-messages.html.twig template is consistently used regardless the authentication situation.

There's now an MR to consolidate the theming of status messages over on #3396318: AJAX MessageCommand markup and styling differs from Theme default which looks like it still needs some work on test fixes but could use early reviews/testing.

If we're able to do the approach there, the markup between messages that are sent from PHP, AJAX and pure-JavaScript messages should be identical, since it will use the theme's twig template to generate the markup for the JS messages too.

I'm postponing this issue on that one, since if we commit it over there, it should fix everything here. Except for the inconsistency noted in #3456176-106: 10.3 upgrade now missing status-message theme suggestions but that's another issue again.

Sorry for commenting on a postponed issue.

I think the reason why the message rendered looks different between anonymous user and authenticated user is that in a page rendered for an authenticated user, there is another big-pipe placeholder callback for the toolbar was called prior to the call of Drupal\Core\Render\Element\StatusMessages::renderMessages(). That causes all messages were deleted in line 529 before the messages were rendered.

https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/big_p...

Since the anonymous user won't have toolbar, the big-pipe placeholder for the message is the only one in that page, so that the renderMessages() is called before the messages were deleted in line 529.

This bug is really hard to understand for site builders.
For me, the workaround in #45 works, but this should
definitely be fixed in core!

For me #17 was the cleanest solution until this is resolved, no patch to core.

For anyone facing the same: I had a problem with Devel module when dumping objects or arrays through dpm(). Everything normally collapsed (sub-arrays,...) was expanded and not collapsible.
I could get rid of the problem by disabling Big Pipe (and Big Pipe Sessionless). Or by applying patch #45.
https://gitlab.com/drupalspoons/devel/-/issues/543

Thank you at #111 for testing this, I can confirm patch #45 works for the time being, dpm and kint are essential to our dev process.

Can confirm too, i use patch #45 and it use my status-message template.

Patch from #45 works for me as well.

Patch from #45 works for me too.
Thank you.

Post #94 fixed it for me in my theme without messing with BigPipe.

I got rid of the patch and added the preprocess block as suggested in comment #92 and #94.

This works with bigpipe.

Thank you, this is the cleanest solution for now (for me) as I don't have to patch core.

Just wound up here as well after updating to 10.3. Seems like BigPipe is the issue.

Note: If you're hosted on Pantheon, you can simply disable BigPipe module to resolve the issue, no patching or custom code required.

Ref: https://docs.pantheon.io/modules-known-issues#bigpipe

Adding #94 does solve the issue in a way, but it seems it introduces another issue. on a page that's cached in dynamic page cache, if there's a message to be displayed, it will append at the bottom because it does not find data-drupal-messages-fallback . the fallback markup seems that is not added when rendered this way !?

This problem should be solved in drupal core, the status message does not work properly on custom themed sites.

For us the MR on related issue #3396318: AJAX MessageCommand markup and styling differs from Theme default does not fix the issue. We have a custom module with form_alter that places custom inline status message on specific place. After the #3379885: Use MessagesCommand in BigPipe to remove special casing of the messages placeholder all status messages are rendered on same place:

This issue can be reproduced easily with core (11x.) by creating a custom module with following code and setting the site to maintenance mode and going to "/node/add/article".

<?php
use Drupal\Core\Form\FormStateInterface;

function MY_MODULE_form_node_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  // Some business logic.
  $form['field_example'] = [
    '#theme' => 'status_messages',
    '#status_headings' => [
      'error' => t('Error message'),
    ],
    '#include_fallback' => TRUE,
    '#message_list' => [
      'error' => [
        t('Failed to connect the API service, please try again later.'),
      ],
    ],
  ];

#17 works for drupal/core (10.3.8). I just tried it

Edit: Striking my comment as not being particularly constructive.

We encountered this system message styling issue while upgrading from 10.2.12 to 10.3.11. Our theme is based on Radix 5.

Disabling BigPipe (#30) was a workaround, but yourtheme_preprocess_block__system_messages_block (#17) didn’t work.

Since Radix 6 already fixes this, I backported the solution instead of upgrading.

1. Update {theme}.info.yml:
   (example: radix_starterkit.info.yml)

   libraries-extend:
     core/drupal.message:
       - {theme}/drupal.message

2. Update {theme}.libraries.yml:
   (example: radix_starterkit.libraries.yml)

   drupal.message:
     version: VERSION
     js:
       {path}/{to}/message.js: {}

3. Add {path}/{to}/message.js
   (example: message.js)

For me, using this patch, together with (legacy) bootstrap_barrio:5.1.12 subtheme:

https://www.drupal.org/files/issues/2024-12-04/3456176-bootstrap_barrio-...

Created an issue where:
(1) Clear all caches persists on multiple pages
(2) For anonymous users, applicable status messages (for examples, views_data_export), the messages are unthemed in the footer.

The solution in the end for me was to implement my own message.js in my subtheme, guided by comment #125 and the issue description.

Drupal 10.4.3:
The patch in #45 helped me.

Yous updated to Drupal 10.4.4 and the problem is back again :(
#45 helped me again, but could i be fixed permanently? - I have to edit several sites to fix it.

The permanent fix is likely to happen in #3396318: AJAX MessageCommand markup and styling differs from Theme default. Testing and reviews on that issue would be very welcome (although it needs a fresh MR on there at the moment).

Adapted patch from #45 to core 10.4.6 to workarround barrio related issued reported in #126 when also applying patch from #123.

Finding that the changes described in #94 work for messages like clearing caches and editing content success, but it does not work when used with Views batch processing. In fact, the messages placeholder is removed, and the system message block outputs nothing but BEGIN/END OUTPUT.

The view in question is a views_data_export (8.x-1.5) on Drupal 11.1.6. When batching is included on an export with over 3500 rows, the file generates, but the message to download the file never pops up. Removing the preprocessing function allows the messge to be display, albeit unstyled.

#45 variation for 11.1.6

I can confirm #131.

The preprocess-hook workaround being mentioned here doesn't cut it for showing batch results.

For me, with the patch from https://www.drupal.org/project/drupal/issues/3396318, now it's working.

I looked at it wrong, it doesn't work

Just adding what this is postponed on to the remaining tasks per Remining tasks. I had to restore the standard issue template to do that. In the future, keep all the issue template heading as they are used to track progress and various tasks on an issue.

#45 works for us on Drupal 10.4.

I posted the following at #32 in #3396318: AJAX MessageCommand markup and styling differs from Theme default

We use status-message.html.twig to theme individual messages and #theme => 'status_message' when constructing a render array.

If that proposal is agreeable, this issue would be used to add the theme hook core and template to core themes.

Reroll of #45 for drupal 11.2

Thank you @danchadwick, this was holding me back from running the latest updates, very much appreciated!

Can confirm #138 applies cleanly to Drupal 11.2.

#125 Worked perfectly for me, i'm on D 10.5 using Bootstrap barrio,

When using MessageCommand i would end up with html that could not be modified to adapt my styling.

I just upgraded to Drupal 11.2 and it seems the problem is gone.

@uv516 is that with the patch or without?

@d.fisher: It was without the patch.

Interesting. I will test without the patch.

I newer used patch #125. Only #45 in Drupal 10 (10.3 to 10.5).

I can confirm I am also seeing this issue fixed in Drupal 11.2.2. What do we do now? Close as fixed?

Can anyone locate the commit(s) that fixed this issue in 11.2? Then I'm hoping we can create a back port to 10.4.x.

This isn't actually fixed in 11.2 as such in the same way it wasn't broken as such in 10.3. It happens less often in 11.2, after 10.3 made it happen more often.

If you have a theme that doesn't implement JavaScript message theming, then that is a bug in the theme that can only be fixed in the theme itself. Various subsystems may or may not result in more or less JavaScript messages being added on a site.

10.3 changed the way that big pipe renders status messages so that they're rendered via the AJAX system - this results in more js messages on a site, so it is more obvious when the theme doesn't support them - hence the dozens of people finding that out in this issue.

The workarounds in patches here undo the 10.3 logic but do not resolve the underlying issue.

#3396318: AJAX MessageCommand markup and styling differs from Theme default changes things so that js messaging no longer requires explicit theming at all - the theming would be done by Drupal, the AJAX or pure-js messages would use that theme template for js rendering. Anyone who would like to see this overall problem fixed in a sustainable way in Drupal core should please test/review that issue.

Drupal 11.2 changed how BigPipe messages are rendered again, so that messages that are set on a previous request are no longer rendered via big pipe - this happened in #3508299: Support a placeholder strategy denylist for #lazy_builders.

However, if a message is set while generating a placeholder (e.g. during the rendering of the current page by big pipe), that will still be rendered by the AJAX system and it comes back to whether the theme implements js message theming or not. Those remaining messages (rarer but not impossible) are the ones, along with a few other cases, that #3396318: AJAX MessageCommand markup and styling differs from Theme default would sustainably fix.

Having said all that, if the frequency of this is reduced in 11.2 to the same level it was happening in 10.3, then there is no need for this issue to be open to document workarounds, and we could properly close it as a duplicate of #3396318: AJAX MessageCommand markup and styling differs from Theme default.

Thank you for the detailed explanation @catch! I think the work being done under #3396318: AJAX MessageCommand markup and styling differs from Theme default is the right permanent solution.

I am intrigued by some of the functionality being shown in #3508299: Support a placeholder strategy denylist for #lazy_builders and I need to dig deeper into the #placeholder_strategy_denylist attribute.

For now, we will be relying on the core patch provided in this issue to keep the problem from surfacing on our 10.4.8 app using the uswds_base theme as our base.

Thanks again!

Came here because the version in 10.3.x, which is no longer supported.

That last two comment think this is a duplicate, where the correct fix is in #3396318: AJAX MessageCommand markup and styling differs from Theme default. So I am going to close this as a duplicate and update credit. If you think the credit is wrong, ping me in @contribute on Slack.

I've updated the Issue summary to mention the correct fix and that this issue documents workarounds.

Thanks