WooCommerce 11.1 retires stable WooCommerce Admin flags from core.json, development.json, and the normal window.wcAdminFeatures source of truth. Features remain available and compatibility shims exist, but an extension may still hide UI, skip setup, branch data migrations, or run tests based on a flag that no longer owns availability.
Use this for extensions, themes, deployment scripts, end-to-end tests, and support runbooks that read WooCommerce Admin feature flags.
Quick answer
Search PHP, JavaScript, templates, tests, build artifacts, deployment configuration, and support docs for every retired flag named by the advisory. For each read, classify whether the code asks about availability, rollout, experimentation, migration, UI visibility, or test setup. Replace the retired switch with the documented stable behavior or a capability check owned by the extension. Test with shims present, with deprecation logging enabled, and in a harness where the old flag source is absent. Do not reintroduce a private copy of core.json as an application switch.
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 |
|---|
| PHP shim | Features check | Deprecation found and mapped |
| JavaScript shim | wcAdminFeatures read | Owned branch removed |
| Old source absent | Test harness | Stable UI still works |
| Restricted role | Shop manager | Capability controls visibility |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| List retired names | Inventory Features::is_enabled, Features::exists, window.wcAdminFeatures, configuration files, selectors, snapshots, fixtures, mocks, and documentation that mention retired names. | Every retired flag consumer has an owner and replacement. |
| Find every consumer | Classify each use as a visibility guard, experiment, migration gate, capability check, test condition, telemetry dimension, or dead code. | No permission decision relies on feature configuration. |
| Classify the decision | Turn on deprecation logging in staging and capture call sites with package version, route, user role, and feature name. | Core screens and extension screens work without the old source. |
| Replace owned branches | Run setup wizard, home screen, analytics, marketing, product editing, orders, settings, onboarding, and extension screens with the old source removed from the test harness. | Deprecation logs and test fixtures no longer hide stale branches. |
What to check first
- Inventory Features::is_enabled, Features::exists, window.wcAdminFeatures, configuration files, selectors, snapshots, fixtures, mocks, and documentation that mention retired names.
- Classify each use as a visibility guard, experiment, migration gate, capability check, test condition, telemetry dimension, or dead code.
- Turn on deprecation logging in staging and capture call sites with package version, route, user role, and feature name.
- Run setup wizard, home screen, analytics, marketing, product editing, orders, settings, onboarding, and extension screens with the old source removed from the test harness.
- Replace owned branches with stable behavior or an explicit extension capability, then remove stale fixtures and update support diagnostics.
Field notes
- Write the expected result before changing anything and keep one repeatable synthetic fixture for the full test window.
- Record exact versions and UTC timestamps because caches, retries, scheduled actions, and deployments can change the evidence between checks.
- Test the public path and the stored server-side result, not only an admin preview, isolated command, or API response.
- Review the result again after the relevant cache, queue, cron, webhook, and observation window has completed.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
rg -n "Features::(is_enabled|exists)|wcAdminFeatures|core.json|development.json" wp-content/plugins wp-content/themes
# Map each hit to availability, rollout, migration, UI, test, or dead code.
Why this usually happens
- An experiment flag became stable but extension code kept the rollout branch.
- Tests mock window.wcAdminFeatures and never exercise the source-free state.
- A flag check is used as authorization instead of a user capability.
- A copied configuration file silently becomes an unsupported source of truth.
Decision rule
Approve the extension only when no business or permission decision depends on a retired flag, deprecation logs are understood, and stable behavior works when the old configuration source is absent.
Production verification checklist
- Every retired flag consumer has an owner and replacement.
- No permission decision relies on feature configuration.
- Core screens and extension screens work without the old source.
- Deprecation logs and test fixtures no longer hide stale branches.
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.
- List retired names
- Find every consumer
- Classify the decision
- Replace owned branches
- Test without the old source
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, a stable fixture, the expected result, and a tested rollback point.
- Treating one successful screen as proof while logs, stored records, background jobs, caches, emails, APIs, and downstream systems remain unchecked.
- Testing only as an administrator instead of using the role, device, locale, cache state, request path, and failure branch that users actually reach.
- Leaving debug output, temporary exclusions, helper accounts, duplicate hooks, broad permissions, or relaxed firewall rules active after verification.
Questions teams ask during testing
Can I test this directly in production?
Start with read-only evidence. Use staging for code, package, security, checkout, form, privacy, or cache changes. If a production canary is necessary, make it identifiable, reversible, monitored, and incapable of exposing personal data or charging a customer.
How do I avoid a false positive?
Repeat the same fixture with the same versions, URL, role, locale, cache state, and downstream integration. Compare the public result, stored result, and logs instead of relying on one browser view.
What evidence should I retain?
Keep UTC time, exact versions, request or record ID, expected result, actual result, relevant log lines, change made, rollback point, owner, and final verification. Redact credentials, tokens, and personal data.
When is the work complete?
Close it when the primary path passes, failure branches are understood, stored and downstream records reconcile, temporary changes are removed, monitoring is active, and the owner has the evidence packet.
What to tell the client or owner
Give the owner a concise packet with the affected workflow, exact versions, UTC test time, synthetic fixture ID, expected result, actual result, key logs, change made, rollback point, final result, unresolved risks, 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 audit a WooCommerce extension.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Scan extension literals during the same upgrade
Once retired feature flags are removed, continue the code review with the WooCommerce 11.1 enum and magic-string scan. It maps order, product, stock, payment, and settings literals to public constants while preserving old-version compatibility and exact stored values.
Helpful references