WooCommerce 11.1 updates is_rest_api_request() so requests using ?rest_route= are detected as REST requests, not only pretty /wp-json/ routes. This fixes a classification gap, but extensions that skip hooks, assets, authentication, caching, logging, or business logic when the helper returns true can now take a different branch for query-parameter requests.
Use this for WooCommerce sites and extensions that support plain permalinks, reverse proxies, security layers, application passwords, webhooks, custom REST routes, or request-context conditionals.
Quick answer
Build matched requests for /wp-json/wc/v3/... and /?rest_route=/wc/v3/... using the same method, credentials, body, user, and cache bypass. Record the helper result, route, response status, headers, body schema, database writes, hooks, logs, and cache behavior. Search extension code for is_rest_api_request(), REST_REQUEST, rest_route, wp_doing_ajax(), and front-end-only guards. Both URL shapes should execute the same intended REST contract without loading presentation code or skipping required services.
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 |
|---|
| Pretty route | GET /wp-json/wc/v3/orders | Expected auth and schema |
| Query route | GET /?rest_route=/wc/v3/orders | Same auth and schema |
| Write | Synthetic update by both shapes | One intended state change |
| Denied | Invalid credential | Same safe error class |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Map every request-context conditional and the business service it protects or skips. | Inventory extension conditionals that branch on WooCommerce or WordPress REST request detection. | Both URL shapes match the intended route, permissions, schema, and status. |
| Create matched route fixtures and record both helper and response behavior. | Send matched GET, POST, authenticated, anonymous, valid, invalid, and permission-denied requests through both URL shapes. | Writes, hooks, emails, and webhooks happen exactly once where expected. |
| Move required services out of presentation-only guards and align proxy cache rules. | Compare route matching, authentication, nonce or application password behavior, cache headers, hooks, writes, and response schema. | CDN, WAF, and page-cache rules do not cache authenticated REST data. |
| Retest permissions, writes, webhooks, errors, and rate limits for both shapes. | Inspect CDN, WAF, page cache, and security plugin handling for the query-parameter route. | Front-end presentation assets remain separate from REST business services. |
What to check first
- Inventory extension conditionals that branch on WooCommerce or WordPress REST request detection.
- Send matched GET, POST, authenticated, anonymous, valid, invalid, and permission-denied requests through both URL shapes.
- Compare route matching, authentication, nonce or application password behavior, cache headers, hooks, writes, and response schema.
- Inspect CDN, WAF, page cache, and security plugin handling for the query-parameter route.
- Verify front-end assets stay unloaded while required inventory, order, email, and webhook services still execute.
Field notes
- Use synthetic IDs and examples that can be traced from the first request or interaction to the final record.
- Keep a before and after result for every changed setting, package, selector, route, or deployed version.
- Separate user-visible success from internal success so a green interface cannot hide a failed request or inaccessible control.
- Review the evidence again after caches, queues, browser history, and scheduled work have had time to settle.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sS -u ck_test:cs_test 'https://store.example/wp-json/wc/v3/orders?per_page=1'
curl -sS -u ck_test:cs_test 'https://store.example/?rest_route=/wc/v3/orders&per_page=1'
# Search request-context branches
rg "is_rest_api_request|REST_REQUEST|rest_route|wp_doing_ajax" wp-content/plugins
Why this usually happens
- An extension treats every non-REST request as a front-end page and loads presentation hooks.
- A cache rule keys on /wp-json/ but ignores the rest_route query parameter.
- A security plugin applies different authentication or rate limits to the two shapes.
- Required business services were incorrectly placed behind a negative REST check.
Decision rule
Approve WooCommerce 11.1 only when pretty and query-parameter routes produce the same intended REST contract, no sensitive response is cached, and no required business service is skipped by the corrected helper result.
Production verification checklist
- Both URL shapes match the intended route, permissions, schema, and status.
- Writes, hooks, emails, and webhooks happen exactly once where expected.
- CDN, WAF, and page-cache rules do not cache authenticated REST data.
- Front-end presentation assets remain separate from REST business services.
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.
- Map every request-context conditional and the business service it protects or skips.
- Create matched route fixtures and record both helper and response behavior.
- Move required services out of presentation-only guards and align proxy cache rules.
- Retest permissions, writes, webhooks, errors, and rate limits for both shapes.
- Ship with request-context logging and an owned rollback for affected extensions.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, settings, stable fixture IDs, and a reproducible baseline.
- Treating one successful screen as proof that keyboard access, APIs, caches, jobs, reports, analytics, and downstream records agree.
- Testing only an administrator session instead of the devices, roles, networks, consent states, and failure branches customers use.
- Closing the work without a named owner, rollback point, observation window, and contextual incoming link from an established guide.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only checks and one narrow synthetic fixture that cannot charge a card, send real customer email, expose personal data, or change inventory. Run upgrades, package changes, cache changes, and destructive repairs on staging first.
What evidence should the test report keep?
Keep exact versions, UTC timestamps, stable synthetic IDs, expected and actual results, screenshots or response excerpts, the decision owner, rollback point, and final verification. Redact credentials, tokens, customer data, private addresses, and infrastructure details.
How long should the observation window stay open?
Keep it open long enough to include at least one cache cycle, scheduled job cycle, and representative traffic period. For release changes, include both logged-in and logged-out use plus the first real operational handoff.
When is the task complete?
Complete it when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to this guide in context.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window remains open.
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, audit a WooCommerce REST integration.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Align rest_route classification with WAF and cache behavior
After origin route parity passes, run the WooCommerce 11.1 rest_route WAF cache test to prove authenticated bodies cannot enter shared caches and distinct query routes keep distinct edge keys.
Helpful references