While working through how to handle an issue in Commerce (#1864186: Optional load API keys & settings using variables) 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.


dwkitchen’s picture


Have a look at my presentation at Drupal Camp North West on writing rules in code - it will give you a glimpse in to how to use hook_default_rules_configuration() and hook_default_rules_configuration_alter().

Basically if you want to use hook_default_rules_configuration_alter() you dealing with a rule object, the problem is Rules export does not do export them as objects.

DamienMcKenna’s picture

@dwkitchen: Thanks for the suggestion. I've read through the commerce_eu_vat_ic_default_rules_configuration_alter() code and it proves my point - you shouldn't need to know Rules' internal architecture to make a few small customizations, which in my specific use case is to change one single API key that (due to architectural failings of Commerce) is stored in a Rules definition.

DamienMcKenna’s picture

FYI this architecture was originally decided back in January 2010: http://drupal.org/node/419644