Description

Adds the ability to effectively shutdown a WordPress application, when the ~WPCOM_VIP_OVERDUE_LOCKOUT~ VIP_OVERDUE_LOCKOUT constant is set and truthy.

Checklist

Please make sure the items below have been covered before requesting a review:

• [x] This change works and has been tested locally (or has an appropriate fallback).
• [x] This change works and has been tested on a Go sandbox.
• [x] This change has relevant unit tests (if applicable).

Steps to Test

1. Check out PR.
2. Edit config/wp-config.php and add the following:

define( 'VIP_OVERDUE_LOCKOUT', true );

3. If testing on a VIP environment, you should see the site-shutdown.html page on all requests.
4. If you are testing on a local environment, nothing should happen. Fake a VIP environment by adding

define('VIP_GO_ENV', true);

to your wp-config.php file

Codecov Report

:exclamation: No coverage uploaded for pull request base (develop@41642f1). Click here to learn what that means. The diff coverage is 0.00%.

:exclamation: Current head e9572be differs from pull request most recent head f8e006d. Consider uploading reports for the commit f8e006d to get more accurate results

@@            Coverage Diff             @@
##             develop    #3431   +/-   ##
==========================================
  Coverage           ?   34.34%           
  Complexity         ?     3553           
==========================================
  Files              ?      216           
  Lines              ?    13803           
  Branches           ?        0           
==========================================
  Hits               ?     4740           
  Misses             ?     9063           
  Partials           ?        0           

Impacted Files	Coverage Δ
lib/utils/class-context.php	0.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Is there anything else that needs to be addressed before we can merge this PR to develop?

@vaurdan I left a few more non-blocking thoughts, I think this is really close.

@vaurdan Let's merge it and try locking out a test site.

Just waiting for the final approval by @Automattic/vip-platform-cantina :)

Tested and works great! @Automattic/vip-platform-cantina any help you can offer to get this across the finish line is greatly appreciated 🙇

Thanks for looking @WPprodigy !

Lets double check that it is cacheable, and ensure the cache is purged when a site is unlocked.

I've looked at Varnish VCL and 4xx is cacheable AFAICT ... the only specific handling we have is for 404, which is cached for 60s, otherwise it should behave the same.

But also, super unlikely there is any movement on this, as these things seem to rarely change

It's easy enough to change in the future if needed, but this code makes the most sense IMO since it's 1) in the 4xx error range, and 2) related to payments (a subtle jab 😄)

Disabling cron means we won't be getting SDS syncs.

Very good point - I think we're safe to leave cron running...it's not really the target of these lockouts. @vaurdan what do you think about leaving cron alone?

Disabling cron means we won't be getting SDS syncs. Having that data fall out of sync isn't super ideal, but atm there's not a means to only run one type of job. (could be a fun future project to have a backup means of syncing to SDS for when cron is turned off / broke)

Great point! I just committed a change to ignore the lockout when running from WP-CLI, cron included.

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
5 Code Smells

No Coverage information
0.0% Duplication