Sat Aug 25, 2007
Textpattern Caching
IMHO, one of the biggest feature holes in Textpattern is its lack of caching. There are no built in mechanisms and the only option to date is the plugin zem_cache. I toyed around with it for a bit, but I don’t like having to wrap existing tags with more tags.
To fill the hole, I’ve made another mod to Textpattern v4.0.5. This one automatically adds caching support to all existing and future tags. In addition to output caching, the caching class can also be used by plugins to cache anything the developer needs. All cache entries are referenced by an id and a context. A context can be a page, a plugin name, a namespace, or anything else to guarantee an id is unique. The context makes caching tags uniquely between pages easy (e.g. the nav links on this site), and allows the caching of a tag across an entire site (e.g. the sidebar links).
I still need to make some additional improvements to the caching so that it works properly with the authentication mods currently in place. Caching what should be hidden information and displaying it to anonymous users is currently a very bad side effect. I think the solution will be as easy as appending $txp_user to the context.
This functionality does not exist in crockery and is a useful enough feature that I will probably submit a patch in to the void that is the txp-dev list.
Comment
Hi Manfre.
What about the asy_jpcache plug-in?
Have you tested it?
You don’t need to use any tag in templates or forms.
Also, if you give it a try, could you please explain the difference between your solution and asy_jpcache, advantages and disadvantages, if any?
Thanks!
— ManiquÃÂ · 08/26/07 06:34 PM · #
I’ve used asy_jpcache previously, but the biggest limitation I found was that “asy_jpcache will only cache complete pages”. Full page output caching, while generally the most efficient method of output caching, will not work on my site because I’ve made changes to support per user information. I would be required to modify asy_jpcache to support user sessions, but this would result in a rather large cache (1 set of pages per user) that does not save much processing time due to the number of cache misses.
When used as an output cache, my solution is on par with zem_cache, except you only need to add additional attributes to existing tags on your page. The main advantage over zem_cache is that if zem_cache breaks or is uninstalled, all of those tags scattered throughout your site are unrecognizable by Textpattern. The biggest advantage of my solution is that it is more than just an output cache. Any data can be cached for an arbitrary amount of time. This means that plugins will not have to rewrite its own caching functionality.
Commenting is closed for this article.
