Layout Cache Serving Stale Blocks Across Store Views
A merchant runs Adobe Commerce 2.4.6 in production mode with a two-store-view setup (default and a fr store view). A developer adds a CMS block to the footer via a layout update in cms_index_index.xml for the default store view only, using <referenceContainer name="footer">. After deploying, the block appears on the default store view but also appears on the fr store view, even though the layout update was scoped to the default store. The developer clears the config cache, but the block persists on fr. Separately, a CSS change to a theme file does not appear until setup:static-content:deploy is re-run. The deployment pipeline runs bin/magento cache:flush but not cache:clean, and static content is deployed without -f.
1. Why does the footer block appear on the `fr` store view, and how does layout caching interact with store scoping?
Read the worked answer
Layout XML from cms_index_index.xml is not automatically store-scoped unless the block itself is conditioned on store. A <referenceContainer> insertion applies to the layout handle for all store views that render that handle; the layout cache is keyed by handle and area, not by store view by default. To scope a block to one store view you must either:
- wrap the block in a
<block>with anifconfigcondition tied to a store-scoped config path, or - declare the layout update in a store-specific context (e.g., a widget/CMS directive scoped to the store), or
- use a block that checks the current store in its template/
_toHtml.
The developer also used cache:flush, which clears the storage backend but does not invalidate by cache type/tag in the same way cache:clean does; combined with production mode, stale layout cache can persist. cache:clean layout (or cache:flush followed by verifying the layout cache type is enabled) is required for the new layout to take effect. The block appearing on fr is therefore a combination of unscoped layout insertion plus stale layout cache.
2. What is the correct deployment sequence for both the layout change and the CSS change, and why does `cache:flush` alone not fix the CSS?
Read the worked answer
Static content (CSS/JS) in production mode is pre-generated into pub/static per theme and locale. Editing a .less/.css source file does nothing until bin/magento setup:static-content:deploy regenerates the published assets. Without -f (force), the deploy command skips files it believes are already deployed, so the change may not be picked up. Use setup:static-content:deploy -f (and specify locales such as en_US fr_FR if needed).
Correct sequence:
bin/magento setup:upgrade(if schema/data changed).bin/magento setup:di:compile(production mode).bin/magento setup:static-content:deploy -f <locales>.bin/magento cache:clean(orcache:flush), then verify the layout cache type.
cache:flush clears the cache storage but does not regenerate static assets - CSS lives on disk in pub/static, not in the cache. That is why flushing alone leaves the old CSS. Also ensure the web server serves the regenerated pub/static and that MAGE_MODE is production.