Caching and page speedPro
Converter for Media MCP: where image conversion meets an AI agent
Converter for Media is not a cache. It generates WebP (and, in PRO, AVIF) copies of your images and serves them in place of the originals. A Converter for Media MCP connection through GoBuildWP therefore does two things: exposes the plugin's webpc_ option rows by name, and, through cache-verify-in-browser, reports which image formats a page's markup appears to reference. Markup cannot settle it: Converter for Media never changes image URLs to .webp, whichever delivery mode it uses, so the real format shows only in the response Content-Type. Starting a conversion run stays in the plugin's admin screen.
GoBuildWP Pro supplies settings access. Converter for Media PRO is a separate licence required for AVIF conversion.
converter_for_media- Layer
- asset
- Declared purge scopes
- No purge entry point declared
- Shared keys
- None
- Detected by
- plugin folder webp-converter-for-media
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.
Data model
Converted copies beside your uploads
Converted files are written to /wp-content/uploads-webpc/; originals are left untouched and image URLs in your content do not change. Delivery happens through .htaccess rewrite rules or the plugin's Pass Thru mode, which is why it needs mod_rewrite, mod_mime and mod_expires on Apache, extra configuration on Nginx, and GD or Imagick built with WebP support.
Its settings are option rows starting with webpc_. GoBuildWP reads them in full and writes one exact name per key after reading it back. They answer questions no cache plugin asks (which formats to generate, at what quality, by which method), and GoBuildWP deliberately does not equate any of them with a cache plugin's next-gen image setting: that setting rewrites URLs to files, while this plugin creates the files.
Converting the media library is a long-running job started from the plugin's own screen, or with wp converter-for-media regenerate on the command line. GoBuildWP does not start it.
Option name prefixes
webpc_
An image converter rather than a cache: it produces the WebP and AVIF files that a cache plugin's next-gen setting only rewrites URLs to. Nothing is mapped onto the canonical vocabulary because its settings answer a different question ; which formats to generate, at what quality, by which method ; and claiming one of them means the same as another plugin's images.next_gen would be false: that key rewrites URLs, this plugin creates the files. Its option rows are readable and writable by name. Conversion itself is a long-running job over the media library and is started from its own admin screen, not from here.
Other plugins
Converters, caches and CDNs
- image_delivery lists every converter GoBuildWP knows (WebP Express, EWWW Image Optimizer, ShortPixel, Imagify, Optimole, Smush and Converter for Media) with an active flag, which shows at a glance when two are installed. Only Converter for Media is confirmed never to put .webp URLs in the page; for the others markup_shows_next_gen is null, meaning not verified, and the same Accept-header request comes before any blame on their queue.
- The vendor's testing guide says to purge caches such as Cloudflare or LiteSpeed before checking results; cache-purge handles the plugin layers, and an edge still needs its own purge.
Limits
What stays with the converter
- GoBuildWP cannot start, pause or resume conversion; the plugin's screen and wp converter-for-media regenerate do that.
- image_delivery reads file extensions in markup, so on this plugin its count never shows WebP; the Accept-header request it recommends is the check that does.
- Images hosted on a CDN or another server are not converted, per the vendor; the plugin works only on files on the WordPress server.
- Row writes are undoable with rollback-change; generated files are untouched by any undo.
Worked example
Are visitors actually getting WebP?
Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.
Following the vendor's test, open DevTools' Network panel with cache disabled: a converted image can keep its .jpg or .png address while arriving with a WebP response type. That proves delivery for the tested request, not the whole library or sole attribution to Converter for Media. Sample other paths and inspect the conversion queue, server requirements and any image host or CDN.
Run conversion in the plugin. This converter never puts .webp URLs in the page, so the markup count cannot show delivery: request an image with Accept: image/webp,image/avif and cache disabled, and inspect Content-Type and Vary. Verify external-cache purges separately.
I installed Converter for Media and ran the conversion. Are visitors getting WebP now?
wppilot/cache-check-setupReadLists converter_for_media plus the page caches and edge layers that could be serving older responses.
wppilot/cache-purgeWriteClears the page-cache layers so cached HTML and headers do not mask the change; the converter itself reports nothing to purge.
wppilot/cache-verify-in-browserReadReturns image_delivery with Converter for Media marked active with markup_shows_next_gen false, plus an Accept: image/webp request to test delivery for that image path. One response does not establish whole-library conversion or which plugin served it.
A suggested sequence from the ability reference, not a recorded run.
Abilities
The cache abilities, applied to an image converter
| Ability | What it does here | Undo and limits |
|---|---|---|
cache-verify-in-browser | Its image_delivery report counts JPEG, PNG, GIF, WebP, AVIF and SVG sources on a page and lists the converters it knows with an active flag. Current source marks Converter for Media markup_shows_next_gen: false (its pages never carry .webp URLs), so with it active and no WebP or AVIF counted the recommendation says the count cannot show delivery and gives a request to run instead: fetch one of the page's images with Accept: image/webp,image/avif and read Content-Type and Vary. | It counts by file extension in the HTML, so a page being served WebP still counts as JPEG here. A response in the original type is a lead to inspect conversion, negotiation and delivery for that tested path; a CDN, another optimizer or cache rule can also affect it. |
cache-check-setupcache-measure-page | check-setup lists converter_for_media as kind asset with no purge scopes, so its rows are reachable. measure-page reports images lacking width and height, a separate problem from format. | Neither sees the response type of an image, which is where WebP delivery shows. |
cache-get-settingscache-set-native | List webpc_ rows and change one by exact name with confirm=true. | A row write is a direct option update; if a changed delivery method needs new rewrite rules, save once in the plugin's screen. |
cache-purgecache-warm | Have nothing to purge for this layer, but purging the page caches and edge in front matters after a delivery change, since cached pages and headers can hide it. | The converter result always reads not purged; that is expected. |
cache-set-settingscache-apply-presetcache-list-presets | Never map onto this plugin. images.next_gen on a cache plugin is not treated as the same thing. | Presets cannot turn conversion on. |
cache-list-actionscache-run-action | Declare no conversion action. | Run conversion from the plugin's screen or WP-CLI. |
cache-begin-experimentcache-revert-experimentrollback-change | Restore webpc_ rows to their captured values. | Files already generated in uploads-webpc are not removed or restored by any undo. |
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.
Files from the converter, URL rewriting from the cache
Converter for Media next to a cache plugin's own WebP switch
A Converter for Media MCP session usually involves a second plugin with its own idea about WebP. In GoBuildWP's shared vocabulary, images.next_gen lands on WP Rocket's cache_webp, Speed Optimizer's siteground_optimizer_webp_support, WP-Optimize's use_webp_images, LiteSpeed's img_optm-webp and Cache Enabler's convert_image_urls_to_webp, and both the balanced and aggressive presets switch it on. Applied to a page cache on a site where Converter for Media already delivers WebP, a preset can add a second mechanism deciding which file a visitor receives.
Before applying a preset there, read cache-list-presets for the page cache: its would_change list shows whether images.next_gen is about to flip. Whether the two mechanisms sit together cleanly on your stack is something to test on staging, not assume. If Converter for Media should stay the only delivery path, apply the individual keys you want with cache-set-settings instead of the preset, and leave images.next_gen off on the cache plugin.
uploads-webpc is full but browsers still receive JPEG
When conversion has run and the browser still gets the original format, the cause is usually delivery rather than conversion. Work down this list in order; every step before the last is read-only or a purge.
- cache-verify-in-browser on a page with several images. It counts extensions in the markup, where this plugin never shows WebP, so the current recommendation names Converter for Media and gives the deciding request instead: fetch an image with Accept: image/webp,image/avif and read Content-Type and Vary. A WebP or AVIF answer establishes that tested response type. It does not prove whole-library conversion or identify the delivering plugin; sample other image paths and inspect conversion state, the delivery route and cache or edge responses.
- The blocked_by_environment list in the same response: on a LiteSpeed or Apache server with no .htaccess in the WordPress root, WebP content negotiation is named as inert, typical of OpenLiteSpeed unless the vhost loads .htaccess. The confirmation it suggests is a request with Accept: image/webp and a look at Content-Type.
- cache-check-setup for edge layers: a CDN that stored the JPEG before conversion keeps serving it until it is purged at the edge.
- cache-purge across the page caches, since cached HTML and headers can hide the change.
- Only then the plugin's own screen: delivery method, server requirements, and whether the image lives on this server at all.
Who can run a Converter for Media check, and on which licence
All of that diagnosis apart from the purge runs under the Read Only safety profile, for a user who can manage options; cache-purge is a write and needs Production Safe or higher. Changing a webpc_ row goes through cache-set-native, which is annotated destructive and asks for confirmation on every profile that allows it. See how the safety profiles work.
Two licences can be in play. The cache abilities are part of GoBuildWP Pro, while AVIF output and remote conversion are features of Converter for Media's own PRO edition. Neither licence lets the agent start a conversion run.
Converter for Media prompts that stay within reach
Phrase requests around evidence and settings, not around conversion, which stays in the plugin.
- "Check the product page and tell me whether its images arrive as WebP. Read only."
- "Would the balanced preset on our page cache change anything about WebP? Show me would_change and apply nothing."
- "List the webpc_ rows and tell me which delivery method is set."
Questions
Converter for Media questions
Is Converter for Media a cache plugin?
No. It creates WebP and AVIF files and delivers them. GoBuildWP lists it with cache layers only so its settings can be read and written.
Can an AI agent convert my media library?
No. Conversion is started from the plugin's screen or with wp converter-for-media regenerate; GoBuildWP declares no action for it.
Why does GoBuildWP report no WebP when the conversion worked?
The plugin serves WebP at the original .jpg or .png address, and image_delivery counts by extension in the HTML. Its recommendation says so and gives the check to run: request an image with Accept: image/webp and read the Content-Type that comes back.
Does Converter for Media produce AVIF?
AVIF conversion, and conversion on a remote server, are PRO features according to its WordPress.org page.
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.
Converter for Media is a separate product; no partnership or endorsement is implied.