WordPress 2.0.6 and FeedBurner Disconnects

This article provides a workaroud for WordPress 2.0.6 and chronic FeedBurner disconnects. It’s essential that you upgrade to WordPress 2.0.6 immediately in order to prevent your blog from being taken over by hackers! Upgrade, then follow these instructions to get it to play nicely with FeedBurner afterwards.

The Problem

After upgrading to WordPress 2.0.6 or WordPress 2.1 Beta, your FeedBurner feed will, at times, give you an “invalid xml” error, and “FeedMedic” will show you something like this:

Your server disconnected us before sending the full source feed content. If your blogging platform is TextPattern, this is a known bug, and a fix can be found here: http://forum.textpattern.com/viewtopic.php?id=11247


FeedBurner uses something called “Conditional Get requests” to ask your server whether or not the page has changed since the last it viewed it, in order to save you some bandwidth. Depending on how popular your site is, FeedBurner may hit up your feed up to hundreds of times a day, so this is a really good idea! Unfortunately, in WordPress 2.0.6, your site doesn’t respond in a way that FeedBurner recognizes. The 304 headers it sends back to let it know that the content hasn’t changed are malformed and corrupt – and FeedBurner has no idea what they mean.

Workaround 1

Thanks to Mark Jaquith, there’s a little change you can make to your code to make it work the way it’s supposed to. This very same change will be included in WordPress 2.0.7, so you don’t have to worry about unsafe changes. You can grab the unified diff file here, if you like.

Open /wp-includes/functions.php and find the following code:

if ( substr(php_sapi_name(), 0, 3) == &#8216;cgi&#8217; )<br />
		@header(&#8220;HTTP/1.1 $header $text&#8221;);<br />
	else<br />
		@header(&#8220;Status: $header $text&#8221;);<br />

Replace that code block with this code below, which commetns out the trouble-causing portions:

// 	if ( substr(php_sapi_name(), 0, 3) == &#8216;cgi&#8217; )<br />
		@header(&#8220;HTTP/1.1 $header $text&#8221;);<br />
//	else<br />
//		@header(&#8220;Status: $header $text&#8221;);<br />

Save the file and exit. Resync your feed at FeedBurner.

Workaround 2

If you’re not feeling up to messing with the WordPress source code and would rather not possibly have to fix something later, you can create a php script that “relays” the content of your feed to FeedBurner for you. All you have to do is cut and paste the code below into a file of your own on your server – or any other as a matter of fact. Then, just point FeedBurner to this file instead, and you’re done. Just remember: this file doesn’t cache! 

Create a file called FeedBurner.php, which contains the following code:

$uri="http://neosmart.net/blog/feed/"; //Replace this URI with the URI to *your* feed!!

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $uri);
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
echo curl_exec($ch);
$status = curl_close($ch);

The code’s that simple. Upload this file to a webserver, and point FeedBurner to the URI for this file, and you’ll no longer get that ugly error!

  • Similar Posts

    Craving more? Here are some posts a vector similarity search turns up as being relevant or similar from our catalog you might also enjoy.
    1. WordPress 2.0.7 Fixes the FeedBurner Bug
    2. Totally Redone Feed System
    3. CompleteRSS: Content-Complete Feeds Raring to Go!
    4. Workaround for Akismet on SVN
    5. Ultimate Tag Warrior and WordPress 2.1
  • 14 thoughts on “WordPress 2.0.6 and FeedBurner Disconnects

    1. Yes, the second one does. If you’re familiar with PHP, you can use fopen instead – but if you have curl-lib installed it’s recommended that you use this.

      It might be easier to just use Workaround 1 instead.

    2. Awesome fix, thanks! I found this via Technorati, but I think it needs more exposure, especially since Technorati is sorted by date…


      It would be nice if Matt or someone put this on the dev blog – that would guarantee attention.

    3. @Ajay: It’s really straightforward; first you give it a URI, then CURL downloads the contents of that URI into a variable, and PHP prints the contents of that variable out.

      Basically, it’s a proxy script, for only one page. It proxies the contents of your feed into a new page (FeedBurner.php) in a way that circumvents the 304 headers/conditional gets. In a nutshell, it turns a page that support conditional caching into a static page like any other – except this one works.

    4. great – I thought it was me causing the errors.

       Now to my next feedburner issue, how do I get feedburner/Wordpress to display a summary feed without using the summary tool in feedburner?  I’ve set ‘summary’ in my dashboard but it never takes.


    5. The feedburner plugin is irrelevant to this . . . the error is still there. I used workaround one and everything is flowing fine.

    6. There are millions of crazy feeds out there doing a lot of weird stuff. I’ve long given up on investigating every single case. Feeds that use pubsub hubs (like most feedburner) push content to us. I don’t know why this feed decides to push content every time we pull it, maybe there’s a webhook somewhere.

    Leave a Reply

    Your email address will not be published. Required fields are marked *