| 开发者 | australcode |
|---|---|
| 更新时间 | 2026年10月22日 10:08 |
| PHP版本: | 8.2 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPL-2.0-or-later |
| 版权网址: | 版权信息 |
<picture> element. The result: same size product images across your whole shop — resize product images without cropping and regenerate product thumbnails in bulk, with no catalog limit.
Key differentiators
<picture> markup — multi-source with AVIF + WebP + JPEG fallback. Survives any page cache (LiteSpeed, WP Rocket, Cloudflare APO, W3 Total Cache) because it does not use Vary: Accept. The browser picks the optimal format; the cache serves HTML without negotiation.IMG_4832.jpg. Image SEO reads the WooCommerce product title, category and brand and writes real alt text: "Vape Pod XYZ — Pods, Brand Z". Automatic on every new upload, free, no AI and no API calls. It never overwrites alt text you wrote yourself.custom_order_tables and cart_checkout_blocks compatibility without any setup./cdn-cgi/image/format=auto) with automatic availability detection on your zone. If CIT is not enabled on your CF plan, the plugin keeps serving local derivatives without breaking anything.oom, missing_original, engine_failed, fs_permission), scope filters (auto = products only based on Settings; all-used = every image referenced in posts/products/Bricks templates/terms).wp acimg health, stats, regenerate, derivatives <id>, purge-cache (orphans; --stale/--all require Pro), restore-originals, migrate-from-sir. 2 Pro: wp acimg doctor (extended diagnostics) and wp acimg reset (full state reset).<img> with CIT URLs (/cdn-cgi/image/format=auto) instead of local derivatives when CIT is enabled on your zone. Defensive automatic fallback to the normal path if CIT is unavailable.wp_termmeta, WooCommerce shortcodes, custom meta. Trash mode with typed confirmation, immutable audit log, and an untrash endpoint for rollback.gpt-4o-mini) or Anthropic Vision (claude-haiku-4-5). Bring Your Own Key (no Merchant of Record over AI costs). Context enrichment with WooCommerce product title + category + brand. Complements Image SEO rather than replacing it: use it on the photos where the product name doesn't describe the picture.fetchpriority="high" and propagates correct loading/decoding to the final <picture>. Native LCP optimization.wp_get_attachment_image and optional output buffer rewriter for themes/page builders that bypass that filter.data-src/data-sizes lazy loaders (reads both if present).<picture> element, cache-safe by design — AVIF + WebP + JPEG fallback served without Vary: Accept, so it survives any HTTP page cache (LiteSpeed, WP Rocket, Cloudflare APO, W3 Total Cache). The browser picks the format; the cache serves one HTML.wp_get_registered_image_subsizes() and respects the WC thumbnail-cropping setting, so it targets exactly the product sizes your theme uses.libheif for AVIF) or GD as fallback.wp plugin install australcode-uniform-images --activate
wp acimg health # verify everything is OK
wp acimg regenerate # bulk dry-run
wp acimg regenerate --start --yes # starts bulk in the background
wp acimg purge-cache --orphans --yes # clean up derivatives whose image is gone
Pro adds two more commands — wp acimg doctor (extended diagnostics) and wp acimg reset (wipes every persisted artifact: the 6 custom tables, options, post meta, transients and derivative directories, without deactivating the plugin). They ship only in the Pro build, so in the free version they are not registered at all. Pro also unlocks the --stale and --all scopes of purge-cache; the free version runs --orphans. The destructive ones default to a dry-run that only lists what they would change; pass --yes to apply it.No. Image SEO writes the alt text, title and caption attributes — it does not touch filenames. Renaming a file after upload means rewriting every URL that already points at it, and getting that wrong breaks live product pages. If file renaming is what you're after, this is not the plugin for it.
Image SEO reads your WooCommerce product data — title, category, brand — and builds the alt text from a template. It's instant, free, deterministic, and runs on every upload. AI alt text (Pro) looks at the image itself and describes what it sees, using your own OpenAI or Anthropic key at a fraction of a cent per image. Most stores run Image SEO on everything and AI only on the images where the product name doesn't describe the picture — a lifestyle shot, a detail close-up, a size comparison. They write the same field, so neither runs automatically on top of the other, and neither overwrites alt text you wrote yourself.
No. The automatic path only writes where the field is empty. The plugin also records what it generated, so if you edit an alt text by hand afterwards it's locked — no automatic pass will touch it again. The only way anything gets overwritten is if you click the button on that specific image yourself, or explicitly pick the "replace existing" option on a bulk run — and even then only the alt text is replaced. Titles and captions you wrote are never touched.
Because they aren't attached to a product. Image SEO builds the text from the product title, category and brand — a logo, a banner or a blog image has no product to read from, so the plugin writes nothing rather than inventing something. The Dashboard counter reflects this: it reports how many images it can actually fill, not how many are missing alt text.
Yes. Australcode Uniform Images makes WooCommerce product images uniform, so WooCommerce is a hard requirement: the plugin declares Requires Plugins: woocommerce and WordPress blocks activation if WooCommerce is not installed and active. It is not a general-purpose image optimizer.
No. Not on the free version, not on Pro. There is no image cap, no monthly credit quota and no per-site allowance to run out of — the bulk run walks your entire catalog, ten products or thirty thousand. It processes through Action Scheduler in batches, so it survives a worker being killed mid-run and picks up where it stopped instead of starting over. What the size of your catalog does cost you is disk: roughly 700 KB of derivatives per original at the Standard preset. A thousand products with one image each is about 700 MB. That is the real constraint, and it is your server's, not a licence's.
No. AVIF, WebP and JPEG are generated by the free version and served together in a real <picture> element, with the browser choosing. Modern formats are part of the core of this plugin, not an upgrade — if AVIF were behind a licence, the free version would be shipping the heaviest possible image, which defeats the point.
What Pro adds on top of delivery is different in kind: serving through the Cloudflare edge, the library audit, the weekly health monitor, AI alt text and the per-aspect-ratio override. The formats themselves are never gated.
Yes. Compatibility with custom_order_tables and cart_checkout_blocks is declared from day one via before_woocommerce_init. No manual configuration required.
Yes, and well. The plugin emits <picture> with <source> per MIME type — it survives Cloudflare APO and any page cache perfectly because it does NOT use Vary: Accept (which would break caching).
If you have Cloudflare Pro+, you can enable Image Transformations from Settings → CDN edge. The plugin automatically detects whether CIT is available on your zone and emits /cdn-cgi/image/ URLs that CF transforms on-demand with format=auto.
Caution with Cloudflare Polish: if active, it re-compresses the AVIF/WebP that the plugin already optimized — double compression equals visual artifacts. The plugin detects this on the Health page and alerts you with an admin notice. Recommendation: disable Polish, keep APO.
Imagick (preferred) with libheif for AVIF. GD as fallback. libvips is wired in the code but requires bundled binaries (not included in v0.x — future sprint). The active engine and its capabilities (read/write per format) appear on Health → Image engines.
Imagick compiled with libheif (common on modern hosts: Kinsta, WP Engine, SiteGround, recent Cloudways). If Imagick does not support AVIF, the plugin still emits WebP + JPEG and the Health page reports the limitation. You do not get stuck without anything — you just lose the most efficient format.
Estimate: ~700 KB of derivatives on average per original image at Standard preset (varies a lot by content type — product photos with a uniform background compress better). For a catalog of 1,000 products with one image each, that's ~700 MB of derivatives. By default the plugin never modifies your originals — derivatives are separate files, so you need space for original + derivatives. The only exception is the optional "apply trim to original" setting (off by default), which backs up the pristine file first and is reversible with wp acimg restore-originals.
Change settings on Australcode Uniform Images → Settings, save (the plugin shows a modal warning you that existing derivatives are invalidated), and then go to Bulk regenerate or run wp acimg regenerate --start --yes. The plugin keeps serving the old derivatives until regeneration completes — zero visual downtime.
Yes, disable those plugins before installing Australcode Uniform Images. The Health → Doctor page detects them and alerts you. The typical conflict is that those plugins also hook into wp_get_attachment_image and rewrite the HTML — the output ends up inconsistent.
Yes, 9 commands under wp acimg <subcommand>. Seven ship in the free version: health (CI smoke test), stats, regenerate, derivatives , purge-cache, restore-originals, and migrate-from-sir. Two more ship only with Pro: doctor (extended diagnostics) and reset (resets all persisted state without deactivating). Each command supports --format=json, and wp help acimg lists the commands available in your build.
Open a support thread in the WordPress.org plugin support forum — the plugin menu links straight to it. For Pro license-related issues, use the "Contact Us" screen in the plugin menu, or email info@australcode.io.
<picture> inside the one Bricks builds, and browsers then ignored the per-width sources: phones got the desktop image. There is now a single <picture>, and each Bricks source gets its own AVIF and WebP versions for the same breakpoint. The source image you chose in Bricks stays as the fallback.woocommerce_single as 800×0, and some themes use 9999 for "no limit" (Shoptimizer: woocommerce_gallery_thumbnail 150×9999). In uniform mode those sizes came out on canvases like 800×9999 — always for a declared 9999, and for a 0 when a per-content-type override switched a proportional size to uniform. They now come out square at the size's width (800×800, 150×150), as a uniform size should. The reverse override works too: a uniform 800×0 switched to proportional is no longer boxed into 800×800. Run wp acimg regenerate (or a bulk regeneration) if your theme declares sizes with height 0 or 9999.wp acimg migrate-from-sir now detects Smart Image Resize Pro as its vendor ships it (wp-smart-image-resize-pro folder, wp_sir_settings option) and also imports which post types it processed. Applying the import no longer resets settings it does not cover — per-content-type and per-aspect overrides, "Keep full-bleed photos", CDN — to their defaults.object-fit, a portrait full-bleed photo now stands taller than its neighbors. Only sites with the setting enabled see their derivatives marked outdated; regenerate to apply.<picture> wrapper no longer shifts theme layouts. Since 1.0.0 the wrapper uses display: contents, which also turned its <source> elements into flex and grid items: in a grid they took a cell, and in a flex container with a gap they added space before the photo. They are now hidden, still at zero specificity so any theme rule wins, and the browser keeps choosing the same AVIF or WebP file. Measured on a live store: a mini-cart row squeezed the product name into a 0 px column, and a category card photo dropped 30 px.acimg_should_wrap_in_picture filter now also covers variation data. Turning it off kept the gallery on the original photo, but picking a variation still switched to the optimized file — a different geometry, or a 404 where those files were not on disk. Both now follow the filter.margin: auto inside a flex or grid container are no longer pushed off-centre. Wrapping the image in <picture> used to change which element the layout sees, so the theme's centring stopped applying. Measured on a live site: an image sat 61 px to the left of where it belonged, on six pages. The wrapper is now transparent to layout, and the images land exactly where they do without the plugin.wp acimg regenerate --ids=12,34,56. Reprocess a specific handful of images without planning a full catalog run. It deliberately skips the context filter, which is the point: it is for the images the filter would otherwise skip.wp acimg reset deletes them only with --delete-backups), so wp acimg restore-originals still works after a reinstall.wp acimg purge-cache only ever deletes generated files. A stale database row could point it at an original upload; it now refuses anything outside the plugin's derivatives folder. --stale also stopped deleting files a current derivative still used.--yes is honoured when there is no terminal to confirm in.wp acimg doctor and wp acimg reset used to ship inside the free version and refuse to run without a license. They now ship only in the Pro build, so on the free version they are simply not registered — wp acimg doctor reports an unknown command instead of a license error. The advanced purge-cache scopes (--stale / --all) still appear in the free command's help and point you to Pro when used; only --orphans runs there, as before. Nothing changes for Pro users, and every free command (health, stats, regenerate, derivatives, purge-cache --orphans, restore-originals, migrate-from-sir) works exactly as before.<img> the plugin serves was not declaring its width and height, so the browser had no shape to reserve and themes that impose no aspect ratio of their own drew the image at whatever height the slot allowed — a square product image could render as a tall strip. Themes that set their own aspect ratio were masking it, which is why it only showed on some sites. The image now declares the dimensions of the file it actually serves. Safe in-place upgrade — no regeneration, no settings change.srcset still listed WordPress' original crops instead of the uniform ones the plugin generates, so a browser could pick a file whose proportions contradicted the image it belonged to.<picture> wrapper the plugin adds was invisible to your theme's CSS, so the height your theme sets on an image was measured against the wrapper instead of the card it sits in. The wrapper now behaves like the image it replaces.acimg-picture), so your theme can style it directly. If your theme already worked around this, your own styling still wins over the plugin's.alt="", aria-hidden or role when served as <picture>. The rewrite kept only a fixed list of attributes and dropped empty values, so a decorative image marked alt="" reached the browser without it — screen readers announced the filename instead of skipping the image. Every attribute your theme sets is now passed through untouched.auto token to the sizes of lazy images that is meant for the <img> tag only; the plugin was copying it into the <source> elements of the <picture>, where it made the browser resolve the wrong shape. The <img> keeps the token, the <source> copies no longer do — no settings change and no regeneration needed.es_ES and es_CL, 100% coverage). WordPress picks your site language automatically.