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
Explanation
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:
[sourcecode language='php'] if ( substr(php_sapi_name(), 0, 3) == 'cgi' ) @header("HTTP/1.1 $header $text"); else @header("Status: $header $text"); }[/sourcecode]Replace that code block with this code below, which commetns out the trouble-causing portions:
[sourcecode language='php']// if ( substr(php_sapi_name(), 0, 3) == 'cgi' ) @header("HTTP/1.1 $header $text"); // else // @header("Status: $header $text"); }[/sourcecode]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:
[sourcecode language='php'][/sourcecode]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!
This fix required curl library ?
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.
Awesome fix, thanks! I found this via Technorati, but I think it needs more exposure, especially since Technorati is sorted by date...
dzone - digg - NetScape
It would be nice if Matt or someone put this on the dev blog - that would guarantee attention.
Hi, can you explain what the curl code does exactly?
@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.
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.
Anybody know if this affects people who use the Feedburner Feed Replacement plugin? I assume people using that plugin are OK. If I'm not mistaken, that plugin works on the same principle that workaround #2 uses. Can anyone confirm?
I'm actually feed time-out errors now on Feedburner. Any idea why?
Jim - perhaps a plugin - specifically Bad Behavior with <v2 or v2 in strict mode?
The feedburner plugin is irrelevant to this . . . the error is still there. I used workaround one and everything is flowing fine.
Hi there,
thanks for the nice working workaround!
The asides.php file is pretty big.
You'll find the mentioned code at line 2231.
Thanks.
...sorry folks!
Meant to say functions.php file.
(Need to slow down)