Emailing Users About Content Activity in Drupal 8

Site owners and administrators often want to send emails to users telling them about content creation or changes. This sounds basic, but there are a lot of questions. What exactly needs to be accomplished? Some examples could include:

• Send notifications to authors when their content is published.
• Send notifications to authors when users comment on it.
• Send notifications to administrators when content is created or updated.
• Send notifications to site users when content is commented on.
• Mail the content of a node to site users when content is created or updated.
• And the list goes on…

The first step in assessing solutions is to identify the specific need by asking the following questions:

Who needs to be notified? 

• So many options! It could be an editor, the author, all site users, all site users of a given role, a specific list of users, anyone who commented on the node, or anyone who subscribed to the node.

When should notifications be created?

• A little simpler, but it could be when the node is created, when it is published, or when it is commented on. A message might be initiated every time the action happens, or postponed and accumulated into a digest of activity that goes out once a day or once a week or once a month.

When should notifications be sent?

• This could be immediate, sent to a queue and processed on cron, or scheduled for a specific time.

What should deliver the notification?

• Is it both possible and feasible for the web server to be responsible for delivering the notification? Does a separate server need to deliver the mail, or perhaps a third party mail delivery service needs to be used? 

How should recipients be notified?

• Assuming that they should be notified by email, there could also be a long list of other options available.

What should recipients receive?

• Notifications could be just messages saying that the node has been created, changed, or published. It might include a summary of the node content, or the entire content of the node could be sent in the email. This could also be a digest of multiple changes over time.

How much system flexibility is required?

• This could encompass anything from a very simple system, like a fixed list of users or roles who are always notified, all the way to complicated systems that allow users to select which content types they want to be notified about, maybe even allowing them to subscribe and unsubscribe from specific nodes.

Clarifying the answers to these questions will help define the solution you need and which module(s) might be options for your situation. There are dozens of modules that have some sort of ability to send emails to users. While I did not review all of them, below are reviews of a few of the most widely-used solutions.

Note: There are also several ways to use the Rules module (possibly in conjunction with one of these solutions), but I did not investigate Rules-based solutions in this collection of ideas. 

Admin Content Notification

The Admin Content Notification module is designed to notify administrators when new content is created, but it can also be used to notify any group of users, administrators or not. The configuration allows you to choose either a hard-coded list of email recipients or send notifications to all users that have one or more specified roles. Since you can send notifications to users by role, you could create a new ‘email’ role and assign that role to anyone who should be notified.

Some of the capabilities of this module include:

• Selecting content types that should generate notifications.
• Choosing whether to send notifications only on node creation or also on updates, and whether to notify about unpublished nodes or only published nodes.
• Selecting roles that have permissions to generate notifications.
• Selecting either a hard-coded list of email addresses OR a list of roles that should receive notifications.
• Creating a notification message to send when content is created or changed.
• Adding the node content to the message by using tokens.

The settings for this module are in an odd location, in a tab on the content management page.

This module is extremely easy to set up; just download and enable the module and fill out the configuration settings. Because of its simplicity, it has little flexibility. All content types and situations use the same message template, and there is no way for users to opt in or out of the notifications. There is no integration with changes in workflow states, only with the published or unpublished status of a node. This module provides no capability to send notifications when comments are added or changed. If this capability matches what you need, this is a very simple and easy solution.

Workbench Email

Workbench Email is part of the Workbench collection, but it also works just with core Content Moderation. This module adds the ability to send notifications based on changes in workflow states. 

You begin by creating any number of email templates. In each template, you identify which content types it applies to, who should get emailed, and what the email should contain. The template uses tokens, so you can include tokens to display the body and other custom fields on the node in the message.

Once you’ve created templates, you edit workflow transitions and attach the templates to appropriate transitions. The screenshot below is a bit confusing. The place where it says Use the following email templates is actually below the list of available templates, not above the list. In this example, there is only one template available, called Notification, which has been selected for this transition.

Documentation for the Drupal 8 version does not exist and the screenshots on the project page don’t match the way the site pages look. There is, however, good integration with core Workflow and Content Moderation, and there is a certain amount of flexibility provided in that you can create different messages and send messages to different people for different transitions. There is a documented bug when uninstalling this module, so test it on a site where you can recover your original database until you decide if you want to keep it! This module provides no capability to send notifications when comments are added or changed.

Comment Notify

This module fills a gap in many of the other solutions: a way to get notified about comments on a post. It’s a lightweight solution to allow users to be notified about comments on content they authored or commented on. Configuration is at admin/config/people/comment_notify:

The module has some limitations:

• Only the author can automatically receive notices about all comments on a thread.
• You won’t receive notices about other comments unless you add a comment first.
• You can only unsubscribe to comments by adding another comment and changing your selection.
• There is only one template and it applies to all content types.
• You can’t automatically subscribe groups of users to notifications. Each user manages their own subscriptions.

With the above restrictions, the module is an easy way to get the most obvious functionality: be notified about comments on content you created, and be notified about replies to any comments you made. This module could be combined with solutions that only provide notifications about changes to nodes for a more comprehensive solution.

Message Stack

The Message Stack is an API that you must implement using custom code. Unlike the above modules, this is absolutely not an out-of-the-box solution. It’s much more complex but highly flexible. Much of the available documentation is for the Drupal 7 version, so I spent quite some time trying to understand how the Drupal 8 version should work. 

The Message module creates a new “Message” entity. Your custom code then generates a new message for whatever actions you want to track—node creation or updates, comment creation or updates—all using Drupal’s hooks. You can create any number of token-enabled templates for messages, and implement whichever template applies for each situation in the appropriate hook. Using a separate module in the stack, Message Notify, you choose notification methods. It comes with email or SMS plugins, and you can create other notification methods by creating custom plugins. A third, separate module, Message Subscribe, is used to allow users to subscribe to content using the Flag module. You then create custom code that implements Drupal hooks (likehook_node_insert()) to create the appropriate message(s) and send the messages to the subscriber list.

One head-scratcher was how to set up the module to populate the email subject and message. You do it by creating two messages in the template. The first contains text that will go into the email subject, the second contains the text for the email body. You’ll see two new view modes on the message, mail_body and mail_subject. The subject is populated with Partial 0 (the first message value), the body with Partial 1 (the second message value).

Another thing that took me a while to get my head around is that you designate who the message should be sent to by making them the author of the message, which feels odd. "Author" is a single value field, so if you want to send a message to multiple people, you create a basic message, clone it for each recipient, and change the author on the cloned version for each person on the list to send them their own copy of the message. This way each recipient gets their own message, making it possible to dynamically tweak the specific message they receive.

The Message Subscribe module does all that work for you, but it’s useful to know that’s what it’s doing. It creates Flag module flags that allow users to select which content they want to be notified about and hooks that allow you to alter the list of subscribers and the messages each receives in any way you like. That means that your custom code only needs to create the right message in the right hook. If you want the message to just go to the list of people who already subscribed to the content, you do something like this:

/**
 * Implements hook_node_update().
 */
function mymodule_node_update(Node $node) {
  $message = Message::create([
    'template' => 'update_node',
    'uid' => $node->getOwnerId(),
  ]);
  $message->set('field_node_reference', $node);
  $message->set('field_published', $node->isPublished());
  $message->save();
  $subscribers = \Drupal::service('message_subscribe.subscribers');
  $subscribers->sendMessage($node, $message);
}

You can also add to or alter the list of subscribers and/or the specific text you send to each one. To add subscribers, you create a DeliveryCandidate with two arrays. The first is an array of the flags you want them to have, the second is an array of notification methods that should apply. This is very powerful since you don’t have to wait until users go and subscribe to each node. You can “pseudo-subscribe” a group of users this way. This is probably most applicable for admin users since you might want them to automatically be subscribed to all content. Note that this also eliminates any possibility that they can unsubscribe themselves, so you’d want to use this judiciously.

/**
 * Implements hook_message_subscribe_get_subscribers().
 */
function mymodule_message_subscribe_get_subscribers(MessageInterface $message,
array $subscribe_options, array $context) {
  $admin_ids = [/* list of uids goes here */];
  $uids = [];
  foreach ($admin_ids as $uid) {
    $uids[$uid] = new DeliveryCandidate([], ['email'], $uid);
  }
  return $uids;
}

A lot of configuration is created automatically when you enable the Message Stack modules, but some important pieces will be missing. For instance, message templates and fields might be different in different situations, so you’re on your own to create them.

I created a patch in the issue queue with a comprehensive example of Message, Message Notify, and Message Subscribe that contains the code I created to review these modules. It’s a heavily-commented example that creates some initial configuration, combines code from all the Message example modules, is updated with information I derived from various issues and documentation that I found after searching the Internet and a bunch of trial and error in my test site. It’s a comprehensive alternative to the other examples, which are pretty basic, and should answer a lot of the most common questions about how to configure the module. I included lots of ideas of things you can do in the custom code, but you’ll probably want to remove some of them and alter others using what’s there as a starting point for your own code. Read the README file included in that patch, visit the configuration pages, and review the example code for more ideas of how to use the stack. 

Note that I ran into several issues with Message Subscribe and submitted potential patches for them. Most of them related to the Message Subscribe Email module, and I ultimately realized I didn’t even need that module and removed it from my example. I found an easier way to email the subscribers using just one line of code in my example module. The remaining issue I ran into was one that created serious problems when I tried to queue the subscription process. I suggest you review and use that patch if you alter the list of recipients and use the queue to send messages.

Which module to use?

That’s it for the modules I reviewed this time. Which one(s) should you use? This is Drupal! Take your pick! There are many ways to solve any problem.

Seriously, it really comes down to whether you want something out-of-the-box that requires little or no code, or whether you need more customization and flexibility than that. 

In summary:

• If you want an easy, out-of-the-box, solution to notify users about published content and comments, a combination of Admin Content Notification and Comment Notify could work well.
• If you need to notify users about changes in workflow states, Workbench Email is an easy solution.
• If you need a highly customized solution and you are comfortable writing code and using Drupal’s APIs, the Message stack has a lot of potential.

For my project, an intranet, I ultimately selected the Message stack. I created a public repository with a custom module,  Message Integration, that integrates the Message stack with Swiftmailer and Diff to automatically subscribe all users to new nodes and email the subscriber list with the node’s content when nodes are published, a diff of the changes when new revisions are created, and the text of new comments on nodes they subscribe to. The code is too opinionated to be a contrib module, but it could be forked and used on other sites as a quick start to a similar solution.

Any of these modules (and probably lots of others) might work for you, depending on the specific needs of your site and your ability and desire to write custom code. Hopefully, this article will help you assess which modules might fit your communication needs, and provide some comparison for any other solutions you investigate.