Marco Di Giacomantonio
Forum Replies Created
-
That’s great to hear — “avif not txt” means the MIME fix did its job, so the display issue is sorted.
For the few featured images that still don’t load: that’s almost certainly Cloudflare still holding the old copies. Here’s what happened — before you added the AddType line, Cloudflare cached those specific image URLs with the wrong (text) content-type. The plugin’s per-image purges ran back then, so the bad version got re-cached at the edge. Now that the origin serves them correctly, Cloudflare is still handing out the stale text copy for those particular URLs, which is why the browser can’t render them.
The fix is a one-time full purge: in Super Page Cache, use “Purge all cache” (not selective) once. That clears the stale text/plain copies, and on the next load Cloudflare re-fetches them with the correct image/avif type. After that the featured images should display too.
Also good sign: you mentioned they’re still converting — that means the background queue is running again on 1.9.10, so as more images finish, more will switch over to AVIF automatically. You don’t need to track which are done manually; the ones still pending just keep serving the original until their turn.
And noted on EXIF — I’ll add the optional preserve toggle to the roadmap. Thanks again for working through all of this with me.
Marco
I-PR AVIF ConverterPlease don’t roll back your WordPress backup or downgrade — you won’t lose any data, and a rollback won’t fix it anyway. This one is on me, and I’ve already shipped the fix.
What happened: in 1.9.9 I added self-healing cron scheduling. The unintended side effect was that whenever the cron event is registered, the plugin’s shutdown-based background processing got switched off — it assumed “cron is scheduled” meant “cron is running.” On a setup like yours, where WP-Cron shows as scheduled but isn’t actually being executed, that left nothing to process the queue. That’s exactly why it shows WP-Cron active with no errors, yet nothing converts. And downgrading didn’t help because the scheduled event stays in WordPress’s database regardless of plugin version, so the old version hit the same condition.
The reason a rollback won’t help is the same reason you don’t need one: it’s not a data problem, it’s which code path runs.
I’ve just released v1.9.10. It makes the background fallback always active as a safety net, so the queue processes regardless of whether WP-Cron actually fires on your host. Please update to 1.9.10 — no need to clear anything or restore a backup. After updating, just load a few pages on the site (the fallback runs after the page is served) and the queue should start draining again. Your existing data and settings are untouched.
Apologies for the disruption — this was my regression, and thank you for the detailed report that made it easy to pinpoint.
Marco
I-PR AVIF ConverterHold on — please don’t uninstall yet, because this isn’t the plugin failing, and it’s a one-line fix on your side.
What’s happening: the AVIF files were created correctly (that’s why your stats show the savings). The issue is that your server doesn’t yet know that a .avif file should be served as an image — so it’s sending them with a text content-type, which is exactly why the browser won’t display them and why they download as .txt. Clearing cache won’t change it, because the origin server itself is mislabeling the file every time.
The fix is to register the AVIF MIME type on your server. Since you’re on LiteSpeed, add this single line to your site’s .htaccess (any position is fine):
AddType image/avif .avif
Then, because Cloudflare has cached the wrong content-type, purge those image URLs (or purge all) so Cloudflare re-fetches them with the correct image/avif type. After that, the AVIF images will display normally and the .txt download issue disappears.
If your host has a MIME-types panel instead, you can add the same mapping there (extension: avif → type: image/avif).
Give that a try before reverting — I’m confident it’s just the missing MIME type. And thanks for using Imgur this time, the screenshot came through fine. I’m also going to make the plugin register this automatically in the next version so nobody else hits it.
Marco
I-PR AVIF ConverterGood question, and good news: the plugin only purges the specific image URLs it converts — it never does a full “purge everything” on Cloudflare. Under the hood it sends a targeted purge-by-file request to the Cloudflare API with just the converted image URLs (batched into chunks, with a short pause between batches to stay within API rate limits). So it won’t wipe your whole cache, and it won’t fight with Super Page Cache’s own selective purging.
Since you already have an API token with the right privileges, you can safely enable the plugin’s CDN purge if you’d like the converted image URLs invalidated automatically the moment they’re generated. It’ll coexist fine with Super Page Cache — the plugin handles its image URLs, Super Page Cache handles your post/page HTML. No conflict, no over-purging.
That said, if you’d rather keep everything centralized in Super Page Cache and purge manually, that’s perfectly fine too — the fallback is already baked into the cached HTML, so nothing breaks either way. It’s just a convenience either way.
Glad the misfiring is sorted. Thanks again!
Marco
I-PR AVIF ConverterGlad it’s fixed! And thanks for explaining — that makes sense, and you’re right that wordpress.org doesn’t allow image uploads in the forum, so I understand the need for an external link.
For sharing screenshots, my honest recommendation is to skip the temporary file-hosts — some of them wrap the download page in aggressive ads/redirects that can land on sketchy pages, which is the only reason I didn’t open the earlier ones (nothing personal, just a habit I keep). A couple of cleaner options:
- Imgur (imgur.com) or a GitHub Gist for images — direct, no redirects, free.
- For logs specifically, the easiest is to just paste the relevant lines as plain text right here in the reply. Text is actually better than a screenshot for me anyway, because I can copy the exact query or error string and search the codebase for it directly.
So for anything log-related, plain text in the thread is ideal. For visual stuff (UI glitches etc.), an Imgur link works great.
Thanks again for all the testing — genuinely made the plugin better this week.
Marco
I-PR AVIF ConverterThanks Melvin, and I appreciate the kind words — means a lot that you switched over from Smush/CompressX. Noted on the “don’t forget me” 🙂 for now everything in the plugin is free; if anything ever changes I’ll make sure early supporters are looked after.
Quick answers to each point:
EXIF: noted, I’ve added an optional “preserve EXIF” toggle to the roadmap. Default will stay strip-on, but it’ll be there for people who want it.
WebP at quality 65: you’ll be fine. WebP only gets served as a fallback to the few browsers that still don’t support AVIF, and 65 is perfectly acceptable visual quality for that fallback. It’s not your primary delivery format, so even if WebP were a touch softer than AVIF at the same number, almost no one would be seeing it. (Independent per-format quality is on my list too, for people who want to fine-tune it.)
Cloudflare + Super Page Cache: good news on the part you were hoping for — the tags are written into the page HTML server-side, while the page is being generated, so by the time Super Page Cache stores the cached HTML the AVIF source + original fallback are already baked in. The fallback works straight from cache. No special handling needed.
On the purge: the plugin auto-detects cache plugins via their hooks (that’s why it picked up LiteSpeed), but Cloudflare itself is purged through Cloudflare’s API, which only runs if you enter a Zone ID + API token in the plugin settings and enable CDN purge. Since you already rely on Super Page Cache for Cloudflare and purge from there, you can simply leave the plugin’s Cloudflare purge off — no need to duplicate it. Only add the API token if you’d prefer the plugin to auto-purge the converted URLs itself.
Lastly, the “misfiring” in the log: that’s the SQL error line, fixed in v1.9.8 — it was log noise only, your queue was always working (as you saw). Update and it’ll stop appearing.
Marco
I-PR AVIF ConverterForum: Reviews
In reply to: [I-PR AVIF Converter – Automatic Image Optimization] Great PluginThank you, Melvin — really glad it’s working well for you, and that the background cron approach landed. That was the part I cared most about getting right.
On it “not picking up just yet”: that lines up with what we discussed — the cron event wasn’t always staying registered on setups like yours. I just shipped v1.9.9 with self-healing scheduling that re-registers it automatically, so after you update it should settle and the status will show “WP-Cron” properly.
If you do spot anything else in the logs, feel free to paste the relevant lines directly here as text and I’ll take a look — that’s the quickest way for me to dig in. Thanks again for all the detailed feedback over the last day; it directly made the plugin better across a few releases.
Marco
I-PR AVIF ConverterBoth of these are good product suggestions — thanks for thinking it through.
On the side-by-side image comparison: there isn’t one today, and I agree it’d be genuinely useful — a sample test run that shows the original and the AVIF next to each other with their file sizes, so you can judge quality vs. savings before committing to a quality setting. It’s a proper feature rather than a quick tweak, so I’m putting it on the roadmap for a dedicated release rather than rushing it.
On the batch number: you’re right that the setting is capped at 20, but it’s worth knowing that number is more of a soft ceiling than a hard throughput limit. The plugin already sizes each batch adaptively — it estimates per-image memory cost against your server’s available RAM and processing time, takes the safest of those, and automatically scales the batch down mid-run if it gets close to a timeout or memory pressure. So in practice the engine self-tunes regardless of whether you set 3 or 20.
That said, I’ll raise the configurable ceiling to 50 (which matches the internal safety limit) in an upcoming release, with a note in the UI explaining the auto-throttling. I’d hold off going higher than that — beyond 50 would mean removing the memory/timeout safeguards, which is where things start crashing on shared hosting. 50 with adaptive sizing underneath is the sweet spot between throughput and not blowing up a site.
Appreciate the detailed feedback.
Marco
I-PR AVIF ConverterThanks for this — the first part is a real bug and you pinpointed it well.
The “plugin activated” welcome notice wasn’t dismissing because its dismiss link was pointing at an outdated internal action name, so clicking it did nothing and the notice came back on every admin page. I’ve fixed it in v1.9.9 (releasing now) — once you update, dismissing it will work and stick.
On the “too many notifications from processed images”: I want to be straight with you here. This plugin only ever shows a single admin notice — that one welcome message — and it doesn’t generate any per-image notifications at all. There’s no code path in it that creates a notice for each processed image. So what you’re seeing as “100+ notifications” is either that single welcome notice reappearing over and over (the dismiss bug above, which 1.9.9 fixes), or notices coming from another plugin on your site. If after updating to 1.9.9 you still see repeated notifications, they’re not coming from this plugin — it’d be worth checking which plugin is actually emitting them.
Update to 1.9.9 and let me know if the welcome notice finally goes away for you.
Marco
I-PR AVIF ConverterGood questions. A few things to clarify:
First, the “error still there” part: that SQL error in your log is the PERCENTILE_CONT line, which I fixed in v1.9.8 (just released). Once you update, it stops being written to the log entirely — so the log will actually be readable and you’ll be able to tell what’s happening without that noise.
On the “Shutdown fallback” badge: that label only reflects one thing — whether the plugin’s own WP-Cron event is currently registered in WordPress’s schedule. It is not the processing engine itself. Your images are being converted regardless (as you noticed, they’re processed in the background), so nothing is actually broken.
The reason it shows “Shutdown fallback” even with your system cron running: the plugin currently only registers its cron event on activation and when settings are saved. If the event isn’t present in WordPress’s schedule at that moment — which is common on setups with DISABLE_WP_CRON plus a real system cron — the badge falls back to the shutdown method. As a quick workaround right now, open the plugin settings and just hit Save: that re-registers the event, and the badge should switch to “WP-Cron.”
I’m also adding self-healing scheduling in the next release so the event is re-created automatically on setups like yours, without needing to re-save. Update to 1.9.8 first for the clean log, and let me know what the badge shows after re-saving settings.
Marco
I-PR AVIF ConverterHi Melvin,
Good news on the log line you pasted earlier: it’s fixed. The RAM batch estimator was running a PERCENTILE_CONT query that MySQL 8 and MariaDB don’t support in that form, so it threw a syntax error into your debug log on every queue run. A fallback was already handling the actual calculation, so conversions were never affected — it was log noise, not a functional bug. I’ve replaced it with a portable percentile calculation, released just now in v1.9.8. Once you update, that error will stop appearing.
While I was at it I also corrected the declared “Requires PHP” to 8.1 to match the codebase.
On the second item: as a rule I don’t open files hosted on external/temporary file-sharing links from support threads — nothing personal, it’s just a security practice I keep to. If there’s anything else in your log you’d like me to look at, the best way is to paste the relevant lines directly here as text and I’ll dig into them right away. The PHP notice about the “disable-dashboard-for-woocommerce” text domain, for what it’s worth, comes from that other plugin and isn’t related to this one.
Thanks again — update to 1.9.8 and let me know if anything still shows up in the log.
Marco
I-PR AVIF ConverterForum: Reviews
In reply to: [I-PR AVIF Converter – Automatic Image Optimization] Great PluginThank you, Melvin — this means a lot, especially coming from someone who dug into the technical details. “It just works” is exactly what I was going for, and the background cron processing is the part I obsessed over most: converting in the background without an external API or blocking the site. Your support questions also directly shaped the new revert option in 1.9.7. Really glad it’s a good fit for your setup — don’t hesitate to reach out if anything comes up.
Marco
Quick update on point #2 (deleting processed images / reverting): this is now live in v1.9.7, which I just released.
You’ll find it on the plugin’s settings page as the “Delete generated images (revert)” button, next to “Clear queue.” It removes all AVIF/WebP files the plugin generated and clears the queue, so your site goes back to serving the original images — no uninstall needed. Your originals are never touched (the only exception is if you had explicitly enabled “Delete originals”).
One note: it removes generated files that sit next to an original image, which is the safe behaviour so it never touches files it didn’t create. If you had “Delete originals” on at some point, those few orphaned files would need to be cleared manually.
The other three points (EXIF, WebP quality, Cloudflare) are unchanged from my previous reply. Thanks again for the suggestion — it’s a genuinely useful addition.
Marco
I-PR AVIF ConverterHi Melvin,
Thanks for the detailed questions — let me go through each one.
1. EXIF data
EXIF is stripped during conversion, by design. It keeps the output as light as possible and avoids carrying over metadata you usually don't want public on a web image (GPS coordinates, camera serials, etc.). There's no toggle to preserve it at the moment, but it's noted on the roadmap. If preserving EXIF matters for your workflow, let me know — that kind of feedback helps me prioritize.
2. Reverting processed images without uninstalling
First, the important part: your original files are never deleted during conversion. Each AVIF is written as a separate file alongside the source (image.jpg stays, image.avif is created next to it). The only exception is if you've explicitly enabled the "Delete originals" setting — it's off by default and shows a warning before use.
To be transparent: there isn't a one-click "revert" or "delete all generated images" button in the current version. The cleanest way to revert without uninstalling is to simply deactivate the plugin — as soon as it's deactivated it stops rewriting your images, and your pages serve the original JPEG/PNG again immediately. The generated .avif (and .webp) files just stay on disk unused; they're harmless, and you can delete them manually via FTP or your file manager if you want to reclaim the space.
A dedicated "Revert all / remove generated images" action with a confirmation dialog is a fair request and I'll add it to a future release — thanks for flagging it.
3. WebP compression settings
There's a single "AVIF Quality" field (default 70). When you enable "Generate WebP," that same quality value is reused for the WebP output — there's no separate WebP compression field. WebP is an optional on/off extra: AVIF always stays the primary format, and the .webp file is generated as an additional fallback. If independent per-format quality would be useful for you, it's a reasonable request and I'll consider it.
4. Cloudflare and caching
The plugin generates static AVIF files on your own server, so Cloudflare caches them like any other static asset once they're first requested — no special configuration needed. The fallback isn't handled at the cache layer: the plugin outputs a standard HTML<picture>tag with<source type="image/avif">and your original JPEG/PNG as the<img>fallback. Browsers that support AVIF load it; older ones automatically use the original. Cloudflare simply serves whichever file the browser requests.
The plugin also includes a CDN purge step (Cloudflare and LiteSpeed) that invalidates the relevant URLs after conversion, so the CDN serves the freshly generated file rather than a stale pre-conversion version.
Let me know if anything needs clarification.
Marco
I-PR AVIF Converter