[ 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.
[ How it works ]
-
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.
-
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.
-
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.
-
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?
Does Burrow replace ManageWP or MainWP for plugin management?
Can I see which sites are running outdated plugins?
Does this work for non-WordPress sites?
How do I track WordPress versions across all my clients' sites?
What about PHP version tracking?
Can Burrow detect when a plugin update causes problems?
How is this different from the WordPress Site Health screen?
[ Related ]
Every client's stack at a glance — versions, plugins, updates
CMS versions, PHP runtimes, plugin inventories, and pending updates across every WordPress, Craft, and Statamic site — heartbeats prove each install is alive.
Keep MainWP. See your whole agency.
Connect MainWP with a read-only API key — every site shows up in Burrow next to GitHub, analytics, and invoices. Nothing to migrate or install on child sites.
ManageWP alternative
ManageWP alternative for agencies with mixed stacks — Burrow sees Craft CMS, GitHub, and form health across the portfolio a WordPress-only tool can't.
[ 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.
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