bka
commented
7 years ago Ok, I did some debugging. It seems to only affect CMS pages and is related to the way how Magento_PageCache module works. This module renders a script into the DOM to fetch some blocks asynchronously.
<script type="text/x-magento-init">
{
"body": {
"pageCache": {"url":"http:\/\/magento2.local\/index.php\/page_cache\/block\/render\/","handles":["default","cms_index_index","cms_page_view","cms_index_index_id_home"],"originalRequest":{"route":"cms","controller":"index","action":"index","uri":"\/index.php\/"},"versionCookieName":"private_content_version"} }
}
</script>This is done in PageCache/view/frontend/web/js/page-cache.js. This call hits PageCache/Controller/Block/Render.php and PageCache/Controller/Block.php:_getBlocks triggers the loading of the layout:
$this->_view->loadLayout($handles, true, true, false);However, because of the way how lib/internal/Magento/Framework/View/Model/Layout/Merge.php:_fetchRecursiveUpdates works, the pageLayout will be set to admin-1column defined in app/code/Magento/Theme/view/adminhtml/page_layout/admin-1column.xml. Unfortunately, in this case lib/internal/Magento/Framework/View/Page/Layout/Reader.php:read just gets an empty layout <layout/> for $xml.
public function read(Layout\Reader\Context $readerContext, $pageLayout)
{
$this->getPageLayoutMerge()->load($pageLayout);
$xml = $this->getPageLayoutMerge()->asSimplexml();
$this->reader->interpret($readerContext, $xml);
}I think the layout is not loaded because our area in this case is frontend not adminhtml. So this layout won't be loaded in this case. And therefore there are some critical elements missing inside scheduledStructure afterwards, like e.g. the root container.
Now, the bad thing happens. This structure gets stored into the cache, if there is none. This is done in lib/internal/Magento/Framework/View/Layout.php:generateElements.
$cacheId = 'structure_' . $this->getUpdate()->getCacheId();
$result = $this->cache->load($cacheId);
if ($result) {
$this->readerContext = unserialize($result);
} else {
\Magento\Framework\Profiler::start('build_structure');
$this->readerPool->interpret($this->getReaderContext(), $this->getNode());
\Magento\Framework\Profiler::stop('build_structure');
$this->cache->save(serialize($this->getReaderContext()), $cacheId, $this->getUpdate()->getHandles());
}The $cacheId will be the same as for a normal request because it is based on used handles. But remember, we have missing elements in the structure like root. Next time, somebody visits the page, he will get a blank page without body, because this broken layout structure has been loaded from the cache.
For normal requests on CMS pages, this is not happening, because the controller sets the pageLayout explicitly in app/code/Magento/Cms/Helper/Page.php:setLayoutType before the layout is loaded. This is usually 1column defined in app/code/Magento/Theme/view/frontend/page_layout/1column.xml and can then easily be loaded by lib/internal/Magento/Framework/View/Page/Layout/Reader.php.
I would really appreciate any advice on how to fix this.
erikhansen
andreymoskvenkov
cherreman
miguelbalparda
adrian-martinez-interactiv4
renttek
fabianPas
maksek
hostep
magento-team
magento-engcom-team
Hi folks,
I disovered a potential bug regarding the layout cache which leads to a blank page. If this happens, customers may see a white page without any hmtl inside the body tags. It might be related to #6942, although there is no php-fpm or libxml in the game here.
Preconditions
Steps to reproduce
bin/magento cache:cleancurl -gI "http://magento2.local/page_cache/block/render/?ajax=1&blocks=[%22header.login%22]&handles=[%22default%22%2C%22cms_index_index%22%2C%22cms_page_view%22%2C%22cms_index_index_id_home%22]&originalRequest=a&version="curl -s http://magento2.local | grep "<body" -A 3 -B 3Expected result
Actual result
Discussion
This ajax call seems to destroy the layout cache. If it is not present, structure which gets loaded and unserialized in lib/internal/Magento/Framework/View/Layout.php:generateElements from cache does not contain any root element anymore:
Cleaning the cache again and loading the front page normally generates a valid layout cache, where root is present:
I think it has something do to with the used handles
[default, cms_index_index, cms_page_view, cms_index_index_id_home]which are used for generating the cache key ingetCacheId. If there is no cache present, the page cache block just writes its content into the layout cache although there is no root layout used.I need to dive deeper into this issue. It normally should not happen, because the DOM should get loaded first. And subsequent ajax calls should always have a layout cache present. But if cache gets cleared manually and there is already an ajax call on its way it can lead to a broken layout cache.