Full page cache doesn't work if there are stacks on the page1 user found helpful
I'm finding that full page caching is not working when I have a stack on the page. This is on 5.6.1
Is comsone able to confirm whether is a known issue, or if I should be doing something differently?
I haave tried the following...
- Create a new page. Enable full page caching if blocks support it.
- Clear cache.
- Load the page in a clean browser.
- Check the "full page caching" context menu on the sitemap and confirm the page is cached.
- Add a custom block to the page. This block has btCacheBlockRecord and btCacheBlockOutput enabled in the controller.
- Clear cache again.
- Confirm that caching is working.
- Delete the block I just added.
- Add a stack to the page - this stack contains one of the custom blocks (same type as above)
- Clear cache again.
- Now if I check the sitemap, the page has NOT been cached.
So it seems that any page containing a stack is excluded from the cache. Global areas seem to be fine - as my test page contains several global areas.
Does anyone have any insight on this, or possible workarounds? This is a high traffic site and we are relying on full page caching.
In order for Concrete5 to include your stack on a page where you have "placed" it, it actually inserts a block called CoreStackDisplay and tells that instance of the block which stack you want to display. Then, every time C5 renders that [helper] block, it goes and retrieves the stack's contents and outputs those.
Unfortunately for you, that block type (its handle is core_stack_display) is *not* configured to allow block caching, and with your [assumed] site-wide setting of "On - If blocks on the particular page allow it." for Full Page Caching, it gets to that block , sees that it doesn't allow itself to be cached, and decides *not* to cache it, and thus to *not* cache the page.
I have not taken the time to dive into that block's inner workings, so I can't authoritatively comment on whether the lack of caching support is *necessary* or not, but you and I have both experienced the major performance hit that can come from including stacks on pages. You can override the caching of pages either individually, or site-wide, by choosing "Cache this page" or "On - In all cases." respectively; however, this is something that should be done with great care, because overriding the request from individual blocks to not be cached can produce unexpected results, especially on more complex pages/sites.
To the Concrete5 team I would request a review of this behavior and an investigation to see if it can be altered in some or all cases to allow caching. Some theme designers do not include Global Areas in places where site managers need them, and the alternative is using Stacks and Page Type Defaults, but when it has such a potential HUGE impact on performance (since ALL pages displaying normal stacks will NOT be available for full page caching, unless overridden, which is dangerous), it becomes a difficult decision which has no really good answer. It is interesting to me that the "Global Areas" implementation uses stacks behind the scenes, and yet it does not seem to suffer from this same caching restriction... why is that? Can similar benefits be brought to the mainline stack world, so those of us who have to widely use stacks can still use the beloved Full Page Caching?
I worked around this by forcing the cache on, and turning off manually for pages I knew would cause problems. Obviously this solution isn't ideal, although it hasn't caused us any problems with the blocks we use (mostly custom blocks I wrote).
Yould be interesting to hear back from the core team if there is some fundamental reason why stacks can't be cached -0 if there isn't I'd be happy to explore this further and see if there's a mod that can be made.