When a product collection repeats the surrounding product's title, check block context before editing product records. WooCommerce 11.3 beta changes how Single Product blocks pass context to descendants. A nested block should describe its own product without changing the product context used by unrelated siblings.
Use this on the beta available October 28, 2026. Build a disposable template on staging. This is not a reason to replace a working production theme or bulk-edit titles.
Make the wrong result unmistakable
Create products with deliberately distinct names, such as Fixture A Red, Fixture B Green and Fixture C Silver. Give each a different image and price. Keep a page title that names none of the products.
Put a Product block for A on the page. Inside it, place a Product Collection for B and C and a separate Product Title after the collection. Record what each location is intended to show. A visually plausible title is not enough; match it to a product ID.
The upstream context correction replaces descendant-name tracking with WordPress block context. Its scope includes nested Product, Collection and Query arrangements. Ordinary product editing is not the same contract as a custom PHP subclass that reaches into the former implementation.
Read the page by boundary
| Location |
Expected owner |
| Page heading outside products |
The page |
| Outer product title |
A |
| First collection item |
B |
| Second collection item |
C |
| Title after the nested collection |
A again |
Distinct product labels reveal context leakage that identical sample titles would hide.
Load the public preview, not only the editor canvas. Compare titles, product links, prices and images. An incorrect title with a correct link suggests a different rendering issue from a whole block that links to the wrong product.
Add a second Product block nested inside A and repeat the observation for the title after it. Then test consecutive Product blocks rather than nested ones. These cases catch both leakage into a child and failure to restore context for a sibling.
Identify custom dependencies
Search extension and theme code for extract_single_product_inner_block_names and custom subclasses of the Single Product block implementation. The beta removes protected implementation details. A developer who relied on those details should review the supported context path rather than copying the removed method into WooCommerce core.
Start with read-only searches and a PHP error log. Do not rename methods across the entire project without understanding their callers. If there is no custom subclass and no matching reference, focus on the actual nested template and active rendering extensions.
Keep a minimal failing pattern. Duplicate the affected template into a staging-only test and remove unrelated visual blocks one at a time. Preserve the original template so the test does not destroy the merchant's layout.
Separate context from cached markup
If the error occurs only on a public cached page, compare it with the current origin output using your normal host diagnostics. Confirm the cache is not serving an old template revision. If the wrong product appears in origin output too, repeated cache purges will not repair the context source.
Also compare a core-only staged template with the custom version. Document which extension or template change first introduces the mismatch. Do not claim a core regression solely because the issue appeared after an upgrade.
If the question is which Shop template is associated with the page rather than which product owns a nested title, use the archive-product metadata guide.
Approve the change only after every fixture location shows its intended product and links to that product. Share the minimal pattern, versions and expected-versus-actual map with WordPress block-theme support. That evidence is more useful than a screenshot containing several identically named demo products.
Sources checked October 28, 2026. Synthetic fixtures and diagrams illustrate the proposed checks; they are not claims of customer testing.