Introduction to the Rules Module

This two-hour webinar will focus on the fundamentals of Drupal's Rules module, and how it can be leveraged to add powerful, custom functionality to a web site. The webinar will introduce the basic fundamentals of the Rules module including the Event-Condition-Action (ECA) methodology as well as using scheduled components.

The Rules module is built around a powerful API with allows other modules to integrate deeply. Drupal Commerce, Content Access, Flag, and Organic Groups all provide Rules integration out-of-the-box.

What can the Rules module do for me?

When working with a Drupal web site, it is common for administrators to be always looking for ways to eek out just a bit more functionality or automation for repetitive tasks. Often contributed modules can provide much of this functionality, but sometimes smaller, more custom bits of functionality are desired. While custom modules are often written to fill this void, not everyone is adept at writing PHP code or familiar with Drupal's API. Luckily, the Rules module can sometimes fill in the gap.

In this webinar, we'll look at the basic fundamentals of the Rules module and then build various examples that will demonstrate the impressive power of this module.

Fundamental Concepts

Dependencies

The Rules module requires the Entity API module. The Views module is also recommended when using the Rules Scheduler module (part of the main Rules module package).

Event-Condition-Action

The Rules module allows site administrators to create actions that are automatically trigged by various events when certain conditions are met. This is perhaps best described by example:

  • Event: an article node is saved → Condition: the article node is not published → Action: send the content editor a message asking them to review the article node
  • Event: an article node is saved → Condition: the user who saved the article node has the "content administrator" role → Action: the article node is published
  • Event: a user joins an Organic Group → Condition: the user does not have the "administrator" role → Action: send the user a welcome message
  • Event: an calendar item node is created → Condition: the calendar item node doesn't have a populated "agenda" field → Action: send the author a message two days before the calendar item date reminding them to populate the "agenda" field
  • Event: a log entry is created → Condition: the log entry's severity is "emergency" → Action: send a message to all users with the role "site administrator"
  • Event: a node is about to be saved → Condition: the image field is empty → Action: display a message asking the author if they're sure they don't want to add an image

Rules components

Rules components are parts of rules that can be utilized inside other rules. For example, if you have a custom action that you want to use in multiple rules, a rule component made up of the custom action can be created then simply added to each rule.

When the "Rules Scheduler" module is enabled, components can be scheduled to run at a future time. This is a common use case for rules components. For example:

  • Event: a node is created → Condition: node is published → Action: close comments → Scheduled: +2 weeks from the time the node is created

Rules UI Interface

  • Main Rules configuration at "Configuration | Workflow | Rules" (/admin/config/workflow/rules)
  • The Rules "project" contains three modules: Rules, Rules UI, and Rules Scheduler.
  • Rules are "exportable" - they can be exported to a text file, and imported on another site. Additionally, exported rules can be saved to code (via a Feature or custom module).
  • Rules can be disabled without being deleted.

Tips and tricks

While Rules is an extremly powerful module, it is also one usually requires a bit of experience to use effectively. Here are some of tips and tricks to get you started.

  1. Most important Rules tip ever! When trying to access a specific field via a data selector in an "action", it is usually required that the "entity has field" condition be set for the same field in order for it to work in the "action" For example, if you're trying to access a field called "field_last_name" in an action, be sure to add an "Entity has field" condition for "field_last_name" as well.
  2. Using data selectors effectively is the key to writing powerful rules. This screencast is a good resource to get started.

Examples

Initial setup on a fresh Drupal 7 site:

  • Create new roles: content administrator (no additional permissions), author ("Article: create new content", "Article: edit own content")
  • Create new user with "author" role
  • Create new user with "content administrator" role

Notify content administrators when new content is posted by non-content administrators.

  1. Go to admin/config/workflow/rules and click to "Add new rule"
  2. Name: Notify content admins of new content
  3. Event: After saving new content
  4. Condition: Entity is of type Node, Data selector=node (Created content), Entity type value=Node
  5. Condition: User has role(s), Data selector=node:author, Roles:administrator, content administrator, Match roles value=any, Negate
  6. Action: Send mail to all users of a role:
    • Roles: content administrator
    • Subject: New content!
    • Message: There is new content on the site, [node:title], [node:url], Posted by: [node:author]

Notify site administrators when an log entry with a severity of "warning" or "error" is reported

  1. Go to admin/config/workflow/rules and click to "Add new rule"
  2. Name: Notify of Emergency
  3. Event: System log entry is created
  4. Condition: Data comparison, Data to compare: [log-entry:severity], Data value: error
  5. Condition: Data comparison, Data to compare: [log-entry:severity], Data value: warning
  6. Add both Conditions to an "OR" group
  7. Steps 4-6 can also be done using the "is one of" operator.
  8. Action: Send mail to all users of a role:

Close comments on nodes after 2 weeks

Create component to close comments

  1. Go to admin/config/workflow/rules/components and click to "Add new component"
  2. Component plugin: Action set (because our component performs an action)
  3. Name: Close comment on node
  4. Variables: Data type=Node, Label=Node, Machine name=node, Usage=Parameter
  5. Add action: Set a data value, Data selector=node:comment (Comments allowed), Value=1 (Closed)
  6. Save changes

Where does value=1 (closed) for node:comment come from? If you inspect the "Default comment setting for new content" select box on any content type's settings page (admin/structure/types/manage/article, for example), the three possible values are:

  • Hidden=0
  • Closed=1
  • Open=2

A bit of black magic, I know...

Create rule to close comments on a new articles after two weeks

  1. Go to admin/config/workflow/rules and click to "Add new rule"
  2. Name: Close comment on articles after 2 weeks
  3. Event: After saving new content
  4. Condition: Content is of type, Data selector=node, Content types=Article
  5. Condition: Content is published, Data selector=node
  6. Action: Schedule component evaluation, value=Close comment on node, Schedule evaluation date value=+ 2 minutes (for testing), Identifier=Close comment on article - node ID: [node:nid], Node Data selector=node

To test this rule, create a new node of type "article", wait 2 minutes, run cron, then confirm comments are closed. Once tested, edit the "action" and set the evaluation date to "+ 2 weeks".

As time permits, a second rule can be created to update "reset the clock" on comments closing when an article is updated. This rules needs to have 2 actions - one to delete existing scheduled components for the article, and one to set a new scheduled component.

Resources