pronamic / wp-pay-core

Core components for the WordPress payment processing library. This library is used in the WordPress plugin Pronamic Pay: https://www.pronamicpay.com/, but also allows other plugin developers to set up a payment plugin.
https://www.wp-pay.org/
GNU General Public License v3.0
27 stars 3 forks source link

Warn administrators about "Disable Recurring Payments" when `define( 'WP_ENVIRONMENT_TYPE', 'staging' )` is defined #166

Open remcotolsma opened 8 months ago

remcotolsma commented 8 months ago

Related to:

We hebben ook wel overwegen om naar de WP_ENVIRONMENT_TYPE instelling te kijken (https://developer.wordpress.org/apis/wp-config-php/#wp-environment-type). Er is echter geen garantie dat staging omgevingen define( 'WP_ENVIRONMENT_TYPE', 'staging' ); in het WordPres configuratie bestand (wp-config.php) hebben staan.

Internal HelpScout ticket: https://secure.helpscout.net/conversation/2454026625/26654?viewId=1425710

Maybe also relevant:

rvdsteege commented 8 months ago

Could be an improvement, but I'm afraid that WP_ENVIRONMENT_TYPE isn't used that much. I'm guessing that making users aware of the setting on URL changes will be more effective, as suggested in https://github.com/pronamic/wp-pay-core/issues/102.

remcotolsma commented 8 months ago

It is possible that hosting suppliers offer functionalities for setting up staging environments and set define( 'WP_ENVIRONMENT_TYPE', 'staging' ); during this process? Or perhaps there are special WordPress plugins available that help set up copies for staging environments and do this?

rvdsteege commented 8 months ago

Sure, therefore I think it is best to add this in addition to URL changes, so we have most scenarios covered.

remcotolsma commented 2 months ago

We have another customer who is struggling with this:

Als ik een Staging kopie van de site maak, worden deze dubbel afgeschreven. Ik weet inmiddels dat ik daarom deze instelling zo snel mogelijk uit moet zetten: "→ Betalen → Instellingen → Terugkerende betalingen uitschakelen → Schakel het starten van terugkerende betalingen bij gateway uit". Dat geeft door het drukke betalingsverkeer toch het risico dat tijdens het opzetten van de Staging site een aantal dubbele betalingen plaats zullen vinden, ook al ben ik er snel bij. Is er een manier om dit slimmer aan te pakken; kan ik de betalingen bijvoorbeeld tijdelijk pauzeren op de Live site, zodat de Staging kopie ook gepauzeerd staat? En ze dan op de Live site weer door laten lopen, zonder betalingen te missen? Alternatief is de site te backuppen, in de backup de Pronamic plugin te deleten, en de site dan naar Staging te restoren, maar dat is en veel werk, en dan is de site geen exacte kopie van live meer. Hebben jullie een beter idee? Het maken van de Staging site is een geautomatiseerd proces via WPMUDev.

Internal HelpScout ticket: https://secure.helpscout.net/conversation/2628449520/27366?viewId=1425710#thread-7908733788

Should we auto disable recurring payments if a URL change is detected? WooCommerce Subscriptions marks subscriptions as manual if a duplicate site is detected:

https://github.com/Automattic/woocommerce-subscriptions-core/blob/d9609cf9632f9e8d881684bea40cb1a465c11a8a/includes/class-wc-subscription.php#L625-L645

I don't know if WPMUDev defines define( 'WP_ENVIRONMENT_TYPE', 'staging' ); while creating a staging environment. And if so we can't always disable recurring payments on staging environments, you also want to be able to test recurring payments in a staging environment. Should we detect wp_get_environment_type() changes as well?

@rvdsteege Do you perhaps have another brilliant idea?

remcotolsma commented 2 months ago

Maybe the user can add a check in wp-config.php to disable the cron?

define( 'DISABLE_WP_CRON', true );
define( 'WP_ENVIRONMENT_TYPE', 'staging' );
define( 'DISABLE_WP_CRON', ( 'staging' === WP_ENVIRONMENT_TYPE ) );

Or a must use plugin in the staging environment:

\add_action(
    'init',
    function () {
        $is_disabled = (bool) \get_option( 'pronamic_pay_subscriptions_processing_disabled', false );

        if ( $is_disabled ) {
            return;
        }

        \update_option( 'pronamic_pay_subscriptions_processing_disabled', true );
    }
);
rvdsteege commented 2 months ago

Should we auto disable recurring payments if a URL change is detected?

The multilingual compatibility issues are resolved AFAIK, so auto disabling should be possible (otherwise it could be impossible to use subscriptions on some sites). But maybe we are to strict regarding http://https:// changes to auto disable the recurring payments in that case?

I still wouldn't rely on the environment type, as I'm not sure if it's in common/proper use.

Or a must use plugin in the staging environment

That it a nice fix too, instead of updating the option it could also only filter the option value.

remcotolsma commented 2 months ago

The multilingual compatibility issues are resolved AFAIK, so auto disabling should be possible (otherwise it could be impossible to use subscriptions on some sites). But maybe we are to strict regarding http:// → https:// changes to auto disable the recurring payments in that case?

Automatically disabling once a URL change is detected might be a good improvement, let's keep that in mind.

I still wouldn't rely on the environment type, as I'm not sure if it's in common/proper use.

Tools that help set up a staging environment should in my opinion define this where possible:

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

Request to all hosts and development environments

All hosts that support setting up staging environments are requested to set this feature to staging on those staging environments.

_Source: https://make.wordpress.org/core/2020/07/24/new-wp_get_environment_type-function-in-wordpress-5-5/_

Therefore, automatically disabling recurring payments when an environment type change is detected does not seem like a bad idea to me.

Or a must use plugin in the staging environment

That it a nice fix too, instead of updating the option it could also only filter the option value.

Until the must-use plugin accidentally ends up in a production environment and users can’t figure out why recurring payments aren’t working.