I don't believe this is a feature of Commerce currently. #2157789: Test Mode implements a form of it for Commerce Stripe, but it would be great if we could import the model to Commerce architecture and not have each payment method implement it separately.

With Ubercart payment processors, it is possible to lock test mode credentials in settings.php using the $conf array. Since Commerce payment method config is stored in Rules rather than variables, this is no longer a feature of Commerce payments.

The advantage to this was that a development site could lock test creds in, have a copy of the live DB loaded, and start processing test transactions. The lack of this feature means that configuring the payment method(s) is required each time the DB is reloaded (or other special handling is required).

CommentFileSizeAuthor
#17 commerce_payment-allow-payment-settings-override-2280057-17.patch3.09 KBjsacksick
#13 commerce-allow-payment-settings-override-2280057-13.patch2.73 KBjsacksick
#4 commerce-payment_config_override-2280057-4.patch920 bytesmaciej.zgadzaj
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

xurizaemon’s picture

xurizaemon
he/him
Location Ōtepoti, Aotearoa 🏝
CreditAttribution: xurizaemon commented
Issue summary: View changes
xurizaemon’s picture

xurizaemon
he/him
Location Ōtepoti, Aotearoa 🏝
CreditAttribution: xurizaemon commented
meecect’s picture

meecect CreditAttribution: meecect commented

Would love to have something for this.

maciej.zgadzaj’s picture

maciej.zgadzaj CreditAttribution: maciej.zgadzaj commented
FileSize
commerce-payment_config_override-2280057-4.patch920 bytes

Something like this perhaps?

maciej.zgadzaj’s picture

maciej.zgadzaj CreditAttribution: maciej.zgadzaj commented
Status: Active » Needs review
xurizaemon’s picture

xurizaemon
he/him
Location Ōtepoti, Aotearoa 🏝
CreditAttribution: xurizaemon commented

Huh, that's neat maciej!

Since Commerce payment methods use Rules for configuration, what I ended up doing was using Environment module and implementing hook_environment_switch() like this. (Yep, this example is longer than your patch :D)

function example_environment_switch($target_env, $current_env) {
  switch ($target_env) {
  case 'development':
    $devel_rules = array(
      'commerce_payment_commerce_dps_pxpay',
    );
    foreach ($devel_rules as $name) {
      if ($rule_config = rules_config_load($name)) {
        $vars = array(
          '%plugin' => $rule_config->plugin(),
          '%label' => $rule_config->label()
        );
        $rule_config->delete();
        watchdog('example', 'Reverted %plugin %label to defaults', $vars, WATCHDOG_NOTICE);
        drupal_set_message(t('Reverted %plugin %label to defaults.', $vars));
      }
    }
    break;
  }
}

Nice and easy, switching from live to dev is as simple as running up a clone of live and drush env-switch development, and also handles enabling other modules / reconfiguration I want to ensure that test sites don't fire purchase notifications off to the site admins :)

GuGuss’s picture

GuGuss CreditAttribution: GuGuss commented

Hi guys,

The patch from @maciej.zgadzaj works fine. The only issue is that it doesn't show the override in the payment method configuration form, which is tricky since the user can still save the form with different values that will be overriden.

Since I don't think a proper solution will be brought to Commerce core, I've provided a contributed module (which is not generic yet but still gives an idea on how to do it): Commerce Payment Settings Switcher.

Maybe this could help!

joelpittet’s picture

joelpittet
Primary language English
Location Vancouver
CreditAttribution: joelpittet commented

Any reason not to use variable_get()?

https://api.drupal.org/api/drupal/includes!bootstrap.inc/function/variab...

xurizaemon’s picture

xurizaemon
he/him
Location Ōtepoti, Aotearoa 🏝
CreditAttribution: xurizaemon as a volunteer commented

@joelpittet, it would depends how you mean to use it, but a feature to me of Commerce vs Ubercart is that in Commerce I can have multiple processor configurations, switching payment at checkout.

For me this is resolved by using Environment module now, since rule revert in hook_environment_switch() is straightforward.

joelpittet’s picture

joelpittet
Primary language English
Location Vancouver
CreditAttribution: joelpittet commented

@xurizaemon I'm just saying because variable_get() does the global $conf; line for you, and loads variables from the db but also loads overrides from settings.php, it seems like a robust pattern to follow. I think the only reason I'd do it without is for micro optimization to avoid the extra function call, and only if that function gets called more than say 5k times, and even then I'd likely just static the results.

joelpittet’s picture

joelpittet
Primary language English
Location Vancouver
CreditAttribution: joelpittet commented

Or maybe an alter hook would be a better pattern for what you're trying to achieve?

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago at drunomics commented

FYI, there is also https://github.com/GuGuss/commerce_payment_settings_switcher

jsacksick’s picture

jsacksick CreditAttribution: jsacksick commented
FileSize
commerce-allow-payment-settings-override-2280057-13.patch2.73 KB
rszrama’s picture

rszrama CreditAttribution: rszrama at Centarro commented

Open question: should we expand this to support instance level overrides or just keep the current approach of method level overrides?

Needs some sort of documentation before we put it in methinks, just not sure if .api.php is appropriate or not.

maciej.zgadzaj’s picture

maciej.zgadzaj CreditAttribution: maciej.zgadzaj commented

What I did up there was an instance-level override.

I haven't tried GuGuss' or jsacksick's solutions, but having a quick look at them they also seem to be instance-level?

Anyway, I'd say that overriding an instance is what really matters here - after all the payment method definition itself can already be altered using hook_commerce_payment_method_info_alter(), doesn't it?

jsacksick’s picture

jsacksick CreditAttribution: jsacksick commented

I retested the patch from #4, the payment settings are correctly altered (anytime the commerce_payment_method_instance_load() function is called), but the unaltered values are still the ones shown in the Rules configuration admin form.

Open Questions :

  • Do we want the UI to reflect what's currently being used?
  • Should we disable the form fields?

The problem with the approach implemented #13 is that when used in combination with the Commerce Features module, I suspect the feature from being marked as overriden because the rules configuration would actually contain the values that are in the settings.php file.
Thoughts?

jsacksick’s picture

jsacksick CreditAttribution: jsacksick commented
FileSize
commerce_payment-allow-payment-settings-override-2280057-17.patch3.09 KB

Here's a new patch that supports instance level overrides (successfully tested with different instances).
Below a code sample that demonstrates how it works :

$conf['authnet_aim|commerce_payment_authnet_aim'] = array(
  'login' => 'foo',
);

I also made some changes in commerce_payment_entity_load()., we're checking all the rules configuration that reacts to the "Select available payment methods for an order" event.

rszrama’s picture

rszrama CreditAttribution: rszrama at Centarro commented
Issue tags: +release-1.14

  • jsacksick committed f646b4f on 7.x-1.x 
    Issue #2280057 by jsacksick, maciej.zgadzaj, rszrama, GuGuss: Permit...
jsacksick’s picture

jsacksick CreditAttribution: jsacksick commented
Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.