New features for the Rule module!

Recently, the Drupal 7 Rules module has received some new functionality - mostly thanks to the development of the fluxkraft project. Quite some of them are under-the-hood improvements available to developers, but there is new stuff for site builders as well. So let's have a look at what's new for everyone using Rules and at what's in for developers also:

Configurable bundles for entity events & support for event settings

With Rules 2.4 events may define an event setting form via an optional event handler class. This might be useful in various scenarios, one of which Rules already implements: It's now possible to restrict entity related events to certain bundles immediately when adding an event. Compared to the previous way of adding a generic entity event plus a separate condition to check the bundle (e.g. "After saving new content" plus "Content is of type" condition) it's way nicer to just select the content type directly while adding the event:

However, the new improvement is more than just a UX improvement - it performs better as well. That is, as when you use the event settings Rules only fires up when the configured event occurs - e.g. "After saving a new article". But if another content type is created Rules won't chime in at all. In most situations that's not a big improvement, but in certain performance critical situations it's quite valuable. That way it opens the door to the creation of useful new events (path-specific rendering events, anyone? :-)

Entity is of bundle condition

This is a new condition that is already available for a while, i.e. since Rules 2.3 - but as it relates to one of Rules' most confusing issues I'd like to highlight it here also. As probably most of you know, when you deal with an entity while configuring a rule, Rules "sees" only all the properties and fields that it knows to be there later on. That is, if you have a content node, but you do not know the content type, you won't see any fields that are content-type specific. The way around this is that you do a check on the bundle, e.g. you use the "Content is of type" condition or the "Data comparison" condition to make sure the content type is e.g. "article". Given that Rules knows it's an article, you'll get to see the article related fields then. 
However, with other entity types - e.g. taxonomy terms - there is no such neat "Term belongs to vocabulary" condition (patch welcome!), so you'd have to go with the generic "Data comparison" condition and know what you have to check for to make the fields appear (the bundle property, i.e. the vocabulary) - or you use the "Entity has field" condition for each field you want to use later on. Quite tedious. Now, the "Entity is of bundle condition" takes away the headache of figuring out what's the bundle of an entity and selecting this as part of a generic "Data comparison". Instead, just go with the "Entity is of bundle" condition, select your entity and bundle (e.g. the content node and "article") and you are good to go.

Event dispatches & task handlers

During the development of fluxkraft we faced the requirement to easily dispatch a bunch of events, depending on some configured events. We realized that this might be a common need for developers who want to support some neat event settings, so I worked together with Sebastien Siemssen (fubhy) to add this feature directly to Rules (actually it's fubhy who wrote all the code). So thanks to this improvements developers may make their event handler implement the RulesEventDispatcherInterface such that the handler gets notified whenever a Rule is configured (or "un-configured") with certain event settings. 
Then, often you'd need to perform some sort of periodic checks in order to invoke the necessary events based upon provided settings, i.e. in one of our use cases we need to check twitter search results and invoke the respective event when new results are available ("polling"). The "Rules scheduler" module already solves executing that kind of periodic tasks, but it has been limited to invoking Rule components only. So the newly added support for Rules scheduler task handlers allows one to define custom task handler classes in order to make use of Rules scheduler's scheduling features to fire up custom code logic based upon a pre-defined schedule - such as checking for new Twitter search results every 15 minutes. Combined, both features enable developers to implement configurable events like "A new tweet matches a search term" in a breeze.

Class based actions/conditions

In the fluxkraft project we've been using modern (object-orient, PHP 5.3, Drupal-8 style) programming practices in order to ease re-using existing PHP libraries and to simplify the update to Drupal 8 - so does the flux Services Integration project implement class based plugins similar to Drupal 8 (more on that another time). While doing that we realized it's quite a pain having to write old-style callback based Rules actions, conditions and events all over the place, and people new to fluxkraft would have to learn both approaches. Fortunately, I figured that Rules' object-oriented design already treats actions and condition plugin implementations as objects, thus supporting class-based actions and conditions in Rules was a question of adding just ~10 lines of code and some small related changes. (In fact, I'd have preferred class based plugins already when I wrote Rules 2.x initially - back in 2009, however unfortunately I felt the community would not be ready / like that approach at that time). Given that and the addition of a simple discover mechanism Rules allows you to provide new events / conditions / actions now :-) (requires 2.4 or later). For more information about that check the change record or look at a working example like the flux Twitter API module.

Not yet into Rules?

We've got nice new features, but you are not into Rules yet? Not a problem, there is a lot of free learning material around (get started with the handbook) or, check our session at Drupalcon Prague and learn Rules in a day.