Blog Tags: 

Drupal Rules in a nutshell

In a nutshell, Rules is a visual programming tool. Instead of writing code as a block of text, you configure the desired behavior via a GUI that guides you through the setup of "rule sets" which are basically stored procedures that define conditionals and actions to execute, and triggering those rulesets from various canned events.

Rules sets can can call each other immediately (watch out for infinite loops), schedule each other (or themselves) to be called later, etc.

Most of the common trigger events and actions are "canned", which means you can add and configure them from the Rules Admin UI without having to know Drupal internals. When that isn't enough you can program arbitrary trigger events / actions in a PHP block.

The main advantage of using Rules rather than writing code for a custom module is a reduced learning curve. The most common events and actions are listed in the UI. You don't have to know about or remember API calls. For the most common stuff you don't even have to know any PHP.

The main disadvantage is that programming through a GUI can become rather tedious. It's the usual GUI trade off. You pay for the relatively shallow learning curve by giving up power and speed.


Rules is most useful for automating repetitive tasks which is or could be done somewhat tediously by hand.

Like any programming tool, Rules provides enormous power. Once you get past the learning curve it's fun and rewarding to use. Once I had tackled the caching issue I found myself somewhat tempted to go hunting for additional applications to automate.

But watch out. There's a dark side to automation in the form of increased complexity. Don't automate things for the sake of automation. Wait until it hurts first.


  • Drag the "triggered rules" and "rule set" pages to your browser's bookmark toolbar. You'll be going back to them a lot.

  • Add a 'log to watchdog' action to your triggered rules and rule sets as temporary scaffolding to make it easier to test that events are triggered when you think they are.

    On our setup, the watchdog logs go directly to /var/log/drupal via syslog.

  • You can call/trigger rulesets manually by scheduling them to "now". They will be executed the next time the Drupal cron job runs. This is useful for very useful for testing, especially in combination with the watchdog log.

  • It's technically possible to avoid rulesets and just program all the actions you want as actions associated directly with triggered events. Don't do this for non-trivial logic.

    Instead, use rulesets to bundle together/encapsulate related actions into meaningful actions to avoid violating the Don't Repeat Yourself rule, just like you would want to do with a procedure in a conventional programming language.

Add new comment