WooCommerce 11.1 automatically deactivates the standalone Additional Variation Images extension because the feature now lives in core. If galleries look incomplete, immediately reactivating the extension can create conflicting writers. Core migrates legacy metadata in scheduled batches of up to 250 variations, preserves legacy values, and does not overwrite a non-empty core gallery, so the right rollback depends on job state and data ownership.
Use this for large catalogs, interrupted WooCommerce 11.1 upgrades, custom gallery themes, direct metadata integrations, failed Action Scheduler jobs, emergency rollbacks, and stores where some variations show images while others do not.
Quick answer
Pause catalog edits and capture the affected variation IDs, old and new metadata, Action Scheduler migration status, WooCommerce database version, extension state, and current storefront output. If migration is still running, fix the queue and let an idempotent batch finish before changing ownership. If core metadata is correct but the theme fails, repair rendering. If data is missing, restore the database snapshot to staging and rerun the migration. Roll back production only with a complete code and database plan. Do not assume reactivating the old extension will synchronize later core edits.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Migration pending | Legacy data present | Resume scheduler |
| Core data correct | Theme output wrong | Fix renderer |
| Conflicting meta | Both non-empty | Review per variation |
| Full rollback | Code and DB snapshot | Previous state restored |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Freeze catalog edits | Record WooCommerce, extension, theme, and database versions; upgrade timestamp; Action Scheduler queue; product counts; affected variation IDs; backup ID; and cache state. | Representative high-value, empty, large, and recently edited variations show the expected ordered media. |
| Classify migration state | Compare _wc_additional_variation_images and _product_image_gallery for empty, migrated, conflicting, recently edited, and high-value variations without writing either field. | Action Scheduler has no unexplained migration failures or endlessly requeued batches. |
| Identify the current data owner | Inspect pending, running, failed, and completed migration actions, batch counts, retry history, PHP and database errors, worker availability, and the time of last catalog edit. | Admin, REST, CSV, theme, and headless views agree on the current core gallery. |
| Rehearse the chosen recovery | Test the active theme and a default theme, admin gallery editor, variation selector, REST API, CSV export, headless client, object cache, page cache, and CDN after a narrow purge. | The old extension remains inactive unless a fully tested rollback explicitly requires it and data ownership is restored. |
What to check first
- Record WooCommerce, extension, theme, and database versions; upgrade timestamp; Action Scheduler queue; product counts; affected variation IDs; backup ID; and cache state.
- Compare _wc_additional_variation_images and _product_image_gallery for empty, migrated, conflicting, recently edited, and high-value variations without writing either field.
- Inspect pending, running, failed, and completed migration actions, batch counts, retry history, PHP and database errors, worker availability, and the time of last catalog edit.
- Test the active theme and a default theme, admin gallery editor, variation selector, REST API, CSV export, headless client, object cache, page cache, and CDN after a narrow purge.
- Rehearse finish-migration, theme-fix, metadata-repair, code rollback, database restore, and forward-recovery paths on staging with the same affected fixtures.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison far more useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, OAuth refreshes, retries, and background processing can change the evidence.
- Check the public experience and the stored server-side result. Admin previews and isolated API calls do not prove the whole workflow.
- Repeat the test after the relevant cache, queue, scheduled action, webhook, and observation window has finished.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp plugin status woocommerce-additional-variation-images
wp action-scheduler action list --status=failed --format=table
wp db query "SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE post_id IN (812,813) AND meta_key IN ('_wc_additional_variation_images','_product_image_gallery');"
Why this usually happens
- The upgrade request completes while background migration still has many queued batches.
- A theme or extension reads the legacy key even though core now owns the current value.
- A variation edited after migration differs from preserved legacy metadata by design.
- A code-only rollback expects the older extension to understand newer core edits automatically.
Decision rule
Resume production only when the chosen path preserves every tested variation gallery, one component owns future edits, scheduled migration state is understood, and the complete code and database rollback has been proved.
Production verification checklist
- Representative high-value, empty, large, and recently edited variations show the expected ordered media.
- Action Scheduler has no unexplained migration failures or endlessly requeued batches.
- Admin, REST, CSV, theme, and headless views agree on the current core gallery.
- The old extension remains inactive unless a fully tested rollback explicitly requires it and data ownership is restored.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Freeze catalog edits
- Classify migration state
- Identify the current data owner
- Rehearse the chosen recovery
- Verify representative galleries
Mistakes to avoid
- Changing production before recording plugin versions, WordPress version, PHP version, UTC time, the exact fixture, and a tested rollback point.
- Accepting one successful admin screen while the public form, stored record, API response, accessibility tree, cache, email, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, device, locale, network state, and failure path that a real customer reaches.
- Leaving test accounts, broad credentials, debug logs, temporary compatibility filters, or synthetic customer data active after verification.
Questions teams ask during testing
Should I test this on production?
Use production for read-only evidence first. Reproduce the change on staging with a current data shape, theme, extensions, caching stack, and browser mix. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I know the result is not a cache artifact?
Record the origin response, purge only the affected paths, and repeat the test in a private session and a normal session. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version it contains.
What belongs in the evidence packet?
Keep UTC time, exact versions, fixture ID, role, browser, expected result, actual result, relevant response or log lines, change made, rollback point, owner, and final verification. Redact passwords, tokens, personal data, and private URLs.
When can I close the test?
Close it when the primary path and important failure branches pass, records reconcile across systems, accessibility and mobile checks are complete, temporary changes are removed, and monitoring covers the next update or business cycle.
What to tell the client or owner
Give the owner a short packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key evidence, change made, rollback point, unresolved risk, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP recover a WooCommerce gallery migration.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references