By Greg Nowak. Updated 28 October 2026.
If your WordPress site takes payments, captures enquiries or manages bookings, a plugin update is a business change. The useful question is whether customers can still complete those tasks afterwards, and how quickly you can recover if something breaks.
WordPress.org’s plugin cooldown adds protection before releases reach installed sites. It deserves a place in your risk assessment. You still need someone responsible for testing the workflows your business depends on, approving important changes and watching the site after deployment.
What the WordPress.org plugin cooldown now does
The June 2026 Protect The Shire announcement introduced a temporary delay of up to 24 hours before plugin releases reached sites through automatic updates.
The Plugins Team’s September update describes a six-hour cooldown before distribution through the WordPress.org update API, including dashboard one-click updates. During that window, several AI models and Jetpack Scan analyse release changes. Releases receiving a high risk score are blocked automatically, and plugin committers receive the findings.
That is a meaningful security gate. It cannot establish whether a release works with your checkout customisations, booking rules or accounting connection. Also check how each plugin receives updates: premium vendor packages and custom deployments need their own assessment.
Choose an update route by business impact
A payment extension and a replaceable dashboard convenience should not require the same approval process. Start with the consequences of failure, then agree how much evidence each release needs.
| Plugin role | Recommended route | Evidence before release |
|---|---|---|
| Revenue or access: payments, bookings, subscriptions | Representative staging, named approval and a monitored release window | Relevant customer journeys pass; recovery is ready |
| Operations: forms, publishing, search, integrations | Targeted workflow tests and scheduled deployment | Submission, delivery and connected systems checked |
| Low-impact, easily replaced features | Consider automatic updates with reliable monitoring | Recoverable backup and checks that detect failure |
| Custom or locally modified code | Developer review, automated checks and staging | Reviewed changes, test notes and a restorable package |
Give security fixes an expedited route. Assess the advisory and your exposure promptly, run the essential checks and have recovery available. Avoid adding a routine waiting period when an urgent fix requires action.
Turn the plugin list into an ownership record
For each plugin, record its business purpose, responsible person, supplier, update channel, dependent systems and test journey. Include licence renewals and recovery instructions where relevant. This gives your agency and internal team a shared reference when an urgent release arrives.
Your developer can start with these read-only commands, run from the WordPress installation directory using WP-CLI’s plugin list command:
wp plugin list --fields=name,status,version,update,update_version,auto_update --format=csv
wp plugin list --fields=name,wporg_status,wporg_last_updated --format=csv
wp plugin list --status=must-use --format=csv
wp plugin list --status=dropin --format=csvKeep inactive plugins in the review. Must-use plugins and drop-ins also belong in the inventory. Directory status and last-update fields provide useful signals; blank values for private packages do not establish a problem.
WordPress has supported declared dependencies through the Requires Plugins header and WP_Plugin_Dependencies since version 6.5. Use those declarations as a starting point. Your architecture record should also capture relationships involving custom hooks, shared data and external APIs.
Test the customer journey and the recovery route
Keep the release checklist short enough to use consistently. Every critical update should answer these five questions:
- What changes? Read the changelog and any security advisory. Identify database migrations, new PHP or WordPress requirements, dependency changes and altered integration behaviour.
- Can we recover? Confirm that database and file backups are available, and that someone has verified the restore procedure. Keep the previous plugin package. Replacing files may not undo database changes.
- Does staging represent production? Match important versions, configuration and data patterns. Use payment sandboxes and controlled email delivery so tests cannot charge customers or send unintended messages.
- Does the work still complete? Follow an enquiry through to delivery, a booking through confirmation, or a test payment through order creation. Check relevant logs, webhooks and scheduled tasks. Opening the homepage proves very little about these workflows.
- Who watches after deployment? Record the version, deployment time and approver. Assign someone to check affected journeys and delayed processes, with clear conditions for stopping or reversing the release.
For a live shop, recovery needs particular care. Restoring yesterday’s database can discard today’s orders. Agree how you will preserve or reconcile new transactions before treating a full restore as the default response.
Keep Plugin Check in the developer workflow
For code your team maintains, Plugin Check adds repeatable checks for directory requirements and common development concerns. Install and activate it in a development or staging environment, then run:
wp plugin check my-plugin
wp plugin check /path/to/pluginReplace the example name or path with your plugin. WP-CLI runs static checks by default. The documented workaround for including runtime checks is:
wp plugin check my-plugin --require=./wp-content/plugins/plugin-check/cli.phpAdjust the path for your installation. Review the findings alongside functional tests and manual code review; a clean report cannot certify the whole site.
Make responsibility clear before the next urgent release
A useful update policy fits on one page: who assesses releases, who approves critical changes, who deploys, who monitors and who can authorise recovery. Give each role a named owner and a backup person. Ensure they have the access needed to act.
If responsibility is spread across your host, agency and internal team, Greg can help build the plugin inventory, agree practical release routes and coordinate the handovers. Discuss your WordPress update process with Greg.
Related on GrN.dk
- WordPress Forced an Emergency Update. Did All Your Sites Take It?
- WordPress Security Updates Need an Ops Runbook
- Cloudflare Page Rules Debt: How Old Rules Break Business Websites
Need help with this kind of work?
Discuss your WordPress update process with Greg Get in touch with Greg.
