Since 8.7.0, empty status messages leave empty DIVS causing regions to render even though they are empty.

<div class="region region-system-messages">
    <div data-drupal-messages-fallback="" class="hidden"></div>
  </div>

Comments

kruser created an issue. See original summary.

joegl’s picture

For more info: https://www.drupal.org/node/3002643

It doesn't make sense to me to force rendering of a block when it's empty. There also isn't a very good CSS approach off the top of my head for countering this (styling based on whether the block has content or not).

aramboyajyan’s picture

Same here. It seems that this would require applying styling to the messages themselves, which isn't the most practical thing if there are several wrappers for that region.

Does anyone know if there's a way to disable this from code?

johnpitcairn’s picture

Title: Empty Status messages should be hidden » The data-drupal-messages-fallback element cannot be removed.
Version: 8.7.x-dev » 8.8.x-dev

Hmm. The system_messages_block plugin itself is what is setting the relevant render element variable.

You'd think setting the #include_fallback content key to FALSE in template_preprocess_block() would be able to kill this empty js messages fallback div, but no, that doesn't work.

johnpitcairn’s picture

Title: The data-drupal-messages-fallback element cannot be removed. » The data-drupal-messages-fallback element cannot be removed and causes empty regions to render
joegl’s picture

effulgentsia’s picture

If all you want to do is remove the data-drupal-messages-fallback div, then you can do that by adding this preprocess function:

function YOUR_THEME_preprocess_block__system_messages_block(&$variables) {
  $variables['content']['#include_fallback'] = FALSE;
}

However:

  1. Doing so prevents your site from benefitting from the JS message API. Core isn't using this new API yet, but it might at some point. There might be contrib modules using it already. Think about whether you really want to make your site incompatible with showing status messages generated by JS code.
  2. While the above removes that one div, it doesn't prevent the region from rendering. That's because even without the fallback, status messages (whether empty or not) are rendered with a placeholder (see Drupal\Core\Render\Element\StatusMessages::generatePlaceholder()), so when the region renders, it always sees that placeholder as something that is not empty. While there are ways to override that, doing so would introduce bugs related to caching, which would then require additional workarounds to fix.

Since 8.7.0, empty status messages leave empty DIVS causing regions to render even though they are empty.

Item 2 above has been how Drupal 8 has worked since 8.0. Are you sure you had a pre-8.7 site where the region didn't render at all? Are you able to reproduce that with core alone, or did that require additional contrib/custom code?

johnpitcairn’s picture

Fair enough. I think the only reason I've noticed this new placeholder is that I'm building a minimal-markup theme to see how minimal I can go.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

letrollpoilu’s picture

I'm also having this issue. The empty tag doesn't bother and the rendering of the empty region is a problem.

Is there a way of doing something like that to prevent the rendering?

{% if page.messages|render|render|striptags is not empty %}

I tried it and wasn't working....

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

mightyulysses’s picture

I'm experiencing this issue in 8.9. The preprocess function describe in #7 didn't work for me. Is there another preprocess I can use?

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

YnotB’s picture

This worked for me using Drupal 8.8.6

function YOUR_THEME_preprocess_html(&$variables) {
$variables["page"]["content"]["messages"]["#include_fallback"] = false;
}

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.