WordPress.org’s Plugin Cooldown Calls for a Real Update Process

Illustrated infographic summarizing: WordPress.org's 24-Hour Plugin Cooldown Calls for Real Review

By Greg Nowak. Last updated 2026-08-28.

WordPress.org’s plugin release cooldown is useful, but it is easy to misunderstand. The delay gives the directory’s reviewers and security systems time to inspect a release before it reaches sites through automatic updates. It does not review the release against your checkout, membership workflow, custom code or hosting setup.

When WordPress.org announced the Protect the Shire initiative on June 5, 2026, releases could be held for up to 24 hours. Current official release instructions for the Performance Lab plugins describe a hold of up to six hours. The duration may continue to change as the system develops, so businesses should not build their process around a particular number of hours. The lasting lesson is that updates deserve an operational owner.

What the cooldown does—and what it cannot do

The cooldown adds a platform-level safety buffer between a developer publishing a release and WordPress.org distributing it through auto-updates. That can create an opportunity to detect suspicious or defective code before it reaches a large number of sites.

It cannot tell whether an otherwise legitimate update breaks your particular implementation. WordPress.org does not know that a plugin powers revenue, feeds an ERP system, changes a staff workflow or depends on an undocumented customization. It also does not provide your backup, test the release in staging or decide who should approve deployment.

Treat the cooldown as one layer in the supply chain—not as a replacement for release management.

Give each plugin an update route

A blanket rule such as “enable every auto-update” or “test every patch for a week” is rarely practical. Classify plugins by business impact, then give each class a proportionate route. The classification should reflect what happens when the plugin fails, not how famous or technically complicated it appears.

Plugin class	Typical role	Default update route	Minimum evidence
Business-critical	Payments, orders, bookings or gated access	Production-like staging, named approval and monitored release window	Successful critical journeys, clean logs and tested rollback
Operational	Forms, search, editorial tools or integrations	Staging test before scheduled deployment	Relevant workflow test and integration check
Low-impact	Replaceable or non-essential presentation features	Auto-update may be reasonable	Recent backup, health monitoring and a known rollback path
Custom or modified	Site-specific plugins and inherited agency code	Code review, Plugin Check and staging	Buildable source, test notes and a restorable release package

A practical update matrix: spend the most review time where failure would interrupt revenue, service or staff work.

A security release may need an expedited version of this route, particularly when exploitation is reported. Expedited should mean a smaller, pre-agreed test set and an available rollback—not an unrecorded production update made in a panic.

Map the stack, not just the plugin count

Start with an inventory that includes active, inactive, must-use and custom plugins. WP-CLI can provide a useful baseline:

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

Add the information WordPress cannot supply: business purpose, internal owner, vendor, renewal date, data handled, relevant test journey and rollback location. Inactive plugins also need a decision. If they are not retained for a documented reason, removing them reduces maintenance ambiguity and exposed code.

WordPress has supported declared plugin dependencies since version 6.5 through the Requires Plugins header and the WP_Plugin_Dependencies class. Core can identify required plugins, active dependants, unmet requirements and circular relationships. Use that information when choosing update order.

Declared dependencies are only part of the map. They will not reveal every custom hook, shared JavaScript handle, database assumption or external API contract. Agency handover notes and developer knowledge still matter. A plugin inventory becomes operationally useful only when it records those less visible relationships.

Use Plugin Check where you control the code

For custom plugins and packages your team can inspect, WordPress.org’s Plugin Check provides a repeatable first pass. It tests directory requirements and flags concerns involving areas such as security, performance and accessibility. Run it in development or staging through the admin interface or WP-CLI:

wp plugin check my-plugin
wp plugin check /path/to/plugin

WP-CLI runs static checks by default. The current Plugin Check documentation describes an additional --require setup for runtime checks:

wp plugin check my-plugin --require=./wp-content/plugins/plugin-check/cli.php

Plugin Check is not a vulnerability scanner or a release approval button. Its own documentation says it does not replace manual review. Findings should be triaged into release blockers, planned cleanup and explained exceptions. Any AI-assisted false-positive analysis should remain advisory; the original findings are retained for human review.

Use the buffer to run a five-step release check

Triage the release. Read the changelog and vendor advisory. Identify security relevance, changed integrations, database migrations and declared dependencies.
Prepare recovery. Confirm that the backup is recent and restorable. Keep the previous plugin package and document who can perform the rollback.
Test the right environment. Use staging that resembles production in PHP version, WordPress version, configuration and important integrations.
Exercise business journeys. Test the actions customers and staff depend on: payment, form submission, login, search, publishing, scheduled jobs and data exchange as applicable. Review application and browser logs.
Release and observe. Record the approver, version and deployment time. Monitor the relevant journeys after release instead of treating a successful update screen as proof that the site works.

Make ownership explicit

For an agency, the awkward failures often occur between responsibilities: the host maintains infrastructure, the vendor publishes code, the agency knows the implementation and the client owns the commercial risk. A short update policy should name the person who classifies releases, the person who approves critical changes, the evidence to retain and the emergency rule used outside normal hours.

That is the real opportunity behind WordPress.org’s cooldown. It gives teams a prompt to replace hopeful updating with a lightweight, repeatable process. If your plugin estate has grown without clear ownership, Greg can help map the dependencies, define sensible update routes and turn the procedure into work that an internal or agency team can actually follow. Talk through the project with Greg.

Related on GrN.dk

Need help with this kind of work?

Plan a safer WordPress update process Get in touch with Greg.

Sources

Last modified

2026-08-28