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).
Comment | File | Size | Author |
---|---|---|---|
#17 | commerce_payment-allow-payment-settings-override-2280057-17.patch | 3.09 KB | jsacksick |
| |||
#13 | commerce-allow-payment-settings-override-2280057-13.patch | 2.73 KB | jsacksick |
| |||
#4 | commerce-payment_config_override-2280057-4.patch | 920 bytes | maciej.zgadzaj |
Comments
Comment #1
xurizaemonComment #2
xurizaemonComment #3
meecect CreditAttribution: meecect commentedWould love to have something for this.
Comment #4
maciej.zgadzaj CreditAttribution: maciej.zgadzaj commentedSomething like this perhaps?
Comment #5
maciej.zgadzaj CreditAttribution: maciej.zgadzaj commentedComment #6
xurizaemonHuh, 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)
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 :)Comment #7
GuGuss CreditAttribution: GuGuss commentedHi 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!
Comment #8
joelpittetAny reason not to use
variable_get()
?https://api.drupal.org/api/drupal/includes!bootstrap.inc/function/variab...
Comment #9
xurizaemon@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.
Comment #10
joelpittet@xurizaemon I'm just saying because
variable_get()
does theglobal $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.Comment #11
joelpittetOr maybe an alter hook would be a better pattern for what you're trying to achieve?
Comment #12
fagoFYI, there is also https://github.com/GuGuss/commerce_payment_settings_switcher
Comment #13
jsacksick CreditAttribution: jsacksick commentedComment #14
rszrama CreditAttribution: rszrama at Centarro commentedOpen 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.
Comment #15
maciej.zgadzaj CreditAttribution: maciej.zgadzaj commentedWhat 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?Comment #16
jsacksick CreditAttribution: jsacksick commentedI 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 :
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?
Comment #17
jsacksick CreditAttribution: jsacksick commentedHere's a new patch that supports instance level overrides (successfully tested with different instances).
Below a code sample that demonstrates how it works :
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.Comment #18
rszrama CreditAttribution: rszrama at Centarro commentedComment #20
jsacksick CreditAttribution: jsacksick commented