WooCommerce 11.0.1 adjusts Store API error notice handling so entity-encoded HTML does not become unsafe rendered markup. Custom gateways, shipping extensions, coupon validators, and checkout integrations can still return strings containing tags, entities, links, or user-controlled values. The test must inspect the JSON response and final DOM, not only the visible sentence.
Use this for Cart and Checkout Blocks, Store API clients, custom checkout notices, payment gateway errors, coupon messages, and extensions that return HTML-like error content.
Quick answer
Create controlled errors containing plain text, approved entities, harmless tags, links, script tags, event handlers, and user-controlled fragments. Capture the Store API JSON exactly, then inspect textContent, innerHTML, DOM nodes, CSP reports, console messages, and screen-reader announcement. The customer should receive a useful message while no supplied markup executes or creates unapproved elements.
What to check first
- Inventory custom Store API errors, gateway messages, coupon errors, shipping notices, and extension filters that can reach cart or checkout UI.
- Build a staging fixture with plain text, encoded tags, nested entities, links, event handlers, script tags, and a unique execution canary.
- Save the raw JSON response, decoded application value, rendered innerHTML, textContent, DOM tree, console, and CSP reports.
- Test Cart Block, Checkout Block, mini-cart, shortcode fallback, and any headless client that renders the same errors.
- Check readable wording, keyboard focus, live-region announcement, localization, and whether safe support links have an approved separate rendering path.
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 |
|---|
| Plain text | Declined card message | Readable text is announced once |
| Encoded tag | Encoded bold label | Readable text appears with no injected node |
| Script canary | Encoded image handler | No execution, request, node, or console canary |
| User value | Coupon label with markup | Value is escaped in JSON and DOM output |
Decision rule
Approve when every fixture produces understandable customer text, unsafe input creates no executable DOM or network effect, and assistive technology receives the error exactly once.
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.
- Keep error data as text through the Store API contract.
- Render customer notices with text-safe APIs instead of raw HTML insertion.
- Create a separate allowlisted component for any approved support link.
- Patch extensions that return markup or unsanitized user values.
- Repeat JSON, DOM, execution, accessibility, and localization tests.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Keep error data as text through the Store API contract. | Inventory custom Store API errors, gateway messages, coupon errors, shipping notices, and extension filters that can reach cart or checkout UI. | Raw Store API JSON preserves a predictable text contract. |
| Render customer notices with text-safe APIs instead of raw HTML insertion. | Build a staging fixture with plain text, encoded tags, nested entities, links, event handlers, script tags, and a unique execution canary. | No script, event handler, unsafe URL, or unapproved element appears in the DOM. |
| Create a separate allowlisted component for any approved support link. | Save the raw JSON response, decoded application value, rendered innerHTML, textContent, DOM tree, console, and CSP reports. | Plain and translated errors remain readable and actionable. |
| Patch extensions that return markup or unsanitized user values. | Test Cart Block, Checkout Block, mini-cart, shortcode fallback, and any headless client that renders the same errors. | Cart, checkout, mini-cart, fallback, and headless clients enforce equivalent safety. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
fixture,json_value,dom_nodes,text_content,canary,screen_reader
plain,Payment declined,0,Payment declined,quiet,announced
encoded,<strong>Retry</strong>,0,<strong>Retry</strong>,quiet,announced
script,<img onerror=CANARY>,0,<img onerror=CANARY>,quiet,announced
Production verification checklist
- Raw Store API JSON preserves a predictable text contract.
- No script, event handler, unsafe URL, or unapproved element appears in the DOM.
- Plain and translated errors remain readable and actionable.
- Cart, checkout, mini-cart, fallback, and headless clients enforce equivalent safety.
Why this usually happens
- An error can be encoded by the server and decoded again by a client framework before insertion into the DOM.
- Extensions may assume notices support arbitrary HTML because older shortcode templates allowed limited markup.
- A visible message can look safe while hidden nodes, event handlers, or malformed attributes remain in the DOM.
Field notes
- Run malicious fixtures only on isolated staging with a non-sensitive test account.
- Use a unique canary that records any attempted execution without contacting an external domain.
- Preserve the exact raw and decoded strings because screenshots hide entity transformations.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not use a successful status or screen message as the only proof. Verify the business outcome and the underlying record.
- Do not leave debug logging, broad credentials, test orders, or temporary exceptions active after the review.
- Do not close the incident without recording the fixture, 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, and integrations. Finish with one controlled production fixture when the result depends on real routing, provider, or edge behavior.
What evidence should be retained?
Keep the smallest useful set: stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, version inventory, and the final verification.
When should the change be rolled back?
Roll back when a revenue, privacy, security, or publishing path fails and the cause cannot be isolated inside the approved maintenance window.
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, test WooCommerce checkout notice safety.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references