Drupal 8 Messenger Service

7th February 2019 - 2 minutes read time

Note: This post is over a year old and so the information contained here might be out of date. If you do spot something please leave a comment and we will endeavour to correct.

For a long time the drupal_set_message() function has been a mainstay of Drupal development. You can use this function to print a message or an error response to a user. This is useful to do as it can be done almost anywhere before the final page rendering functions and will be printed into the same area of a Drupal page.

This has recently been deprecated in Drupal 8.5.0 and so I was looking around on how to do the same thing in a new way. Drupal now has a messenger service, powered by the class Drupal\Core\Messenger\Messenger. This can be included into your code using the following shortcut.

$messenger = \Drupal::messenger();

This can be used to print messages to the user. For example, to print a standard message with a blue background do the following.

$messenger->addMessage('Message printed to a user.');

This can be done in one line like this.

\Drupal::messenger()->addMessage('Message printed to a user.');

There are four different types of message available, each of which is printed with other messages of the same type and on a different coloured background.

// Green status message.
$messenger->addStatus('Print a status to the user.');
 
// Blue message.
$messenger->addMessage('Message printed to a user.');
 
// Yellow warning message.
$messenger->addWarning('A warning about something!');
 
// Red error message.
$messenger->addError('An error happened!');

If you are in a Drupal 8 Form's submitForm() handler then you can also get access to the messenger service through the form object.

$this->messenger()->addMessage($this->t('Form message.'));

If you are still using drupal_set_message() then I recommend that you swap to the messenger service soon as it will be removed in future versions of Drupal.

Drupal 8

Drupal

Drupal 9

Add new comment

Related Content

Drupal 9: Selecting Machine Names For Content Entities And Fields

Naming things is hard^{[citation needed]} and there are a lot of things that you can name when configuring a Drupal site. Picking the right machine names for the different parts of Drupal can make your life easy in the long run. Changing labels is simply a case of tweaking the label in the interface, or through configuration updates. The issue is that once you decide on a machine name for something in Drupal it's pretty much set in stone forever.

Drupal 9: Configuring Drupal To Be An Identity Provider With SimpleSAMLphp

I have previously talked about configuring a Drupal site to authenticate against a remote SimpleSAMLphp install, but as Drupal is an excellent user management system I wanted to turn it around and use Drupal as the identity provider. This means that Drupal would allow users to log into other systems using their Drupal username and password by leveraging the power of SimpleSAMLphp.

Drupal 9: Configuring Drupal To Authenticate Against A Remote SimpleSAMLphp Identity Provider

I have previously talked about installing SimpleSAMLphp using composer, so the next step is setting up the system to actually provide authentication against a SimpleSAMLphp system. As I spend a lot of time using Drupal I wanted to set up the authentication with Drupal and SimpleSAMLphp in order to see how things worked.

First, let's define a couple of terms that are important to this setup.

Drupal 9: Creating A GET Form

I've been building Drupal forms for a number of years so I'm quite familiar with to putting together a Drupal form using the FormBase class and the form API. When I attempted to create a GET form this week I realised that there is actually quite a bit to think about. All forms are build using GET requests, it's the submission that I am specifically talking about. By default, forms in Drupal use POST requests to submit their data, and although it is possible to convert a form to use GET to submit data, it isn't well documented.

Drupal 9: Blocking Common Exploit Paths

If you run a Drupal site for any length of time you will quickly realise that a few paths that have nothing to do with Drupal will receive a lot of traffic. All of these paths result in page not found errors so the only impact is taking up your server resources. It's common to see paths like wp-login, xmlrpc.php, phpBB/page_header.php, postnuke/article.php, as well as a multitude of others. These requests are clearly bots probing the site to see what sort of CMS is in use and if they can exploit it or not.

Drupal 9: Changing Config Through Update Hooks

Drupal configuration is normally changed or removed through the configuration import and export process. For example, the process I follow is to make the change in the configuration locally, export the configuration into the source code, deploy the source code to a remote server and import the configuration. Using this mechanism, configuration changes that were exported locally are imported into the site and are ready to use.