I am working on replace an existing, custom built website with a Drupal 7 site. In the existing website I've coded a more or less smart email-notification system which I like to re-build for the Drupal version (if possible).

The website allows members to create/edit/cancel events, participate/decline events, comment events etc. If any of these action happened they where logged for email-notification. The user then could set an interval how often the so called "Action-Log" should be emailed to the user. eg. once an hour, every four hours, one a day or once a week. This is extremely handy to a) stay in touch with the event and b) to not fill the members inboxes.

Advanced feature (phase 2): Further more the website had some logic to reduce the notification if or example a member already declined an event he will not get any notifications about that event. Think this will get really tricky to do in a generic way.

Any hints about how to do this with Drupal 7?

I already had a look to the following modules:

  • Triggers / Actions (sonding email but not "cached/delayed").
  • EntityRegistration (used for event registration).
  • Notifications (is alpha on D7 and called "quick port").

PS: I was told this feature is normally called "digest".

2 Answers 2


For sending notifications you can use the Notifications module.

  • 1
    Seems not to be ready yet for D7 - as I wrote above.
    – Marc
    May 15, 2012 at 10:50
  • I too have not found a good D7 solution to email digests/queues.
    – Sam Becker
    Nov 14, 2012 at 8:14
  • Hey @Sam152, are you still looking for it? If so: check my answer (it only took like 5 years ...). Sep 5, 2017 at 17:17

Part 1 - Building your action logging

IMO the Message module could be a perfect alternative for the activity logging you are trying to implement. Using this module, you can create your own custom "Events logging" (to register things that happened in a site).

Specific to this question here, I'd create one or more so called "Message types" that contain data about:

  • the usernames (of the latest editors of content).
  • the relevant date(s).
  • any data about the actual entity (node, user, etc) or event you want to track, such as the node's id, its title, author, relevant field values, etc.

You could even track things like updates to nodes, i.e. how data looked like before and after they got updated, a kind of "light" revisioning (only for those node attributes you want to know about).

About Message types: think of them as equivalent to Content types, whereas you create messages (instead of nodes) of a specific Message type (instead of Content type).

Part of the Message Stack

The Message module is part of the Message Stack, which consists of these modules (quotes are from the module's project page):

  • Message:

    The Message module is the core of the message stack. It enables logging and displaying system events in a number of different use cases. Events that are recorded over time are sometimes call activity streams. Exportable messages subtypes can be created for different use cases with custom fields and display (view) modes.

  • Message Notify.

    This module provides a method for sending a message via a notifier plugin. Message Notify comes with plugins for email and SMS and may be extended to other transport mechanisms as required.

  • Message Subscribe.

    With this module, users who subscribe to content will be notified when events occur that involve that content. The module leverages the Flag module, which provides a subscribe functionality to users.

These are the basic components and dependencies of the message stack:

enter image description here

Think of the Message Notify / Message Subscribe modules as successors (replacements?) of the Notifications / Subscriptions modules ... even with Drupal 8 successors available also.

Just looking at the available documentation about the Message Stack, it's not obvious to get going with it. But if you want to have a closer look at the Message Stack in your own environment, then experiment a bit with the Answers module (disclosure: I'm a co-maintainer), together with the Answers Notification sub-module, which allows logged in users to subscribe to selected questions, so that they receive notifications (using the Message Stack) when Questions receive Answers.

Rules integration

A really interesting facility of the Message module is its perfect integration with the Rules module. Have a look at the answer to "How to implement a follow author (or user) function?" for way more details on that.

As an example, here is a (rather basic) custom rule:

  • a Rules Event like "Before saving a new node", of "After updating an existing node" (or variations of these events).
  • a Rules Action to "Create a message" (of a selected Message type).

That's really it ...

Example included in Commerce Kickstart

A great sample of this can be found in Commerce Kickstart, which uses the Commerce Message module, to create such "Events logging". In that case in the format of an Order History, as shown in this screenprint (from this module's project page).

Replicate/replace the Activity module

Should you want to do so, it seems perfectly possible to build a view (report) that contains the data similar to what you can do with the Activity module as shown in this screenprint (from this module's project page).

More info about the Message module

The Message module is an amazing module, it is fully entity based, which implies that it perfectly (out of the box) integrates with modules such as Views and Rules.

Though there is not a lot of documentation about it (which is what makes it a hidden D7 gem ...). A possible way to get started with it, and to get an idea of the kind of things it can be used for, is to have a look at the answers to:


Part 2 - Building your journal style Newsletter

After you've implemented your action logging, similar to what is described in "Part 1", it really becomes a piece of cake to complete it with the journal style Newsletter. Because your action logging will be fully entity based, and therefor perfectly integrates with modules such as Rules and Views.

If you then also add the Views Rules module to it, you've reduced your Newsletter challenge to building some rules that:

  • Run at specified intervals (eg when cron runs).
  • Process (= Rules Actions) a views result (using Views Rules) to create an appropriate "digest" of relevant messages contained in your action logging.
  • Send that digest by eMail to only those users for which the Views results are not empty (i.e. if there is anything new that happened in the site, and which the user wanted to be informed about).

PS: for dozens of other questions (+ answers) about the Message Stack, refer to this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.