Dougal Campbell's geek ramblings

If you run a busy WordPress site, or even if your site just has a lot of processor-intensive plugins, then you probably already run the WP-Cache plugin (plugin directory, original announcment, recent security update info). Even though my site isn’t super busy, my server is a little light in the RAM department, and using WP-Cache helps the box keep up with requests better.

One minor annoyance, however, is that with WP-Cache enabled, my syndication feeds aren’t delivered with the correct Content-Type. They are all cached with a “text/html” type. Again, this is only a minor annoyance, since I haven’t run across a feed reader yet that cares very much about the Content-Type header. But the Feed Validator does. If it sees an Atom feed delivered with content type “text/html” instead of “application/atom+xml”, it gives you a warning. It still checks the validity of the actual feed content, but there’s that big ugly warning at the top.

But not any more. I dug a little bit into the WP Cache plugin to try to figure out what was going on. The plugin does attempt to preserve the correct content type of pages when it caches them, but the output buffering that it uses to capture the content gets in the way. You can’t get to the generated headers until after you flush the buffer. But you don’t want to flush the buffer until you’ve got all of the data to write into the cache meta files. It’s a catch-22. (Actually, it might be okay to flush the buffer at the point where you need the headers, but I’m not sure without further analysis, and I just don’t have the time right now. I’ll leave that as an exercise for someone else. 😉 )

So, if you’re a stickler about minor things like the Content-Type of your feeds, and you’re using WP-Cache, feel free to check out my patch: WP-Cache Feed Content Type Patch. Note that the changes to the wp_cache_get_response_headers() function don’t actually work for me. But I left them in the patch in case anybody else wants to examine that section more closely. It might just be something that works in some combinations of Apache/PHP versions and not others.

Update 2007-10-12: This problem was officially fixed in wp-cache version 2.1.2.