Rename the default "Messages" region for all themes to "Highlighted"

Information +1 for me !

Here is a patch to introduce the change of messages (Messages) region to informations (Informations) in Bartik theme.
It does :
- do the change
- make sure messages block is set to informations by default
- add the usual markups for regions :

<div class="informations">
  <aside class="layout-container section clearfix" role="complementary">
     <div class="region region-informations">
       content of information region

Notice it actually fixes CSS issue due to same name between region and block:

"informations"? There is only "information" (dictionary but no "informations", sorry but we should fix that typo.

I would go for notifications because information can be everywhere on a page (an article is also an information) :)

Notifications +1 for me.

+1 for Notification/Notifications.
What about "Status"?

Ok for Notifications.
Regarding child issues, I have closed it to handle the renaming of that region all at once, otherwise patches depend from each other which seems wrong.

Notifications -1 from me.

It is the same meaning as messages, so it doesn't feel like an improvement for:

New regions should not be named after the default content that they hold on install.

How about ""highlightings" since it is actually above everything but still after header, it is made to hightlight some informations.

This can be done here in this issue I guess.
However hightlighted is still much used in core. Ie defined in ThemeHandler.php, used in page.html.twig along with messages and so one.
It looks like we cannot rename 'messages' to 'hightlighted' in core but have both. However, in Seven theme we can rename messages to hightlighted. That means messages would still be available, but not used in Seven. Would it be ok ?

+1 for Highlighted

+++ b/core/themes/bartik/templates/page.html.twig
@@ -109,7 +109,13 @@
+    {% if page.highlighted %}

Just as a side note; this might be unnecessary if condition because I think messages are being printed always so this condition will pass every time #953034: [meta] Themes improperly check renderable arrays when determining visibility

@Dom. Do you mean that the default highlighted region couldn't be used in Bartik? If so, why?

My patch is crappy.

Highlighted makes sense to me.

@Dom. That's true the default regions in Drupal include both messages and highlighted. https://www.drupal.org/node/171206

I think that if we don't need both messages and highlighted for Bartik and Seven than we don't need to add these for all themes, most custom and contrib themes define their own, so what's the benefit of having both in core?

I think we should create a core-wide issue to remove the messages region for all themes and maintain highlighted throughout.

+1 to Highlighted. The other names just felt like synonyms of messages to me.

@LewisNyman for #17 : +1 for this ! Remove Messages region from everything within core : replace it with Hightlighted region everywhere and in core themes.
Would this be accepted though regarding beta evaluation since it may be diruptive to contributed themes that started to go with those core regions.

Little less crappy patch

@laurii: thanks for help on this.
If we go to removing messages in core however, you must take care of it in all core themes: seven, classy etc.. So you will probably need to touch there CSS too.
Also you forgot the core definition of those regions : ThemeHandler.php

I applied this patch and reinstalled Drupal and the messages block appears in the highlighted region in Bartik.

I guess we need to remove this change record or edit it to mention the messages region instead? The messages region was added during the D8 cycle so I don't know if we need to add a CR to say we've removed it again. https://www.drupal.org/node/2398539

Change record edits available for comment: https://www.drupal.org/node/2398539

Until the CR changes are approved, I've left the intermediate screenshot attached to the node, but with "Display" unchecked.

Nice, the change record looks good.

Improving issue title.

Shouldn't this issue also handle the "Messages" region in ThemeHandler, Classy and Seven? I think this improvement makes sense, but wouldn't it better to look at the whole of Drupal, to keep things as consistent as possible? Back to NR for that.

+1 That was my proposition at #21 :)
Because it will be hard to make separated patch for each themes.

Shouldn't this issue also handle the "Messages" region in ThemeHandler, Classy and Seven? I think this improvement makes sense, but wouldn't it better to look at the whole of Drupal, to keep things as consistent as possible? Back to NR for that.

I can answer that, we have followup issues for changing it globally and in Seven #2471697: [meta] Rename the default Messages region for all themes #2471655: Rename the Messages region in Seven.. I think at devdays we decided against doing it in one big patch because this was a big blocker for Bartik issues.

I didn't realise the other issues were closed, I will reopen them.

I'm going to push back on having this inconsistency. I agree with @Wim Leers and @Dom. we should be changing the messages region everywhere to be highlighted.

I'm +1 on the region name of Highlighted. It makes sense to me.

As per the rationale here all other issues are closed in favour of this one, rather than having a META with child issues.

This issue therefore becomes one of combining and making consistent the following (quite small) patches:

* https://www.drupal.org/files/issues/rename-messages-region-2470807-26.patch
* https://www.drupal.org/files/issues/rename-messages-region-2471697-1.patch
* https://www.drupal.org/files/issues/rename-messages-region-2471655-1.patch

Plus also reviewing e.g. files and filenames in core/profiles/standard/config/install , and also confirming we've made any necessary changes to ThemeHandler.

Looking at this now.

Attached is a patch for review. This patch addresses the tasks in #39 as follows:

• Combine 3 existing patches: done on 8.0.x HEAD; "informations" changed to "highlighted" throughout.
• Consider renaming core/profiles/standard/config/install files: NOT done; .yml filename convention seems to be based on the block (messages) rather than the region (highlighted); so leaving as it is.
• Review ThemeHandler: done, provisionally; but I don't know what tests it might break. I'm not set up to run tests locally at the moment, hence uploading for the d.o TestBot!

Mostly as I say above I'm uploading to see if the tests all pass, but also this patch is available for review by the community.

(No interdiff uploaded, as this is 3 patches merged.)

It looks like the tests were failing because they couldn't find some messages that were printed. I had a look over the codebase for anywhere where we were still printing the messages region instead of highlighted. For some reason we were still printing both in Stark? I removed that.

Looks to be missing the core install-page and maintenance-page changes. Was that suppose to be changed? That won't fix the tests though. I'm looking at that now, but haven't tracked it down yet.

This should fix some tests.

+1 to RTBC:

* Patch applies cleanly on 8.0.x HEAD (d4bef05)
* Bartik, Seven and Classy all have a "Highlighted" region
* Bartik and Seven have the "Messages" block within "Highlighted"; Classy doesn't, but then it has no other blocks active and no profile install YAML files, so I'm assuming this is by design?

What shall we do with the change record? As I see it, how we resolve that could be a bit fiddly:

* There was originally a Bartik "Highlighted removed" record.
* When this ticket only covered Bartik, this change record was modified to a Bartik "Highlighted moved" record.
* However, now this ticket covers Bartik, Classy, Seven and core, presumably there are also other change records existing for removing Highlighted from them?

So: should all the other change records be somehow stepped down in favour of the one here, and we then combine everything into one change record? Or should they all be edited in the same way? Do records even exist for all other themes? If not, do we create a new one for each theme?

However, now this ticket covers Bartik, Classy, Seven and core, presumably there are also other change records existing for removing Highlighted from them?

We need to create a new change record that covers all themes. It doesn't exist yet.

Ok the Bartik change record looks good, I've written the change record for all themes. Can someone review it? https://www.drupal.org/node/2486961

Committed 249e520 and pushed to 8.0.x. Thanks!

Thank for adding the beta evaluation to the issue summary.

This introduced a regression for watchdog messaging.

After patch was applied display of messages was being delayed.

Steps to reproduce regression:
- Clean install of Drupal 8 head
- Create a content type with a single image field
- Create a node of that content type and add an image

At the point the image is attached all messages from the install up to that point suddenly appear inline above the image attach area.

Reverting this commit restores normal drupal messaging behavior.

I've tried to reproduce this. Here are my steps:

1. Install Drupal 8
2. Created a content type
3. Created a image field and pressed save on the field settings page
4. Go to node edit screen and upload an image

Adding some info. These are messages I see through the process with the patch applied.

Congratulations, you installed Drupal!
The content type test has been added.
Saved Image configuration.
test blah has been created.

I cannot reproduce the report in #57. @mrf, can you provide more info on your environment, steps, and maybe things you were working on? Were you using the standard install profile or minimal? Did you do anything else before creating the content type? What messages do you remember seeing in the list?

Removing the suggested commit message since its the same as the one that d.o suggests.

If we can't reproduce this, how do we proceed? @mrf, can you try again and see if you get a similar result?

Installed a fresh copy of Drupal8, applied this patch and I am now unable to successfully reproduce this issue.

This came up when I was trying to reproduce the bug in https://www.drupal.org/node/2410001. So no additional patches were applied, just a whole lot of views and content type creation prior to seeing this.

After I initially noticed this issue I pulled the latest core (mine was only a few hours old), dropped my database and reinstalled the standard profile from the UI. For good measure I did the re-install a third time, and was still seeing the same symptoms.

This is when I reverted this patch per Alex's suggestion and I immediately stopped seeing the strange messaging behavior on my next install of the standard profile.

I'm on Ubuntu 15.04, PHP 5.6.4, MySQL 14.14 and NGINX 1.62, no opcode cache installed if that might make a difference.

Ok, found a breadcrumb trail.

That original install where I had seen this issue on this same machine is still showing the issue when I apply the patch to latest HEAD.

I have to be offline for a few hours, but I'll start the process of dissecting the differences between my two D8 installs a bit later this evening to see what the crucial missing piece is to trigger this issue.

My own comment about installing and re-installing tipped me off on to how to reproduce.

This issue will not show up on a brand new install where Drupal has not been installed previously.

This issue will only show up when this patch was applied and Drupal was installed previously and the files/php and config directories were left in place.

Screenshots attached of where the first missing message occurs.

Hmm. That sounds like it isn't a concern then? Since this patch changes regions and templates (particularly changes to BareHTMLPageRenderer and install-page,) I'm guessing there are still compiled templates hanging around in the files directory that the next install ends up using, but conflict with what the live code is now doing. One thing to try is installing fresh with the patch, and then installing again without clearing the files directory. If the problem isn't reproduced, I assume that's the reason.

Hmm looks like Drupal.org swallowed my comment, lets give this another shot.

I just tried again with the patch applied on a clean copy before Drupal was installed and the bug does not occur on a second or third install even with files left in place.

Looks like this was just a transient issue, sorry for all the noise everyone.

Thanks @mrf for checking this out. Let's get this done :)

Committed e050515 and pushed to 8.0.x. Thanks!

Now where is my karma kitten sticker?

@alexpott: I can give you karma kitten stickers for each commit you make from commiting this patch till Drupal Sauncamp if you show up there ;)