In WooCommerce 11.3 testing, a Shop page can report archive-product for its _wp_page_template value even when a different template assignment remains stored. For block themes, this can be intentional. Do not overwrite the database or repeatedly restore the old value before identifying whether your integration reads saved metadata or the effective filtered value.
October 27, 2026 release status: 11.3 is beta software. The procedure below belongs on staging. A release preview is not a reason to change a working live store's theme.
Confirm that this is the assigned Shop page
Find the page actually assigned as Shop in WooCommerce settings. A page called Shop is not necessarily the assigned page, and a translated or duplicate page can make a comparison misleading. Record its ID and public URL.
Check whether the active theme is a block theme. The 11.3 advisory describes the Product Catalog association in that context. A classic theme or an unrelated page needs its own diagnosis rather than this explanation being applied universally.
Write down the symptom precisely: an editor preview changed, a synchronization job detected a different value, a custom template disappeared visually, or the public storefront actually changed. Those observations need different evidence.
Compare three layers without writing anything
The first layer is the saved assignment. The second is what WordPress returns when an integration asks for template metadata. The third is the HTML and layout a shopper receives. A change in the second layer does not prove the first was erased or that the third is broken.
On an authorized staging installation with WP-CLI, this read-only diagnostic uses the public WordPress accessor:
wp eval '$id = wc_get_page_id("shop"); echo "Shop ID: " . $id . PHP_EOL; echo "Effective template: " . get_post_meta($id, "_wp_page_template", true) . PHP_EOL;'
This reports the effective value returned by the accessor. It is not a raw database inspection and must not be described as proof of the stored value. Ask a developer to inspect the saved record separately if that distinction matters to a migration or synchronization tool.
Three-layer diagnostic: saved template metadata, effective API value and rendered storefront must be inspected separately. No database overwrite is implied.
Audit synchronization before it writes back
Search custom code for _wp_page_template and for the REST template field. Find jobs that compare source and destination values and automatically write whichever one appears different. Put that job into its supported preview or dry-run mode on staging before testing the upgrade.
For each comparison, record whether the business intends to synchronize the saved preference, the effective template or a rendered design. A loop can arise when a process writes a saved value and then treats a filtered read as evidence that its write failed. Increasing retry frequency makes that situation noisier without clarifying it.
Use a synthetic record in the test log: page ID, theme type, saved assignment, effective result and proposed write. Do not include unpublished page content or private customer information. Require a human review of unexpected template writes until the integration's contract is clear.
Rehearse a route matrix
| Route or condition |
What to compare |
| Assigned Shop with block theme |
Catalog preview, effective template and public product grid |
| Ordinary content page |
Its own template assignment and rendered layout |
| Product category |
Category heading, pagination and filtering |
| Single product |
Product layout, options and cart interaction |
| Shop as homepage, if used |
Homepage routing, canonical URL and catalog layout |
Check these with both an administrator preview and a logged-out storefront visit. Cached HTML can hide a template change from one view. Preserve a screenshot and the route for any difference, then identify which layer changed before clearing unrelated caches.
This is separate from the older Shop queried-object change. A callback that assumes a WP_Post_Type object has a different failure mode from a synchronization job that assumes a saved template value will always be returned unchanged.
Repair the assumption at its owner
If the public catalog is correct and only the integration flags a mismatch, fix its comparison semantics instead of forcing the storefront back to an old metadata value. If the catalog genuinely loses required elements, identify the template or extension responsible and prepare the smallest reproducible staging case.
Avoid editing WooCommerce core or issuing direct SQL updates as a generic fix. A plugin-specific compatibility change should be reviewed with the plugin maintainer, including the active theme and exact build. Keep backups of the original template configuration before testing any write operation.
If the template is correct but products are absent, follow the catalog visibility checks. For a broader template or synchronization conflict, get HandL WP troubleshooting help with the three-layer comparison. Retest against the final supported release before approving a live rollout.
Sources checked October 27, 2026. Procedures and synthetic diagrams are explanatory, not claims of customer testing.
If the correct catalog template loads but nested product details belong to the wrong item, inspect block context next: WooCommerce 11.3 Nested Product Blocks: Check the Title Belongs to the Right Product.
Once the catalog template is correct, test Featured Category presentation independently: WooCommerce 11.3 Featured Category Styles: Check Editor and Storefront Parity.