WordPress Caching: Clear An Individual WordPress Post Cache

I’ve become a bit obsessed with caching lately. Speed is an addiction I suppose. So I found another new trick today. If your writing a plugin or theme and have some front in functionality adding and updating posts, sometimes you want to make sure a cached object is cleared before the page is refreshed. But you don’t want to dump the whole object cache, especially if there are thousands of posts. So to just dump one post you can simply do this:

wp_cache_delete($post_id,'posts');

Why I’m Lovin Pyrocms

So in my admittedly-limited free time I’ve been working on some PyroCMS-based projects and the more I work with it the more I love it. The main reason is that it’s built using Codeigniter which is a custom PHP framework. So if you know how to develop with CI you can easily get going with PyroCMS. And because it’s built on a custom framework, there’s a structure for customization.

By contrast if you’re developing with WordPress and you reach a point where you have to go beyond core and start building custom plugins there’s really no pattern to follow. Sure there are hooks and filters that allow you to customize as much as you want. But because WP is not a custom framework, it isn’t built for customization and there are no internal conventions for full-on custom modification. So each plugin you look at has a slightly different approach to accomplishing goals. The Pods CMS project attempts to create a standard for customization, but it has not yet been fully developed or fully adopted.

PyroCMS on the other hand, being CI based, strictly follows the MVC pattern and thus allows developers to anticipate the structure of any module, and replicate and override those modules if necessary. This is what custom frameworks setup to do. PyroCMS combines the code-base scalability with WordPress like features and the ability to quickly launch sites. Though, it still has a ways to go match up with WordPress on features.

This distinction is relevant for clients too. You decide to save on development costs and use a system like WordPress for your CMS. But then you start customizing everything and before you know it what you really have is a custom site attached to a WordPress install. This is fine until your developer goes on to bigger and better projects and you have to find a new one. Well, your WordPress install is too hacked and customized for average WordPress developers to handle. But because it wasn’t built on a custom framework, PHP developers will not be able to easily and quickly understand how the site was setup. Either way the cost of maintenance is going to be considerably higher than if you had gone custom in the first place.