Replace calls to deprecated function drupal_set_message with calls to the messenger service

one less hidden dependancy.

updated this a little.

Updating the issue summary to highlight that this patch valid on Drupal 8.5.x but that this will break on Drupal 8.4.x

fixing another minor err - while I see it.

As well as being postponed .. I think the patch needs to be discarded and a alternative approach taken.

When this patch lands ...

#2935255: Remove all usages of drupal_set_message and drupal_get_messages in core lib

all the cases in the patch extend FormBase or ControllerBase so we pick up the MessengerTrait

- drupal_set_message("Sample text");
+ $this->messenger()->addStatus("Sample text");

So my intent here is to work on this again after 3 months ....

Get it into a converted working state and then postpone again while we talk about the correct time to commit this....

Today core ( 8.6.x ) has committed conversions of a bunch of these.

Specifically in relation to this issue I see that

#2935256: Remove all usages of drupal_get_message and drupal_set_message in modules

has given ConfigFormBase the MessengerTrait - which resolves the issues I was talking about in #10

a) From #8

Also, this patch should require 8.5 in devel.info.

As appropriate, I have modified three info files.

b) As per the change record, the messenger service should probably be directly injected into any custom service rather than using the trait functionality.

c) I have simplified the constructor's of classes that extend base classes.

d) Something new to this issue ... I had to refactor devel_generate/devel_generate.batch.inc

e) See DevelGenerateBase there was a minor maintenance hazard - $type defaulted to 'sting' --- if MessengerInterface ever did anything crazy like updated the value of TYPE_STATUS .. we would be out of sync with that craziness. So I made this change.

protected function setMessage($msg, $type = MessengerInterface::TYPE_STATUS) {

So now we have to discuss Moshe Weitzman's "prudent" comment from #8

PS The last patch need a reroll, I said I was going to start from scratch in any event so no interdiff.

Go testbot go.

My bad,

$this->messenger is wrong

$this->messenger() is good

I cut and paste that from the change record... so I am about to update the change record...sorry for the distraction.

Locally DevelQueryDebugTest now passes.

Thanks for the quick review... I hope I have corrected everything.

I have a question should we consider MessengerTrait for the same purpose ?

A decision tree for when to work with traits

1) If it is a service you are creating then avoid the trait and directly inject into the constructor

2) If it is a small controller method, and it is appropriate to extend ControllerBase, then look for the trait in the base class

3) If what you are writing can be considered application code, then use traits

4) Testing can become complicated. so if you need 100% coverage then consider converting a trait into DI logic.

I hope this helps.

With a DrupalCon starting... I should say I am working on this.

I had to undo do dependency injection ( in the constructor ) because head had already converted many classes to use the trait. No biggie.

First step, reroll.

No conflicts just auto merging.

Note to self -- when there a DrupalCon going I must pull everyday.

A little fix.

Another fix.