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,
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.
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
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.
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.