Optional load API keys & settings using variables [#1864186]

In the olden days of Ubercart it was possible to export almost all settings because so many modules used variables. With Commerce a large amount of the configuration, including the payment gateway API keys, are stored in Rules configurations, and, because it creates an initial configuration, it isn't possible to export this configuration to code without using something (unstable, broken) like Features Override. This means that there's no way to hardcode each site installation to us different settings like it was with Ubercart, e.g. to force a localhost install to use the developer API keys while forcing a production site to always use the production API keys. As a result, it would be really useful if the commerce_authnet module could check for the login and tran_key values in variables.

The goals I'm aiming for are:

All settings exported.
All per-hostname settings (API keys, etc) exported to the settings.php files.

Can anyone help work out if either a) there's already a (stable) way of doing this, or b) where the best location for me to write patches to add hooks would be?

Thanks.

Comments

Comment #1

DamienMcKenna

NH, USA

CreditAttribution: DamienMcKenna commented 11 December 2012 at 21:21

I started looking at maybe extending commerce_authnet_aim_default_settings() to load each value from a setting, but then saw this was only loaded in commerce_authnet_aim_settings_form() thus the overrides would only actually be instantiated when someone overrode the default payment method rule anyway - thus defeating one of my goals.

Comment #2

JulienD CreditAttribution: JulienD commented 12 December 2012 at 10:02

Hi Damien,

I don't know if you found a correct answer but maybe you can do what the import rules form do ?

in a mymodule.rules_defaults.inc file :

function mymodule_default_rules_configuration() {
  $rule_config = rules_import( '{ "commerce_payment_authnet_aim" : {
    "LABEL" : "Authorize.Net AIM - Credit Card",
    "PLUGIN" : "reaction rule",
    "REQUIRES" : [ "commerce_payment" ],
    "ON" : [ "commerce_payment_methods" ],
    "DO" : [
      { "commerce_payment_enable_authnet_aim" : {
          "commerce_order" : [ "commerce-order" ],
          "payment_method" : { "value" : {
              "method_id" : "authnet_aim",
              "settings" : {
                "login" : "login",
                "tran_key" : "key",
                "txn_mode" : "live",
                "txn_type" : "auth_capture",
                "card_types" : {
                  "visa" : "visa",
                  "mastercard" : 0,
                  "amex" : 0,
                  "discover" : 0,
                  "dc" : 0,
                  "dci" : 0,
                  "cb" : 0,
                  "jcb" : 0,
                  "maestro" : 0,
                  "visaelectron" : 0,
                  "laser" : 0,
                  "solo" : 0,
                  "switch" : 0
                },
                "email_customer" : 0,
                "log" : { "response" : "response", "request" : 0 }
              }
            }
          }
        }
      }
    ]
  }}');

  if ($existing_config = rules_config_load($rule_config->name)) {
    $rule_config->id = $existing_config->id;
    unset($rule_config->is_new);
  }
  $rule_config->save();
}

This will override the configuration done in the admin rules form. Maybe you should just add a default configuration if only $existing_config return FALSE ?

Comment #3

DamienMcKenna

NH, USA

CreditAttribution: DamienMcKenna commented 12 December 2012 at 15:31

@JulieD: Thanks.

After some discussions on Twitter this morning I've taken a step back, cloned all of the existing rules definitions and bundled them all into a new feature. So far, so good. However, I'm now stuck with a set of default Rules configurations that can't be readily customized via drupal_alter() (#1864840: Change exports to be nested arrays rather than entity_import'd JSON objects). Argh.

Comment #4

JulienD CreditAttribution: JulienD commented 12 December 2012 at 15:41

Yeah that was an other solution to use Feature. Personally I don't think that's a good solution, we should have a simpler way to set those kind of important settings.

I'll follow your new issue !