Caching and page speedPro

FlyingPress MCP: unmapped settings and purges that prove they exist

FlyingPress MCP access through GoBuildWP Pro is careful by design. FlyingPress is commercial and its keys have not been verified against other plugins, so there is no shared settings map and no preset; an agent reads and writes its own settings by name, with confirmation each time. Purges go through FlyingPress' purger class, called only if that class and method exist on the installed version.

By GoBuildWPContent updated 13 October 2026How we check claims

Get GoBuildWP free See Pro pricing

FlyingPress driverflyingpress

Layer: page
Declared purge scopes: allurl
Shared keys: None
Detected by: constant FLYING_PRESS_VERSION

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.

Limits

What to know first

No key has a verified meaning, so none is mapped, no preset applies and no key is marked risky. Every change goes through cache-set-native with confirm and needs a browser check.
The current bridge prefers FlyingPress\Purge::purge_everything() for all and FlyingPress\Purge::purge_urls([...]) for URLs. Guarded Purger candidates remain fallbacks; check the installed entry point and returned per-layer result.
There is no post-scoped purge; a post request widens to everything.
FlyingPress requires public reachability. A publicly reachable staging site can be tested; an inaccessible local site does not meet that requirement.

Other plugins

FlyingPress prefers to be alone

FlyingPress strongly recommends not using any additional page caching or page optimisation plugin.
It disables conflicting optimisations in Breeze, EWWW, Perfmatters, ShortPixel Adaptive Images and SiteGround Speed Optimizer automatically, so a setting in those plugins may read as on while FlyingPress has overridden it.

Worked example

Check the purge path before relying on it

Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.

The agent reports the resolved purge entry point and the homepage response it measured. Confirm the updated content and cache owner on the visitor path before reporting freshness. If the purger does not resolve, clear from FlyingPress' own screen or its wp flying-press purge-everything command.

Wait for the requested rebuild using vendor status where available. Check expected content and visitor interactions; a preload request or elapsed wait does not prove completion.

AI clientyour-site.comVerify site policy

Clear FlyingPress after the homepage update and confirm the new version is what visitors get.

wppilot/cache-check-setupRead
Lists FlyingPress with native settings only and, crucially, which purge scopes resolve on this install.
wppilot/cache-purgeWrite
Scope all; the per-layer result names the resolved installed entry point if it ran, or reports FlyingPress unpurged.
wppilot/cache-warmWrite
Requests the homepage and notes whether a cache hit came back.
wppilot/cache-measure-pageRead
Checks cache status and response time on the rebuilt homepage.

Proposed sequence from source declarations; not a recorded task or proof of client compatibility. Inspect saved state and browser or provider results separately.

A suggested sequence from the ability reference, not a recorded run.

Data model

Settings row and cache folder

GoBuildWP looks for FlyingPress settings under flying_press_settings and FLYING_PRESS_SETTINGS, both spellings being declared, and exposes every key in them to the native read. Because FlyingPress has no public source and cannot be installed in CI, those keys are shown and written by name without any claim about what they do.

FlyingPress' documentation keeps cached pages in wp-content/cache/flying-press/, needs wp-content writable, and leaves that folder behind on uninstall. Its features include unused and critical CSS, delay JS, lazy loading, WebP and AVIF, font handling, FlyingCDN and preloading, all of which live in that settings row and none of which has a shared key here.

Option rows

flying_press_settings
FLYING_PRESS_SETTINGS

Abilities

The cache abilities on FlyingPress

Ability	What it does here	Undo and limits
`cache-get-settingscache-set-native`	include_native returns the whole settings row; a write names one existing key and is refused if it cannot be read first.	Confirm on every write. The ledger stores the row beforehand, so rollback-change can restore it.
`cache-set-settingscache-list-presetscache-apply-preset`	Every canonical key reports unsupported, and presets list nothing they could set.	These change nothing here.
`cache-purgecache-warm`	All and url scopes call the purger's static methods after checking class and method exist; post falls back to all.	No undo, and FlyingCDN or another edge needs its own purge.
`cache-list-actionscache-run-action`	No FlyingPress actions are declared; its preload is available to you as wp flying-press preload-cache.	Nothing to run.
`cache-check-setupcache-measure-pagecache-verify-in-browsercache-begin-experimentcache-revert-experiment`	Detection by FLYING_PRESS_VERSION with resolvable purge scopes, delivery measurement, browser checks, and a snapshot of the settings row.	Revert needs confirm.

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.

Working FlyingPress by name

Finding which FlyingPress key a toggle writes

With no shared map, the hard part of a FlyingPress change is knowing which key in its settings row corresponds to the switch the owner is talking about. Guessing from a key name is exactly what GoBuildWP refuses to do on the owner's behalf, but there is an honest way to find out. Read the whole row with cache-get-settings and include_native, ask the owner to flip the one toggle in FlyingPress' own screen and save, then read the row again. The key whose value changed is the key that toggle writes, on this version, on this site.

From then on the agent can work that key directly with cache-set-native, always with confirmation, and the ledger keeps the row's previous state for rollback-change. Note the key and its meaning in the site's own documentation, because a FlyingPress update can rename or restructure settings, and the next person to tune the site should repeat the diff rather than trust an old note. If native_complete comes back false, the row was too large to return in full, and a missing key should not be read as proof the setting does not exist.

Start an experiment before the first by-name write, so one revert covers the whole session.
Change one key per round and measure in between; a by-name change has no risk tiering to warn you.
If a written key does not behave as expected, roll it back rather than layering a second guess on top.

Measuring FlyingPress results on the public URL

FlyingPress expects to reach the site publicly, so measurements should too. cache-measure-page reports how each request was fetched, and a server fetching its own URL by an internal route can skip a CDN or edge that real visitors pass through. Compare repeat requests after cache-warm: a page that stays a miss after warming points at an exclusion, a logged-in cookie or a query string rather than at a slow server.

The FlyingPress features most likely to break something are the ones that change script and style delivery, such as delaying JavaScript or removing unused CSS. After any of those, cache-verify-in-browser names the elements most at risk on that URL and hands back browser checks to run. Test the interactions that matter to the business, such as the cart, the menu and any form, because a page that looks right can still have a button that no longer responds.

Settings in other plugins that FlyingPress overrides

FlyingPress switches off conflicting optimisations in several plugins it shares a site with, Breeze and Perfmatters among them. On such a site cache-check-setup lists more than one layer, and cache-get-settings on the other plugin may report an optimisation as on that FlyingPress has in fact taken over. An agent should not try to fix that disagreement by writing to the other plugin. Treat FlyingPress as the layer that decides, and if the owner wants the other plugin to own a feature, that is a decision to make in FlyingPress' settings first.

Questions

FlyingPress questions

Why doesn't GoBuildWP map FlyingPress settings like it does for LiteSpeed or WP Rocket?

A mapping asserts a FlyingPress key means the same as a key elsewhere. Without source to read or a copy to test, nobody has verified that, so GoBuildWP offers access by name only.

The agent says it could not purge FlyingPress. What now?

Read the FlyingPress entry in the purge results first: purged false comes with a detail saying why, such as the purge function not being found on this install. Whatever the reason, clear from FlyingPress itself or run wp flying-press purge-everything; the agent will not claim a purge that did not happen.

Can I test FlyingPress changes on a local copy with the agent?

Not on a local copy. FlyingPress says it needs a publicly reachable site, so a copy on your own machine is outside what it supports. A staging copy that is reachable from the internet fits that requirement; check FlyingPress's licence terms for staging domains, and measure it on its public URL.

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 29 September 2026 by the GoBuildWP team.

FlyingPress is a separate product; no partnership or endorsement is implied.

Try it on FlyingPress in Read Only first

Get GoBuildWP free See Pro pricing