View Caching in CakePHP 1.1.8

The view caching in CakePHP 1.1.8 is both good and bad. It's good in that it can dramatically speed up the performance of your site — when you can use it. And that's the downside. There are certain situations when it simply will not work as a practical option.

How it works

The caching is all handled through the innards of the framework in a combination of global functions, cache() and clearCache(), a cache component and the view object. Basically, once a view has rendered the output, if the cache is turned on, it will render the output to the cache folder. It's saved using a filename based on the URL. On a page request, the bootstrapping grabs the URL and looks for it in the cache. If it isn't found, then it proceeds with dispatching the entire CakePHP process.


The problem is when you want to cache data based on something other than the URL, like user-specific information. CakePHP gets around this by allowing you to set certain areas of a view to not cache. Because the cache is checked before any of the routing or controllers get instantiated, there's no way to tie in additional parameters to tell the cache to function any differently.


I really have to mention this as Nathan Smith helped point out that none of my old links were working. When I did the reboot back in May, I switched up my URL's from the less than ideal /archives/0000123.php to /archives/category_name/article_name/. Under MovableType, I just had both versions get generated to ensure no gruesome 404s. Then I switched to CakePHP. I wasn't using view caching in the beginning and simply took the numeric URL and fed it into my Posts controller. It then noticed the path was numeric and built the correct path to redirect the user to the final article.

But this all stopped working when I enabled the view caching. Turns out, I didn't have an exit() statement right after a redirect. Therefore, despite the redirect and the user never seeing the generated page, the process still continued on and the cached page was created. Then, every subsequent request pulled from the cache (since it checks the cache well before it gets to the controller). Adding the exit statement prevents the page from getting cached.


I've seen people on the CakePHP Google Group recommended using third-party caching systems including Smarty, which has caching.

To pull off something using CakePHP itself is a little more harrowing based on my tinkering of the system. Trying to use CakePHP to use custom caching is tricky because you need the rendered view. Problem is, the view doesn't return a rendered version of itself (except, I think, using a requestAction call but rewriting all requests through requestAction calls seems silly).

What we need

URL-based Caching

The first, is to continue to have the URL-based caching available as an option for users who need it. However, it'd be important that a developer would have control over whether a specific action or controller would generate a cached page or not. I think this is already in there but honestly haven't played with it to that extent.

Cookie/Session-based Caching

Besides the URL, specific information may be stored either in a cookie or in a session variable. It'd be great to be able to check the cache for this type of information before hitting the controller level; this could be done in the app/config/bootstrap.php file that already exists. The cookie and session variable checks would have to be manual (e.g. using $_COOKIE) but this would be a small price to pay.


I think we'll have to wait until either 1.2 or 2.0 for the view caching to be revisited but with just a couple minor tweaks to the codebase, I think it's entirely possible.

Published October 22, 2006
Categorized as CakePHP
Short URL:


5 Comments · RSS feed
Evan Krambuhl said on October 22, 2006

I don't see a problem with just using this skin/theme/view or whatever you call it. This look is really nice and focus' on what a site like yours should, content.

Jonathan Snook said on October 22, 2006

Evan: thanks. :) View caching, is something that I think is important as many applications could see dramatic improvements in performance without having to do much.

For this site, I may not bring back the old designs as, like you said, this design seems to be well suited to handling the kind of content I'm developing.

Johan said on October 23, 2006

Hi Jonathan,

I wonder if cakePHP had anything to do with PEAR?

Tarique Sani said on October 23, 2006

Thanks for the article - hope someone at cakePHP has noticed it. Lack of caching or rather lack of flexible caching is preventing me from seriously considering cakePHP for high traffic sites but then there are people who claim to have Alexa ranking of < 100,000 and running apps on cake....

Jonathan Snook said on October 24, 2006

Johan: CakePHP doesn't specifically have to do with PEAR but it can use it if need be. For example, in an application we're developing, we're using the XML serializer within Cake.

Tarique: well, I wouldn't put too much interest in Alexa. They have my site ranked at 28,540 currently. So, yeah, there are people with that kind of volume running apps on Cake. It was working fine without the view caching but I did feel that it was much slower than what I had previously and I felt that if my traffic peaked, I'd be in trouble.

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.

Want to learn about scaling CSS for large projects?

I'm available for full and half-day workshops on scalable CSS architecture. I can provide on-site training for your team. Interested?
Get in touch.