Inherited Theme Layout Breaks After Parent Theme Update
Your team maintains a custom theme Acme/default that declares Acme/base as its parent. Acme/base was just updated by a vendor: it renamed Acme/base/layout/default.xml to Acme/base/layout/base.xml and moved several <referenceBlock> calls into a new Acme/base/layout/catalog_product_view.xml. After the update, your custom PDP template renders but the related-products block disappears, and the console shows no PHP errors. Your theme's catalog_product_view.xml still uses <referenceBlock name="product.info">. The site is on a multi-store setup with three store views, two of which use Acme/default and one that uses a separate theme. Static content deploy is run in production mode. You have 90 minutes before a flash sale.
1. Diagnose why the related-products block vanished and describe the fastest safe fix.
Read the worked answer
The symptom (template renders, block missing, no errors) points at layout XML merge, not PHP. The parent theme renamed its default layout file to base.xml. Magento merges layout files by handle name, not by file path, so base.xml is still loaded as the default handle - that part alone isn't the cause. The real cause is the referenceBlock calls moved into catalog_product_view.xml in the parent. If those calls referenced a block that your child theme's catalog_product_view.xml also references via <referenceBlock name="product.info">, merge order matters: child layout files load after parent, but only for the same handle. Your child catalog_product_view.xml is merged after the parent's, so a <referenceBlock name="product.info"> in your file that does not re-add the related block will not remove it - but if the parent moved the related block under a new container name (e.g. product.info.related), your child's override of product.info no longer contains it. Fastest safe fix: inspect the parent's new catalog_product_view.xml, find the new container name, and add a <referenceBlock name="<new name>"> in your child theme that re-declares the block with the original template. Verify with bin/magento cache:flush layout block_html full_page and a bin/magento dev:template-hints pass in a staging store view before deploying to production. Do not edit the vendor theme.
2. The third store view uses a different theme and is unaffected. What does that tell you about where to place the fix, and what is the deployment risk?
Read the worked answer
The third store view loads a different theme, so it never merges Acme/base's layout - confirming the fault is in the Acme/default inheritance chain, not in a shared module or the vendor's module-level layout. Place the fix in Acme/default, not Acme/base, so other themes inheriting Acme/base are untouched. Deployment risk: in production mode, layout XML changes require a static content deploy and cache flush; if you deploy only the child theme files without setup:static-content:deploy -f for the affected locales, the compiled layout may be stale. Also, setup:upgrade is not needed for layout-only changes, but any change to theme.xml parent declaration would be. Roll out to one store view first, smoke-test PDP related products, then to the second store view.