Dougal Campbell's geek ramblings

WordPress, web development, and world domination.

WP-Cache fix for Content-Type in feeds

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.

About Dougal Campbell

Dougal is a web developer, and a "Developer Emeritus" for the WordPress platform. When he's not coding PHP, Perl, CSS, JavaScript, or whatnot, he spends time with his wife, three children, a dog, and a cat in their Atlanta area home.
This entry was posted in Plugins, Software, Standards, Syndication, WordPress and tagged , , , , , , . Bookmark the permalink.

12 Responses to WP-Cache fix for Content-Type in feeds

  1. jon says:

    Can you post the whole patched wp-cache-phase2.php file, please?

  2. Titanas says:

    So, using your wp-cache-phase2.php means we’re done? 🙂

  3. Pingback: Parche para WP-Cache | La brujula verde

  4. Pingback: Content-Type Patch for WP-Cache and WP-Cache NoSymlink » twentythree7

  5. Pingback: Around the web |

  6. Mark says:

    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.

  7. Dougal says:

    Argh! Please don’t use text/xml!

    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.

  8. Pingback: Brian Kerr | links for 2007-06-26

  9. Pingback: More Plugins and One Offs » Solo Technology

  10. Bantai says:

    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.

  11. Dougal says:


    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.

Leave a Reply

%d bloggers like this: