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.
7 Comments
Can you post the whole patched wp-cache-phase2.php file, please?
Sure, here you go:
wp-cache-phase2.phps
wp-cache-phase2.txt
So, using your wp-cache-phase2.php means we’re done?
Argh! Please don’t use text/xml! If you insist on using registered MIME types, use application/xml, otherwise just use application/rss+xml and be done with it.
Hrm. I blindly copied the content type out of the WordPress RSS2 feed code. But I’ve corrected my patch to use
application/rss+xml.What is the reason for
stripos($_SERVER["REQUEST_URI"],’wp-cache-fix’) !== false)
?
If the url does not contain the string `wp-cache-fix`, WP-Cache will cache files that should be filtered out according to the rejected strings (default: wp-), which could pose a security thread.
Bantai:
I don’t remember why I added that conditional — it was some time ago. It might have been an experimental change that I forgot to remove before I made the diff.
But in any case, the problem is fixed in wp-cache version 2.1.2.
5 Trackbacks
[...] Dougal Campbell acaba de publicar un parche para el plugin de WordPress WP-Cache. [...]
[...] Campbell, recently posted a patch for WP-Cache that fixes “one minor annoyance” where sites, with WP-Cache enabled, have [...]
[...] WP-Cache fix for Content-Type in feeds - good stuff. [...]
[...] geek ramblings | WP-Cache fix for Content-Type in feeds (tags: wordpress cache feeds content-type) [...]
[...] writing). While perusing the comments (I always read the comments about plugins!) I noticed that Dougal had made a tweak to fix a content-type [...]