Drupal Rules as an automation language

The Drupal Rules module lets you specify conditions plus actions to be performed when the conditions occur. A few small additions to the Rules options would let you use Rules as a formal automation or scripting language.

What is missing? What would be the most useful extensions to rules? Here are ideas for Rules in Drupal 8.

Rules to run rules

Rule A could run rule B. Rule be could work the same as a function in PHP or the way a dependent function works in jQuery. How could the current rules work as a function and what would be the benefit?

Rule B would help rule A by reducing the size of rule A. If rule A performs the same action on two sets of data, rule A has to define the action twice or use an external action. Rule B could be the action and could be used twice in rule A, each time with different data.

Sets of data

Our example rule A could select a set of data then feed each item into rule B. Rule A might select all content of a certain type then feed the content into rule B. Rule B might expect one content node and perform a specific action on the node but not contain and node selection conditions.

Rule B might react to published nodes over a certain age and archive them. The rule could have an indicator to specify the rule should not run by itself and should only run when called by another rule. Rule A might select only one content type then feed that content type to rule B for archiving.

Rules needs a way to let rule A select a set of content then apply rule B to each item in the set. The process would be similar to using .each() in jQuery or foreach() in PHP.

Passing parameters

Rule B can accept parameters through tokens and the tokens could be extended. Tokens have the format [node:title]. The [node: part could be [each:] followed by the set you want to use.

Returning results

Functions can return a single result. Functions in PHP can work on objects and change them. Functions in jQuery can select anything and change anything it can select. Rules can select many things, similar to jQuery, and the jQuery programming model may be the best choice for Rules.

Following the jQuery model, rule B would receive a parameter [this] and work on it. At the end of rule B,

jQuery as a model

jQuery has a good processing model to follow when expanding Rules to create a language. Before Drupal, I wrote some automation languages with at least two working something like rules the way I describe here. One had a model similar to PHP 5 OOP, one had a model similar to jQuery, and some had models similar to text scripts. They were written before either PHP 5 or jQuery. Of all the variations, I currently like jQuery because jQuery works well in an environment similar to automation, jQuery is easy to teach, and many of the automation users will have jQuery experience.

Although the language would not be coded anything like jQuery, the selection options and the returning of the processed object would be an excellent start.

Update elements

Rules, Views, and all the other similar Drupal programming languages built through a user interface suffer from one problem, you cannot update an element, you have to write a PHP function to perform the work. Simple updates could be added to Rules. Simple examples include switching binary elements on, off, or to the opposite state. Changing a node from unpublished to published is an example.

The Rules selection process lets you use a really complicated set of rules to decide which items need the change. Often the change is simple and could be coded similar to the way a single line of Rules selection is coded. Applying a 10 percent price increase at the end of the month could be a rule with no PHP code required.