10.3 upgrade now missing status-message theme sugestions

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.

🐛 status message notification twig file name changed Postponed: needs info

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've just set olivero as the default theme on my site and modified /themes/olivero/templates/misc/status-messages.html.twig myself. It did nothing.

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 🐛 Some theme hooks are not invoking (depends on templates order provided by filesystem) Needs work 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.php. 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] => 
)

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 🐛 10.3 upgrade now missing status-message theme suggestions Postponed

@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(-)

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, 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));
          //   }
          // }

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 🐛 10.3 upgrade now missing status-message theme suggestions Postponed 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's removed 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));
            }
          }

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 📌 The AJAX messages command should render messages using the twig template Active 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 📌 The AJAX messages command should render messages using the twig template Active 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 📌 The AJAX messages command should render messages using the twig template Active

... 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:

  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.

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 🐛 10.3 upgrade now missing status-message theme suggestions Postponed 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, workaround #45 is not necessary, at least in all the pages so far i have tested it.

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 📌 The AJAX messages command should render messages using the twig template Active 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 🐛 AJAX MessageCommand markup and styling differs from Theme default Needs work , since the other was closed as a duplicate.

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

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 📌 Add js message theme override to match Umami message markup Needs review 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 🐛 AJAX MessageCommand markup and styling differs from Theme default Needs work , 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 implement Drupal.theme.message, and that doesn't fix the issue, because the function isn't being called for the BigPipe messages. Only commenting out that BigPipe code 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 🐛 10.3 upgrade now missing status-message theme suggestions Postponed

#17 🐛 10.3 upgrade now missing status-message theme suggestions Postponed works for me fine on Drupal 10.3.1.
Thanks.

+1 #17.

hook_theme_suggestions_HOOK_alter works as expected after this is called

#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.

+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. 🐛 10.3 upgrade now missing status-message theme suggestions Postponed
https://www.drupal.org/project/uswds_base/issues/3465493 📌 Drupal 10.3 changes how to theme status messages. Active
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 🐛 10.3 upgrade now missing status-message theme suggestions Postponed 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.

@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 → changed the visibility of the branch 3456176-10.3-upgrade-now to hidden.

@acbramley the only way to make status messages the same for ajax vs. non-ajax responses for all themes would be to do 🐛 AJAX MessageCommand markup and styling differs from Theme default Needs work , 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 (looking good):

<!-- 💡 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 markup is like so (not looking good)

<!-- 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 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>

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) 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.

There is also a core patch here that looks like it does something similar.

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 the following error is found in the console log

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 🐛 Message Notifications appear broken when using Olivero with Drupal10.3 Active

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 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 ✨ Add support for additional coloured notices Needs work

The good news is i seem to be able to apply https://www.drupal.org/project/drupal/issues/3456176#comment-15738200 🐛 10.3 upgrade now missing status-message theme suggestions Postponed 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 patches 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.

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

I think that is why the result are diffferent between anonymouse and authenticated users.

There's now an MR to consolidate the theming of status messages over on 🐛 AJAX MessageCommand markup and styling differs from Theme default Needs work 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 there is another big-pipe placeholder callback 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 delete 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.

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 🐛 AJAX MessageCommand markup and styling differs from Theme default Needs work does not fix the issue. We have a custom module with form_alter that places custom inline status message on specific place. After the 📌 Use MessagesCommand in BigPipe to remove special casing of the messages placeholder Fixed 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 🐛 10.3 upgrade now missing status-message theme suggestions Postponed works for drupal/core (10.3.8). I just tried it

I’m curious why there is not discussion about officially reverting the BigPipe change that has created this problem? The workaround patch at #45 seems to remove the offending 3 lines of code.

While 🐛 AJAX MessageCommand markup and styling differs from Theme default Needs work might be the perfect long term solution, the current state of SystemMessagesBlock is a fairly major breakdown (in my opinion).

Shouldn’t those 3 lines of BigPipe code (shown clearly in comment #45) be removed as soon as possible? Once the new solution for the RenderMessagesCommand is ready, BigPipe can then return to taking control of system messages.

Just a thought and please forgive me if it has already been discussed and ruled not a good idea for reasons that I’m not privy to.