toolkit

Scenario · Before you touch a site

Is it safe to update?

“Is it safe to update?” Asked before running WordPress core, plugin or theme updates.

"Is it safe to update" doesn't have one clean answer, but "what are we actually running, and how far behind is it" is a fact this can hand over before anyone touches anything — which is a cheaper way to find out than discovering it live. This reports exactly what's outdated, abandoned, or carrying a known vulnerability, as evidence for the decision to update — it can't predict whether an update will break something, and the call on timing and rollback still belongs to a person.

What to ask for

WP plugins & themeWordPress plugin and theme audit — takes the plugins and active theme a site exposes and checks each against the WordPress.org directory for freshness: outdated (behind latest), abandoned (long since updated), and lagging the current WordPress version.

See it work

A real run of WP plugins & theme:

WP plugins & theme · wp-plugins-and-theme — https://toolkit-tests.pages.dev/wp/wp-gold.html
  detecting plugins + theme via wordpress-inspector …
  auditing 3 item(s) against the WordPress.org directory + WPScan …

FAIL — https://toolkit-tests.pages.dev/wp/wp-gold.html
  3 audited · 3 outdated · 0 abandoned · 2 vulnerable
  FAIL   contact-form-7 (plugin) — outdated: 5.9.2 → 6.1.7 (major); 2 known vulnerabilities — fixed in 6.0.6
  FAIL   wordpress-seo (plugin) — outdated: 22.0 → 28.4 (major); 6 known vulnerabilities — fixed in 28.1
  REVIEW twentytwentyfour (theme) — outdated: 1.1 → 1.6 (minor)

  playbook: local fallback

  report: ./out/wp-plugins-and-theme-wp-plugins-and-theme.html
  text:   ./out/wp-plugins-and-theme-wp-plugins-and-theme.txt

The captured report, exactly as a run hands it to a client —open the full report ↗

“Is it safe” has no single answer, but “what are we running, and how far behind is it” is a fact this check can hand you before anyone touches anything — cheaper than finding out live, and the right first step whether the plan is to update one plugin or the whole stack.

  1. Run the plugin-and-theme inventory against the public site and keep the report.
  2. Read the outdated, abandoned and known-vulnerable findings alongside the site’s hosting context — an abandoned plugin on a site slated for a rebuild next quarter is a different priority than one on a site that will run for years.
  3. [manual] Decide the update window and the rollback plan outside this check — it is read-only evidence for that decision, never permission to update, and it cannot predict a compatibility break.
  4. [manual] After the approved update runs, rerun the inventory and record the resulting versions and whatever risk remains.

Evidence for the decision, not the decision itself

The known-vulnerable flag is the one that should move first regardless of anything else on the list — but which plugin gets updated when, and in what order, is a judgement about the specific site that this check deliberately leaves to the person running it.

What this does not cover

Whether applying the update will break the site. Read-only, no login: it lists what is outdated, abandoned or known-vulnerable, which is the input to that decision rather than the decision itself — a compatibility break is a fact only the update itself can surface.

← All scenarios