Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Problem with 'uncached' inside a Layout?

Go to End

6 Posts   1509 Views


Community Member, 102 Posts

27 September 2011 at 7:52pm

Edited: 27/09/2011 8:29pm

Partial cacheing:

The uncached tag doesn't seem to work when used inside a layout to cancel a cached tag in the main Or am I doing something wrong?

I have a cached tag in tutorial/templates/ and an uncached tag in tutorial/templates/Layout/, but he contents of the uncached tag are still cached.

There is a workaround, which is to close the cached tag before $Layout and open another cached tag inside the layout file if necessary, then a nested uncached tag works.
Maybe it's good practice never to enclose $Layout in a cached tag, and to consider all layouts on a case-by-case basis. Whatever, I don't think the behaviour I'm seeing is intended. I can't see any reference to this issue in trac.

This is how to reproduce the problem using the tutorial theme. Or is the problem that I've misunderstood how the cached and uncached tags are used?


SS_Cache::set_cache_lifetime('any', 24 * 60 * 60);


	function CurrentDateTime() {
		return date('Y-m-d H:i:s');
Note the cached tag wrapped around the $Layout

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "">
<html xmlns="" lang="en" >
		<% base_tag %>
		<link rel="stylesheet" type="text/css" href="tutorial/css/layout.css" />
		<link rel="stylesheet" type="text/css" href="tutorial/css/typography.css" />
		<link rel="stylesheet" type="text/css" href="tutorial/css/form.css" />
		<div id="Main">
<% cached 'Outer', ID, LastEdited, SiteConfig.LastEdited %>
<% include CacheStats %>
<% end_cached %>


<h1>Inside layout</h1>
<% include CacheStats %>

Note the uncached tag wrapped around the first two timestamps in the table

		<div id="ContentContainer">
			<h2>Cache Stats:</h2>
				<% uncached %>
				<% end_uncached %>

The page type is used to create a page in the CMS. Before viewing the published page, delete all files in silverstripe-cache/cache

The first time the page is viewed, both sets of times are the same.
The second time the page is viewed, the two values of Now are different, which should never happen. All times inside the layout are the same as before, they have been cached, even though they are in a cached tag.

Cache Stats:
	Now		2011-09-26 18:07:42
	LastEdited	2011-09-25 21:59:32
	Cached		2011-09-26 18:07:18

Inside layout

Cache Stats:
	Now		2011-09-26 18:07:18
	LastEdited	2011-09-25 21:59:32
	Cached		2011-09-26 18:07:18

The Now value should always show the current time, because it is uncached, right?


Community Member, 44 Posts

10 December 2011 at 7:28am

Hey inCharge, I am having this same problem. Did you ever figure out what was going on with this?


Community Member, 102 Posts

10 December 2011 at 1:12pm

The work-around I ended up using is to end the Page header's 'cached' statement just before the $Layout, and have another 'cached' statement for the footer, and another inside the layout..

This does mean that you end up with a lot of files in the cache, especially on a big site, but apart fropm that, it isn't as bad as it sounds. It makes sense that caching should be considered on a case-by-case basis for each layout. And it's often the case that the footer is the same for all pages, so using a cache ID like...

<% cached 'Footer', SiteConfig.LastEdited %>

...means one cached version of the footer is shared by every page on the site.


Community Member, 44 Posts

11 December 2011 at 3:16am

Thanks for the reply. That's what I was thinking - adding cache blocks inside each layout template.


Forum Moderator, 1391 Posts

11 December 2011 at 7:21am

Might be something like this: the SSViewer class, that renders the main page, will create a new SSViewer instance to render the $Layout subtemplate. So the main SSViewer has no control over what happens in the $Layout template. It just includes whatever HTML is returned and when $Layout falls within a cached block, it never even bothers to create that second viewer.

So what's left is your solution, I guess. Just wanted to know why :-)


Community Member, 31 Posts

1 June 2014 at 2:06am

This is slightly annoying :-(

I was following the approach of caching the entire page content on a page by page basis (in and then adding nested <% cached %> blocks with stricter/more common regeneration rules throughout my various layout/include files (or adding <% uncached %> tags for truly dynamic content)

It should be noted that the behaviour above mentions nesting blocks within Layout but the same is also true for includes.

Can't help but think this should be highlighted or at least mentioned in the docs?