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.
Comments
Comment #1
dwkitchen CreditAttribution: dwkitchen commentedDamien,
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.
Comment #2
DamienMcKenna@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.
Comment #3
DamienMcKennaFYI this architecture was originally decided back in January 2010: http://drupal.org/node/419644
Comment #4
TR CreditAttribution: TR commentedThis late in the Drupal 7 development cycle, the export format is not going to be changed. In Drupal 8 rules are configuration entities with the normal config import/export behavior, so this issue only pertains to D7.