Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
remcotolsma opened this issue Dec 19, 2023 · 7 comments

Comments

@remcotolsma
Copy link
Member

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
Copy link
Member

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 #102.

@remcotolsma
Copy link
Member Author

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
Copy link
Member

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

@remcotolsma
Copy link
Member Author

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
Copy link
Member Author

remcotolsma commented Jun 18, 2024

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
Copy link
Member

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
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Status: Todo
Development

No branches or pull requests

2 participants