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

“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.

What Burrow changes

Portfolio-wide visibility without 40 logins

Your Burrow dashboard shows every client project. Each project surfaces the connected CMS environment: WordPress core version, installed plugins with version numbers, active theme, PHP version. Craft CMS projects show modules and their versions. Statamic projects show addons.

When the question is “which sites are running WooCommerce below 8.2?” — you have the answer in 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