toolkit

Scenario · Before you touch a site

Install or troubleshoot a plugin

“Can you install [plugin] for us?” Or: “Something broke after the last update.”

Installing a plugin means adding someone else's code to a site you're responsible for, with permission to do almost anything — the install itself is trivial, and what actually matters is knowing what the site looked like immediately before, so any regression has something real to be measured against. This checks a plugin's own health and known risk before it goes in, and compares the site before and after a change to catch anything the update quietly broke, updating one thing at a time on purpose so a regression can actually be traced.

What to ask for

WordPress inspectorRead-only WordPress site inspector — fetches a URL and reports what the site is running before you touch it: whether it is WordPress at all, the WP and PHP versions, web server and managed host, active theme and child theme, the page builder (Divi 4 vs 5, Elementor, Beaver Builder, WPBakery, Bricks, Oxygen, Gutenberg), the plugins visible from outside, the caching and CDN layer, and externally-visible security notes — into a DETECTED / LIKELY / NOT WORDPRESS verdict plus an HTML report.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.Embed health checkThird-party embed health check — renders the page and asks one question per embed: did it actually paint anything? An Instagram feed, review widget, booking iframe or chat bubble that renders an empty container is invisible in the delivered HTML and visible only to the client.Performance (Core Web Vitals)Core Web Vitals and performance scan for a live page.Before/after checkBefore/after verification for a change to a live page — the safety net for the small edit that doesn't justify a staging round-trip.ScreenshotsCapture multi-device screenshots of any URL from the command line — one PNG per device preset (iPhone → Desktop 4K), headless, on a Playwright core.

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 ↗

Adding a plugin is adding somebody else’s code to a site you are responsible for, with permissions to do anything. The install is trivial; what this procedure buys is knowing what the site looked like before, so a regression has something to be compared against.

  1. Inventory the site first. The WordPress inspection reports the WP and PHP versions, the active theme, the builder and the plugins already visible. Two plugins doing the same job is a common cause of the breakage this ticket is often about.
  2. Check the plugin’s own health before installing it. The plugin and theme audit reports what is outdated, abandoned or carrying known vulnerabilities. An abandoned plugin is a permanent liability and it is cheaper to decline it now than to remove it after it is load-bearing.
  3. Snapshot the pages that matter. Home and the templates the plugin will touch. Skipping this is what makes “something broke after the update” unanswerable.
  4. [manual] Install or update, one plugin at a time. With a backup, and never several at once — the whole reason the troubleshooting half of this ticket is hard is that somebody updated six things and now cannot say which one did it. Publish and purge.
  5. Check the public consequences. Before/after comparison on the snapshotted pages, the embed check if the plugin renders anything, a performance re-measure, and screenshots across devices. Plugins that add front-end components are the usual cause of a layout that was fine yesterday.
  6. Re-run the plugin audit to confirm the version you meant to install is the version present, and that nothing else moved with it.
  7. For the troubleshooting case, work backwards from the same list. The audit tells you what changed version recently; the before/after against an older snapshot tells you what changed on the page. If there is no prior snapshot, that is the finding — and step 3 is why the next one will be answerable.

One at a time, with a backup

Both halves of this scenario — install and troubleshoot — are made expensive by the same thing: batched changes with no recorded before. The procedure is mostly about refusing to batch, which costs minutes now and saves an afternoon of bisecting later.

What this does not cover

What the plugin does inside WordPress. Everything here reads the site from the outside, so a plugin's admin behaviour, its database writes, and its interaction with another plugin are all invisible until they surface on a public page. Whether the plugin is trustworthy enough to run on a medical practice's site is a judgement no check makes — an abandoned plugin with a known vulnerability is reported, but the decision to install it anyway is a human one.

← All scenarios