Problem/Motivation
When doing integration testing with phpunit, WebAssert::buildStatusMessageSelector() requires a <div data-drupal-messages> outer wrapper and per-type <div aria-label="…"> (or aria-labelledby) elements.
ui_suite_bootstrap's status-messages.html.twig produces neither, so the four helpers (statusMessageExists, statusMessageNotExists, statusMessageContains, statusMessageNotContains) always fail when UISB theme is active.
Steps to reproduce
Proposed resolution
- Wrap status-messages.html.twig output in <div data-drupal-messages>
- add aria-label="{{ status_headings[type] }}" to each per-type container.
Remaining tasks
?
User interface changes
None
API changes
None
Data model changes
None
Issue fork ui_suite_bootstrap-3586780
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
herved commentedComment #4
herved commentedComment #5
grimreaperArg, I was so happy to remove this drupalism at that moment.
Can it have an impact on JS generated message?
And message provided by a render array directly?
And when mixed on a page?
Comment #6
herved commentedI had to add an additional "messages__wrapper" div, this now follows more closely what other core themes do.
For JS the relevant logic is Drupal.Message.defaultWrapper and Drupal.Message.messageInternalWrapper.
defaultWrapper() returns firstElementChild when the [data-drupal-messages] wrapper is non-empty. Without
<div class="messages__wrapper">in the template, that would be an individual alert, causing JS messages to nest inside it. The explicit wrapper ensures firstElementChild is always a stable container.PS: I wanted to provide tests for this, extending DrupalMessengerServiceTest but I hit an other undisclosed issue.
Comment #7
grimreaperComment #9
grimreaper