Caching and page speedPro
Hummingbird MCP: clearing WPMU DEV's page cache from an agent
The Hummingbird MCP route in GoBuildWP purges through Hummingbird's page-cache module directly, because the hook that sounds like a purge, wphb_clear_page_cache, turned out to be an event Hummingbird fires rather than one it listens for. Settings are reachable as wphb_ and wphb- option rows by name only, since WPMU DEV normally configures the plugin through its own config API.
hummingbird- Layer
- page
- Declared purge scopes
all- Shared keys
- None
- Detected by
- plugin folder hummingbird-performance
Installed class, method or listener checks and per-layer results determine whether a purge ran. Neither a declaration nor a returned ran flag proves public freshness.
- Edition
- Pro
- Abilities
- 16
- Requires
- WordPress 6.9+, PHP 8.0+
Before changing cache settings, inspect captured drivers and not_captured. After reverting, inspect restored, deleted, not_restored, verified and purged_layers. Use a separate cache-purge result when you need details for each layer. Storage verification checks captured values; it does not establish functional recovery or public freshness. Revert may overwrite later settings, and vendor configuration regeneration or a re-save can still be required.
Check each measurement run’s fetched_via before treating it as public-path evidence. cache-verify-in-browser supplies checks and does not operate a browser. Automatic purge coalesces targets within the request and runs on shutdown; it is not necessarily one immediate flush per call. Verify generated files, object/page/edge caches and actual visitor behavior separately.
Abilities
How the cache abilities reach Hummingbird
| Ability | What it does here | Undo and limits |
|---|---|---|
cache-check-setup | Lists hummingbird as a page layer. purge_scopes.all turns true only when the Utils accessor and the module's clear_cache method both resolve on the installed version. | url and post scopes are always false for this driver; there is no targeted entry. |
cache-purgecache-warm | Any purge ends in the page-cache module's clear_cache(), and the layer result shows the resolved chain as its entry point. Warming then requests pages so Hummingbird can store them again. | Only the page-cache module is cleared. Minified asset output and the Gravatar cache are not named in GoBuildWP's purge map. |
cache-get-settingscache-set-native | Read the wphb_ and wphb- rows; write one by exact name with confirm=true once it has been read back. | A raw row write bypasses whatever the WPMU DEV config API would validate or apply on the plugin's behalf. |
cache-set-settingscache-apply-presetcache-list-presets | Report everything unsupported; no preset touches Hummingbird. | Hummingbird's own configs, applied from its dashboard, fill that role. |
cache-list-actionscache-run-action | Declare no Hummingbird action. | Anything beyond a page-cache clear happens in Hummingbird's own screens. |
cache-begin-experimentcache-revert-experimentrollback-change | Capture and restore the wphb rows; a revert reports each storage and purge outcome; storage verification does not prove functional recovery or edge freshness. | If Hummingbird derives files or server rules from a setting, restoring the row may not undo that effect until you save once in Hummingbird. |
cache-measure-pagecache-verify-in-browser | Measure delivery and check for broken scripts or shifted layout after a minify or combine row changes. | Run the browser checks before celebrating a faster number: a quicker page with a dead script is a regression. |
Reference: /docs/reference/cache
Shared cache module; do not add this count across drivers. Edition and effect labels describe the source catalogue. The installed schema, dependency versions, licence, WordPress capability, safety profile and per-ability policy determine availability; labels alone do not prove confirmation or recovery.
Data model
Modules, a config API, and a set of wphb rows
Hummingbird is organised in modules: page caching, browser caching, Gravatar caching, GZIP, asset optimisation with minify and combine, and Redis object-cache integration, with critical CSS, delayed JavaScript and a CDN in the Pro edition, plus Cloudflare and APO integration. Configuration normally flows through the WPMU DEV config API, which is why GoBuildWP maps none of it onto its shared vocabulary.
Stored locally is a family of options named with wphb_ or wphb- at the front. GoBuildWP's generic driver lists all of them, subject to the same size cap as any native dump, with native_complete saying whether everything fitted, and it writes one exact row name at a time.
Purging is the one place GoBuildWP reaches into Hummingbird's code instead of its rows. It resolves Hummingbird\Core\Utils::get_module('page_cache') and calls clear_cache() on the module that comes back, the same path the plugin's own code uses to reach that module.
Option name prefixes
wphb_wphb-
Configuration normally goes through the WPMU DEV config API rather than plain options, so nothing is mapped. Its option rows are readable and writable by name.
Other plugins
Hummingbird next to other performance plugins
- Hummingbird's FAQ says it works alongside WP Rocket or W3 Total Cache if each overlapping feature is active in only one of them. With both installed, cache-get-settings without a driver reads the mapped plugin, so name hummingbird to see its rows.
- NitroPack lists Hummingbird among the plugins it cannot run beside when both cache or optimise pages.
- WooCommerce cart, account and checkout pages are excluded from Hummingbird's cache automatically, per its listing, so a full clear does not change how those pages behave.
Worked example
Set a restore point, then clear and check
Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.
The experiment records captured storage and the purge reports its layer outcome. Check the page's expected content before calling it fresh. If a later change breaks it, use cache-revert-experiment and inspect restored, deleted, not_restored, verified and purged_layers, then check the page again. If purge_scopes.all is false, inspect the installed accessor, version and configuration; clear from the vendor dashboard when appropriate.
After write or revert, perform any required native re-save and generated-rule check. Inspect expected content and clear the asset cache separately when minified CSS or JS remains stale.
Before we try anything on Hummingbird, take a snapshot, then clear its page cache and check the home page.
wppilot/cache-begin-experimentWriteCaptures every wphb_ and wphb- row and returns an experiment_id to quote later.
wppilot/cache-get-settingsReadDriver hummingbird with include_native true lists the rows by name so the user can say which one to change.
wppilot/cache-purgeWriteClears the page-cache module through its accessor chain and reports that chain as the entry point.
wppilot/cache-verify-in-browserReadHands back browser checks and PageSpeed report links for the home page.
A suggested sequence from the ability reference, not a recorded run.
Hummingbird troubleshooting
New HTML, old styles: the Hummingbird stale-asset pattern
A common report after an agent clears Hummingbird is that the text on a page changed but the styling did not, or a fixed script still misbehaves. That fits how the purge is built. GoBuildWP asks Hummingbird's page-cache module to clear, so the next request to WordPress can build the HTML again (a CDN or edge cache in front of the site may still hold its own copy), but asset optimisation output is a separate store that this purge does not name. If the change was to a stylesheet or script that Hummingbird minifies or combines, the fresh page can still point at the old optimised file.
The agent can narrow it down before anyone opens Hummingbird. cache-measure-page shows whether the HTML is new and how many stylesheets and head scripts the document loads, and cache-verify-in-browser returns checks to run in a real browser, such as whether a rule from the new CSS is present. If the HTML is fresh and the rule is missing, clear asset optimisation from Hummingbird's own screens, then warm the page again. If Hummingbird's Cloudflare integration is in use, cache-check-setup lists that edge separately, and it needs its own purge too.
Running Hummingbird beside WP Rocket or W3 Total Cache
Hummingbird says it can share a site with WP Rocket or W3 Total Cache as long as each overlapping feature is switched on in only one of them. Keeping to that rule is mostly an inventory job, and the agent can do the reading. cache-get-settings for the other plugin returns its page cache, minification, combining and lazy-loading state in the shared vocabulary. cache-get-settings with driver hummingbird and include_native lists Hummingbird's wphb rows by name.
Because Hummingbird's rows are unmapped, the agent should present them as names and values rather than claim what each one does, and the owner confirms in Hummingbird's dashboard which modules are on. The outcome is a short table of features enabled in both plugins and a decision for each about which plugin keeps it. Make the switch-offs in the plugins' own screens or one row at a time with confirmation, inside an experiment, and measure the pages that matter after each.
- Avoid overlapping page-cache ownership. Multiple active caches can serve different copies; inspect the actual request path and clear each relevant layer before checking freshness.
- WooCommerce cart, checkout and account pages are excluded from Hummingbird's cache by Hummingbird itself.
- A Hummingbird config applied later from its dashboard can undo a row change, so note which configs are in use.
Questions
Hummingbird questions
Why doesn't wphb_clear_page_cache clear the cache when called?
Hummingbird fires that action when it clears, rather than listening on it. has_action() found no listener, so GoBuildWP calls clear_cache() on the page-cache module instead.
Can the agent apply a Hummingbird config?
No. Configs go through the WPMU DEV config API, which GoBuildWP does not call; only individual option rows are writable.
Does a Hummingbird purge from the agent clear minified CSS and JavaScript?
The call GoBuildWP makes clears the page-cache module. Asset optimisation output is not part of it; clear that from Hummingbird's own screens if needed.
Limits
Hummingbird limits
- No canonical keys, no presets and no risk tiers; each native row change needs confirm=true and a browser check.
- The purge reaches the page-cache module only.
- If a future Hummingbird renames its accessor, check-setup shows purge_scopes.all false instead of an attempted purge that fails.
- Row writes bypass the config API; undo them with rollback-change, which restores the touched row exactly.
Where these facts come from
GoBuildWP behaviour is taken from the plugin source and the ability reference; third-party details from the vendor documentation below, checked by the GoBuildWP team.
Hummingbird is a separate product; no partnership or endorsement is implied.