WooCommerce 11.0.1 includes permission-related fixes for product featured images and SKU handling. A store can react in two bad ways: keep excessive capabilities because the workflow still works, or remove so much access that catalog teams cannot update products. The correct test uses real roles and checks both allowed and denied operations across simple products, variations, REST, imports, and media ownership.
Use this for stores with Shop Managers, catalog editors, vendor roles, marketplace plugins, ERP imports, custom REST users, or agencies that separate product work from full administration.
Quick answer
Create role fixtures that mirror production, then test create and update operations for featured image, gallery, parent SKU, variation SKU, duplicate SKU, media ownership, and unrelated settings. Approved catalog roles should complete only their assigned product operations. Lower-privilege and cross-owner fixtures should fail without partial metadata, orphaned media, cache changes, or sensitive error details.
What to check first
- Export current roles, capabilities, user owners, REST credentials, import identities, and custom authorization filters.
- Create simple, variable, draft, private, and published product fixtures with stable SKUs and known media attachments.
- Test featured image, gallery, parent SKU, variation SKU, duplicate SKU, removal, replacement, and bulk import operations.
- Capture wp-admin, REST, database metadata, media ownership, revision, audit log, cache, and frontend output.
- Repeat with Administrator, Shop Manager, catalog editor, vendor, customer, expired credential, and unrelated-owner fixtures.
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 |
|---|
| Shop Manager | Update featured image and unique SKU | Allowed with correct audit owner |
| Catalog editor | Approved product fields only | Allowed within written scope |
| Customer | REST product update | Denied without partial change |
| Duplicate SKU | Variation conflicts with existing product | Rejected with useful private error |
Decision rule
Approve when every intended role can complete its assigned product and media work, every denied role leaves product and media state unchanged, duplicate SKU rules remain intact, and audit evidence identifies the real actor.
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.
- Define a written catalog-operation matrix before changing capabilities.
- Grant the smallest product and media capabilities required by each human and service role.
- Correct REST, import, custom-filter, or ownership checks at the layer that made the wrong decision.
- Remove partial metadata and orphaned test media after preserving evidence.
- Automate allowed and denied product fixtures for each WooCommerce release.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Define a written catalog-operation matrix before changing capabilities. | Export current roles, capabilities, user owners, REST credentials, import identities, and custom authorization filters. | Approved roles update only the intended image and SKU fields. |
| Grant the smallest product and media capabilities required by each human and service role. | Create simple, variable, draft, private, and published product fixtures with stable SKUs and known media attachments. | Denied and cross-owner requests create no partial metadata, attachment, revision, or cache change. |
| Correct REST, import, custom-filter, or ownership checks at the layer that made the wrong decision. | Test featured image, gallery, parent SKU, variation SKU, duplicate SKU, removal, replacement, and bulk import operations. | Simple, variable, draft, private, REST, import, and bulk paths follow the same capability policy. |
| Remove partial metadata and orphaned test media after preserving evidence. | Capture wp-admin, REST, database metadata, media ownership, revision, audit log, cache, and frontend output. | Audit logs distinguish human users, service identities, and failed attempts. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
role,operation,product,expected,metadata,media,cache,result
shop_manager,set_image,fixture-simple,allow,changed,owned,purged,pass
catalog_editor,set_sku,fixture-simple,allow,changed,none,purged,pass
customer,set_image,fixture-simple,deny,unchanged,none,unchanged,pass
shop_manager,duplicate_sku,fixture-var,deny,unchanged,none,unchanged,pass
Production verification checklist
- Approved roles update only the intended image and SKU fields.
- Denied and cross-owner requests create no partial metadata, attachment, revision, or cache change.
- Simple, variable, draft, private, REST, import, and bulk paths follow the same capability policy.
- Audit logs distinguish human users, service identities, and failed attempts.
Why this usually happens
- Custom roles copy broad capabilities from Shop Manager and retain powers no longer required.
- Media attachment permissions, product permissions, and REST authentication are checked at different layers.
- Bulk imports and headless catalog tools can use a privileged service identity that hides what normal staff can do.
Field notes
- Do not use live products, customer-visible SKUs, or licensed product images for destructive fixtures.
- Delete orphaned test media and invalidate only the affected product cache after evidence is retained.
- Keep the API identity distinct from human accounts so audit records remain useful.
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 green screen, successful request, or quiet log as proof that the customer outcome is correct.
- Do not leave debug logs, broad credentials, test orders, temporary roles, or firewall exceptions active after verification.
- Do not close the work without recording versions, fixture IDs, UTC timestamps, owner, result, and rollback point.
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.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, cache, data shape, roles, integrations, and server packages. Finish with one controlled production fixture when the result depends on real email routing, edge cache, crawler access, payment callbacks, or advertising diagnostics.
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, secrets, order keys, and full click identifiers.
When should the change be rolled back?
Roll back when a revenue, privacy, 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.
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, review WooCommerce catalog permissions.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references