Drupal Association members fund grants that make connections all over the world.
While working through how to handle an issue in Commerce () I realized how Rules handles its exportables and then realized that the exportables are handled completely differently to every other Drupal exportable. Every other Drupal exportable is saved as a nested array or StdClass, and can be readily customized as needed; this allows for easy customization of default configurations used in distributions, etc, and allows for readily reusable configurations. Rules definitions, however, are created during hook_default_rules_configuration() via entity_import(), so trying to customize a mostly undocumented object makes building reusable constructs much more complicated than they need to be.
My recommendation for what should happen:
- The hook_default_rules_configuration() definitions should just contain the definitions, e.g.:
$items['rules_my_authnet'] = array( "LABEL" => "Credit Card (Authorize.Net AIM)", "PLUGIN" => "reaction rule", "TAGS" => array "my rules", ), ...
- Whatever triggers hook_default_rules_configuration should be updated to support the current system but also the new exportables method; this should be simple to do, just check to see what each element is and handle it accordingly.
Advantages to this:
- The exportables would actually be easily customizable via hook_default_rules_configuration_alter(), which they are not today.
- It would be much easier to tailor Rules definitions, as required for Commerce to work, thus make Rules-heavy distributions more customizable without requiring vast amounts of configurations to be left in an overridden state.
Downsides to this:
- Exportables from the newer versions would be incompatible with older versions of Rules.