[ Use case ]

Track WordPress versions, plugins, and PHP across every client site

See which of your 40 WordPress sites run PHP 8.3, which have outdated WooCommerce, and which need core updates — one portfolio view, no logging into admin panels.

Built on System

[ How it works ]

  1. Connect CMS plugins across your portfolio

    Install the Burrow WordPress plugin on each managed site. Install the Craft CMS or Statamic plugin where applicable. Each plugin reports CMS version, active plugins/modules, theme versions, and PHP environment details — all scoped to the client's Burrow project.

  2. See your portfolio inventory at a glance

    The System channel's Site Health list shows every site's CMS version with its pending upgrade beside it, PHP runtime, plugin count with the outdated tally, and last-scan time — sortable by what needs updates. No logging into 40 separate WordPress admin panels.

  3. Track updates as they happen

    When a plugin updates, a theme changes, or a CMS core version bumps, Burrow captures the event in the client timeline. See exactly when the update happened, what changed, and — because deploys and form data are in the same timeline — whether the update caused any downstream issues.

  4. Correlate updates with operational impact

    Plugin update at 3:47pm. Form submissions drop to zero at 3:48pm. Burrow shows both events in the same timeline. That correlation is invisible when your CMS management tool and your form monitoring tool are separate systems. In Burrow, it's automatic.

“Which of our 40 sites is still running WooCommerce 7.x?”

That question should take 5 seconds to answer. In practice, it takes 40 WordPress admin logins. Or opening ManageWP and hoping it has current data. Or checking a spreadsheet someone updated last month — maybe.

Version tracking across a large portfolio is one of those problems that scales silently. At 5 clients, you know every plugin version from memory. At 15, you have a general sense. At 40+, you’re guessing. And guessing breaks when:

  • A PHP deprecation affects sites running older versions of a specific plugin
  • A WordPress core update introduces a known conflict with WooCommerce below version 8.2
  • A Craft CMS security patch requires immediate attention on all Craft installations
  • A theme framework releases a breaking change and you need to know which clients are affected
  • A hosting provider announces end-of-life for PHP 8.1 and you need to audit your portfolio

Each of these scenarios requires answering: which sites are affected? Without a centralized inventory, the answer involves logging into every admin panel, checking every ManageWP dashboard, and hoping you didn’t miss one.

The spreadsheet that’s always wrong

Most agencies handle version tracking with a spreadsheet. Someone updates it after each batch of maintenance work. The spreadsheet is accurate for about a week. Then:

  • A developer applies an emergency plugin update and forgets to log it
  • A client’s hosting provider auto-updates PHP without notifying anyone
  • ManageWP auto-updates a batch of plugins overnight
  • A developer installs a new plugin during a feature build and never adds it to the tracker

By the end of the month, the spreadsheet diverges from reality. By the end of the quarter, it’s a liability. You’re making maintenance decisions based on data that’s 3-8 weeks stale.

The inventory should update itself. Every plugin install, every version bump, every theme change — captured automatically the moment it happens, attributed to the right client project, visible alongside the other operational signals that tell you whether the change caused problems. Two mechanics keep it honest: every install sends heartbeat pings, so a site that stops reporting is itself a signal, and any site can be re-scanned on demand when you need numbers fresher than the last snapshot.

What Burrow changes

Portfolio-wide visibility without 40 logins

The System channel’s Site Health list shows every site with its CMS version and the pending upgrade beside it (craft 5.9.22 → 5.10.11), the PHP runtime, the plugin count with how many are outdated, and when it was last scanned — sortable by what needs updates. Craft CMS projects show modules and their versions. Statamic projects show addons.

When the question is “which sites are running WooCommerce below 8.2?” — the Plugin Inventory answers it as one row: install counts, the exact versions in the wild, and how many installs need the update. Seconds, not hours.

Update events in the client timeline

Version tracking isn’t just a snapshot. It’s a timeline. When a plugin updates — whether through ManageWP’s bulk updater, a developer’s manual action, or WordPress auto-updates — the event appears in the client’s Burrow project:

source: "wordpress"  |  type: "plugin.updated"  |  projectId: "client_acme"
payload: { plugin: "woocommerce", from: "7.9.0", to: "8.2.1" }

That event lives alongside form submissions, GitHub deploys, and uptime signals. The update is contextualized — not isolated in a maintenance tool’s log.

Correlation that catches breaking updates

Here’s where it gets valuable. The plugin update event at 3:47pm. Form submissions drop to zero at 3:48pm. Both events in the same timeline.

Without Burrow, those signals live in different tools. ManageWP shows the update happened. Your form monitoring tool (if you have one) might eventually flag the volume drop. But nobody connects the two automatically. The developer spends 20 minutes investigating before finding the correlation manually.

With Burrow, the correlation is visible immediately. Scout flags the pattern: “Plugin update coincided with form volume drop — investigate.” The developer checks the timeline, sees the WooCommerce update triggered a CF7 conflict, and rolls back. Total investigation time: 3 minutes.

The maintenance conversation gets easier

Client retainer reviews often include a maintenance summary: “We updated X plugins, applied Y security patches, maintained Z versions.” Most agencies assemble that summary manually — checking update logs, referencing ticket history, and reconstructing what happened from memory.

Burrow’s timeline is the maintenance record. Every update event is timestamped and attributed. The monthly digest includes:

CMS activity: 12 plugin updates applied (including WooCommerce 8.1 → 8.2.1 and Gravity Forms security patch). WordPress core updated to 6.5. PHP version: 8.3. Theme: Astra 4.6.1. All updates verified — no operational impact detected.

That paragraph compiled itself from real events. Your AM reviews it, confirms accuracy, and includes it in the client digest. No manual log checking. No stale spreadsheet.

Beyond WordPress: multi-CMS portfolio management

WordPress gets the most attention because it’s the most common platform in agency portfolios. But Burrow tracks versions across every supported CMS:

  • WordPress: Core version, plugin versions, theme version, PHP version
  • Craft CMS: Core version, module versions, PHP version
  • Statamic: Core version, addon versions, PHP version
  • ExpressionEngine: Core version, addon versions, PHP version

For agencies running mixed CMS portfolios — 25 WordPress sites, 8 Craft CMS sites, 5 Statamic projects — the inventory spans platforms. One dashboard shows versions across every CMS. The question “which sites need attention?” has a cross-platform answer.

Getting started

Install the Burrow CMS plugin on your managed sites. WordPress first — it’s the highest-volume platform for most agencies. Plugin versions, theme versions, PHP versions, and CMS core versions start reporting to Burrow automatically. Add Craft CMS, Statamic, and ExpressionEngine plugins as needed.

Within a day, your portfolio inventory is current, self-maintaining, and contextualized alongside every other operational signal in each client project.

WordPress integration | Craft CMS integration | Multi-CMS agencies | Compare with ManageWP | Compare with MainWP

Frequently asked questions

How does Burrow track CMS versions across multiple sites?
The Burrow CMS plugins (WordPress, Craft CMS, Statamic, ExpressionEngine) report environment details — CMS core version, installed plugins and their versions, active themes, and PHP version — to the Burrow project. Each site's data is scoped to its client project, giving your agency dashboard a portfolio-wide inventory.
Does Burrow replace ManageWP or MainWP for plugin management?
No. ManageWP and MainWP handle the mechanics — bulk plugin updates, automated backups, security scanning. Burrow is the visibility layer above them. It shows you the version inventory and correlates update events with operational signals (form health, checkout activity, uptime). Use ManageWP to apply updates. Use Burrow to see what happened after.
Can I see which sites are running outdated plugins?
Yes. The System channel's Plugin Inventory rolls up every plugin across every site — install counts, the exact versions in the wild, and how many installs need an update. The Site Health list flags each site as up to date or needing updates, sortable by what needs attention. Scout monitors for version-related anomalies and can flag sites that haven't received expected updates.
Does this work for non-WordPress sites?
Burrow has first-class plugins for WordPress, Craft CMS, Statamic, and ExpressionEngine. Each captures platform-specific version and environment data. For Shopify, version tracking is inherent to the platform (Shopify manages its own updates). For custom applications, send environment metadata through the Burrow API.
How do I track WordPress versions across all my clients' sites?
Install the Burrow WordPress plugin on each managed site. Your Burrow dashboard shows every client project with their WordPress core version, installed plugin versions, active theme, and PHP version. When any of those change, the update event appears in the client timeline alongside deploy history, form submissions, and other operational signals.
What about PHP version tracking?
The WordPress plugin reports the server's PHP version to Burrow. This matters when PHP 8.x compatibility breaks older plugins or when hosting providers deprecate older versions. See which clients are running PHP 8.1, which are on 8.3, and plan migration conversations accordingly.
Can Burrow detect when a plugin update causes problems?
Burrow captures the update event and correlates it with other signals in the same timeline. If form submissions drop to zero immediately after a plugin update, both events appear side by side. Scout can flag this pattern automatically. The connection between 'what changed' and 'what broke' is visible without manual investigation.
How is this different from the WordPress Site Health screen?
WordPress Site Health shows one site's status. Burrow shows 40 sites' status in one dashboard. And it adds operational context — the Site Health screen doesn't show that the CF7 update that happened yesterday also stopped form submissions. Burrow's timeline does.

[ Free Playbook ]

How to sell website care plans clients love

The exact playbook behind $20k MRR in maintenance and support packages — packaging, pricing, and the objection-by-objection sales pitch, plus a free proposal template.

Read the guide

15 min read · Free, no email required

Your agency's work deserves to be seen.

Start a 30-day free trial — no credit card required. Connect your first sources and see every client signal in one timeline.

Self-funded · Independent · Built for the long term