WooCommerce 11.0.1 tightens the permission required when setting a featured image by SKU. Stores may still have several importers creating or updating the same product or variation concurrently. Without a stable source key, lock, ownership rule, and replay policy, parallel jobs can collide on SKUs, attach images to the wrong product, overwrite fields, or report success after only part of the catalog change completes.
Use this for WooCommerce catalogs synchronized by ERP, PIM, CSV, REST API, WP-CLI, marketplace feeds, supplier jobs, or separate product and image workers.
Quick answer
Build a non-sale fixture with one product SKU and variation SKUs. Start two import workers with the same source version, then repeat with conflicting versions, delayed image work, a retry, and a user missing edit_product. Join source record, idempotency key, lock owner, product ID, variation ID, SKU, image ID, version, and result. Only the newest authorized source version should own the final catalog state.
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 |
|---|
| Same version | Two workers import identical SKU | One final product and idempotent replay |
| Conflicting version | Older worker finishes last | Newer version remains authoritative |
| Image worker | Featured image set by SKU | Authorized product receives correct image |
| Variation collision | Parent and child jobs overlap | Unique SKUs and complete parent relationship |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Choose a stable source identifier and version for every catalog object. | Inventory every process that can create products, variations, SKUs, featured images, gallery images, stock, price, or attributes. | Each fixture SKU maps to one intended product or variation. |
| Serialize or conditionally lock create and update work by source object or SKU. | Define one immutable source ID, version, idempotency key, lock scope, ownership rule, and replay window. | Older jobs cannot overwrite a newer source version. |
| Reject stale versions and make retries idempotent across product, variation, and image stages. | Create product, variation, image, permission-denied, stale-version, and partial-failure fixtures outside the sellable catalog. | Featured images require the approved capability and attach to the correct product. |
| Require edit_product for image-by-SKU operations and log the acting identity. | Capture database writes, WooCommerce logs, Action Scheduler records, REST responses, product IDs, image IDs, and cache invalidations. | Retries, rollback, cache, and catalog search all show the same final state. |
What to check first
- Inventory every process that can create products, variations, SKUs, featured images, gallery images, stock, price, or attributes.
- Define one immutable source ID, version, idempotency key, lock scope, ownership rule, and replay window.
- Create product, variation, image, permission-denied, stale-version, and partial-failure fixtures outside the sellable catalog.
- Capture database writes, WooCommerce logs, Action Scheduler records, REST responses, product IDs, image IDs, and cache invalidations.
- Verify rollback and retry behavior when one worker completes product data but another fails image or variation work.
Field notes
- Use hidden or non-purchasable fixtures so race tests cannot affect live orders.
- Do not solve duplicate SKUs by silently appending random suffixes.
- Keep source-system ownership explicit for fields that merchants may also edit manually.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
job,source_id,version,sku,lock,product_id,image_id,result
a,erp-882,41,TEST-882,won,44120,7102,committed
b,erp-882,41,TEST-882,replay,44120,7102,idempotent
c,erp-882,40,TEST-882,stale,44120,,rejected
Why this usually happens
- SKU lookup and product creation can be separate operations with a race between them.
- Image, stock, and variation jobs may use different queues and complete out of order.
- A 200 response can represent an accepted partial job rather than a committed catalog transaction.
Decision rule
Approve when repeated and parallel imports converge on one authorized product state without duplicate SKU, stale overwrite, wrong image, orphaned variation, or hidden partial failure.
Production verification checklist
- Each fixture SKU maps to one intended product or variation.
- Older jobs cannot overwrite a newer source version.
- Featured images require the approved capability and attach to the correct product.
- Retries, rollback, cache, and catalog search all show the same final state.
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.
- Choose a stable source identifier and version for every catalog object.
- Serialize or conditionally lock create and update work by source object or SKU.
- Reject stale versions and make retries idempotent across product, variation, and image stages.
- Require edit_product for image-by-SKU operations and log the acting identity.
- Reconcile duplicate, orphaned, and partially updated fixtures before enabling the production schedule.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not treat a successful request, quiet log, or correct screenshot as proof that the complete user outcome is correct.
- Do not leave debug logs, test records, broad credentials, temporary roles, or browser overrides active after verification.
- Do not close the work without recording versions, fixture IDs, UTC timestamps, owner, result, and rollback point.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, roles, data volume, browser behavior, cache, and integrations. Finish with one controlled production fixture when the result depends on the real CDN, email route, worker clock, crawler response, or browser storage.
What evidence should be retained?
Keep the smallest useful evidence set: exact versions, stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, decision, and final verification. Redact customer data, cookies, secrets, order keys, and full advertising identifiers.
When should the change be rolled back?
Roll back when a revenue, privacy, accessibility, security, publishing, or lead path fails and the cause cannot be isolated inside the approved maintenance window. Preserve the failed fixture before rollback so the next attempt starts with facts.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
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, repair a WooCommerce catalog import.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references