The Disappearing Category Description After a Theme Switch
A merchant on Adobe Commerce 2.4.6 runs a custom child theme of Magento/luma. Category pages show a rich HTML description rendered by a custom block in Magento_Catalog/templates/category/description.phtml, which the theme overrides. After the merchant installs a second theme (Vendor/newtheme, a child of Magento/blank) and assigns it to one store view, category descriptions vanish on that store view only, while the default store view still renders them. The new theme's theme.xml declares <parent>Magento/blank</parent>. The developer confirms the description attribute is populated and Is HTML is enabled. No PHP errors appear; the page simply omits the block. The block is inserted via a layout handle in the original theme's Magento_Catalog/layout/catalog_category_view.xml.
1. Diagnose why the description block disappears on the new store view and describe the mechanism that decides which layout and template files win.
Read the worked answer
The custom block is inserted by a layout file that lives only in the original theme's directory tree. Layout XML is resolved by walking the theme fallback chain from the most specific theme to its ancestors and finally to the module's own view/frontend/layout files. Because Vendor/newtheme inherits from Magento/blank, not from the original child theme, the original theme's catalog_category_view.xml is not in the fallback chain for that store view - so the block insertion never happens, and the .phtml override is likewise never reached.
Key reasoning: themes are selected per store view (Configuration > Design), and the entire layout/template resolution is relative to the active theme's inheritance chain. A sibling child theme does not inherit from another sibling. The fix is to move the layout insertion and template into a shared custom module's view/frontend (module-level layout is always merged regardless of theme), or make the new theme a child of the original theme. Simply copying the .phtml into the new theme is insufficient because the layout handle that adds the block is still missing.
2. The developer wants both themes to share the block without duplicating files. What is the correct architectural placement, and what are the trade-offs?
Read the worked answer
Place the block declaration and its template in a custom module (Vendor_CategoryExtras):
view/frontend/layout/catalog_category_view.xmladds the block via<referenceContainer>or<referenceBlock>.view/frontend/templates/category/description.phtmlholds the markup.
Module layout and templates are merged into every theme's resolution, so both store views get the block. Trade-offs: (1) it is now active on all themes, so guard with ifconfig or a layout condition if a theme must opt out; (2) styling that was theme-specific must move into each theme's CSS rather than the template; (3) if a theme wants to override the template it still can, because theme templates take precedence over module templates in the fallback chain. This preserves single-source-of-truth for behavior while keeping presentation themeable.