By Greg Nowak. Last updated 28 September 2026.
WordPress.org’s plugin release cooldown is a welcome supply-chain safeguard. It creates time between a developer publishing a release and that release reaching sites through WordPress.org’s update system. What it does not create is confidence that the release will work with your checkout, booking flow, custom code, hosting configuration or internal integrations.
The original Protect the Shire announcement introduced a delay of up to 24 hours. Current instructions for releasing WordPress’s Performance Lab plugins refer to a hold of up to six hours. That changing duration is the important clue: the cooldown is platform infrastructure, not a timetable businesses should build their operations around.
What does the plugin cooldown actually protect?
The delay gives WordPress.org’s moderators, security systems and wider community an opportunity to identify suspicious or defective releases before broad distribution. It can reduce risk across the ecosystem, particularly when a legitimate developer account or established plugin changes hands.
However, WordPress.org cannot see your business context. A technically legitimate update may still change a database query, conflict with another plugin, interrupt an API connection or alter a customer-facing workflow. The cooldown also does not prepare a backup, reproduce your production environment, assign an approver or monitor the site after deployment.
Treat it as one protective layer. Your own update process must handle implementation risk.
Give every plugin an update route
Neither “automatically update everything” nor “manually test everything for a week” is a useful policy. Classify plugins according to the effect of failure, then apply a proportionate release route.
| Plugin class | Examples | Sensible default | Release evidence |
|---|---|---|---|
| Business-critical | Payments, orders, bookings, subscriptions or gated access | Production-like staging, named approval and a monitored release window | Critical journeys pass, logs are reviewed and rollback is ready |
| Operational | Forms, search, publishing tools and system integrations | Relevant staging tests followed by scheduled deployment | Main workflow and connected systems work as expected |
| Low-impact | Replaceable presentation or administrative conveniences | Automatic updates may be appropriate when monitoring is reliable | Current backup, health checks and a known recovery route |
| Custom or modified | Site-specific plugins and inherited agency code | Code review, Plugin Check and staging before production | Buildable source, test notes and a restorable release package |
A security update may require an expedited route. That should mean a short, pre-agreed test set and immediate access to recovery—not an undocumented production change made in a panic.
Build an inventory that explains the business
A plugin list becomes useful when it answers more than “what is installed?” Record the business purpose, owner, supplier, renewal date, data handled, dependent systems, test journey and recovery location for each plugin. Include inactive plugins, must-use plugins, drop-ins and custom packages; otherwise important code can remain outside the process.
WP-CLI provides a practical starting point:
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=csvThe WordPress.org status fields help identify directory plugins that have been closed or have not been updated recently. They do not assess whether a plugin is commercially important or safe in your particular stack.
WordPress has supported declared plugin dependencies since version 6.5 through the Requires Plugins header and the WP_Plugin_Dependencies class. Core can identify declared requirements, dependants, unmet dependencies and circular relationships. Use this information when planning update order, but do not mistake it for a complete architecture map. Custom hooks, shared database assumptions, JavaScript dependencies and external API contracts may remain invisible.
Test the release, recovery and business journey
A useful update check is short enough to follow consistently and specific enough to catch operational failures:
- Triage the change. Read the changelog and any security advisory. Note database migrations, compatibility requirements, changed integrations and dependencies.
- Prepare recovery. Confirm that both the database and files are backed up and that someone can restore them. Keep the previous plugin package available. Replacing plugin files alone may not reverse a database migration.
- Use representative staging. Match the production PHP and WordPress versions, important configuration, data shape and connected services as closely as practical.
- Exercise real journeys. Test the actions that make or support money: payment, booking, form submission, login, search, publishing, scheduled jobs or data exchange. Review PHP, application, browser and integration logs where relevant.
- Release and observe. Record the version, approver and deployment time. Monitor the affected journeys after release; a successful update screen only proves that the installer completed.
Use Plugin Check for code your team controls
For custom plugins and packages your developers can inspect, WordPress.org’s Plugin Check provides a repeatable first pass against directory requirements and common security, performance and accessibility concerns:
wp plugin check my-plugin
wp plugin check /path/to/pluginWP-CLI performs static checks by default. The current documentation gives this additional setup for runtime checks:
wp plugin check my-plugin --require=./wp-content/plugins/plugin-check/cli.phpPlugin Check is not a complete security assessment or an approval button. Retain its findings, investigate them and separate release blockers from planned cleanup and documented exceptions. Manual review and functional testing still matter.
Make ownership explicit before the next urgent update
Plugin failures often occur between suppliers. The host manages infrastructure, the vendor publishes code, the agency understands the implementation, and the client carries the commercial risk. A one-page policy should name who assesses releases, who approves critical deployments, what evidence is retained and who can authorize an emergency rollback.
The WordPress.org cooldown gives the ecosystem a useful pause. Businesses should use that prompt to establish a process that works regardless of whether the delay is 24 hours, six hours or eventually only minutes. If your WordPress estate has grown without clear ownership, Greg can help map dependencies and turn update policy into a routine your internal team and agency partners can follow. Discuss the project with Greg.
Related on GrN.dk
- MCP 2026-07-28 Is an Auth Migration, Not a Version Bump
- Logistics Optimization in 2026: Fix the Flow Before You Buy More Tech
- NGINX Can Read JSON Before Routing—Should It Handle Your AI API?
Need help with this kind of work?
Plan a safer WordPress update process Get in touch with Greg.
