Support » Requests and Feedback » Easy fix for Common RSS/Atom feed Bug

  • Hi, this message is meant for anyone who has the power to insert permanent changes into the official WordPress codebase.

    There is a fairly common bug with WordPress’s RSS/Atom feeds. It doesn’t happen to everyone, but when it does occur, wordpresses various feed xml documents end up with some extra blank lines at the beginning. Since the feeds are validated XML documents, these extra blank lines are not allowed, and will cause many feed readers to refuse to parse the feed, with an error message like: “XML or text declaration not at start of entity.”

    If you do a google search for this problem, you’ll see that quite a few people are encountering it.

    The root cause of the problem is plugin developers that leave stray newlines at the beginning or end of their .php markup tags in their php files. Someone even wrote a plugin that strips all the leading and trailing newlines from your wordpress .php files, and even that doesn’t always work (it didn’t for me)!

    This is a very frustrating problem for those of us who experience it, but happily there is an easy fix that will solve the matter for everyone. AND we don’t have to rely on forcing every plugin and wp developer to be really disciplined about their stray newlines.

    There is one solution near the end of this forum posting, involving ob_clean():

    And there is another solution (it’s one I tried, and it works perfectly) here:

    Both solutions involve a last-minute removal of any stray newlines that have been added to the beginning of the feed xml documents (regardless of how they got there). As far as I can see, there’s no downside to adding a couple extra lines of code to do this at the beginning of each *-feed.php file, and it should pretty much squash this bug cold.

    That second link that I provided gives the exact details on how to patch the WordPress codebase. I take no credit for thinking up this fix, but I would very much like to bring it to the attention of the WordPress dev team. It seems like a very easy, low-risk fix to a problem that will otherwise keep coming up again and again.

    Please consider adding this in there, guys. Thanks!


Viewing 13 replies - 1 through 13 (of 13 total)
  • I tried your second link and it worked !!

    The intelligent thing would be for the development community to incorporate the code into the WordPress distribution…

    Yup…that’s exactly what I’m hoping will happen. It’s an awfully easy change, and a big win.

    Fantastic! Thanks for the advice (second link) which solved a big headache.

    All those saying the second link worked for them, did you actually try the fix in the first link?

    Maybe you missed the post, since the first link points to the first page in that thread, instead of the third page, where the actual post is:

    I prefer this fix, since it’s less code 🙂
    Just add ob_clean() in all the feeds that are not working, and you’re all set.

    Moderator Samuel Wood (Otto)

    (@otto42) Admin

    This has been brought up on wp-hackers again and again, and I think it was in the bugtracker once. We can’t seem to get any traction on it.

    So.. I would not expect it anytime soon, is all I’m saying.

    Too bad, because this is such a simple problem to fix.

    The issue has been raised in TRAC (you can log in using the same details you use to log into this forum.)

    Feel free to jump in there and add your two cents. If the issue gets enough attention, perhaps one of the devs will fix it.

    Moderator Samuel Wood (Otto)

    (@otto42) Admin

    Like DD32 said, the cure is worse than the disease. Output buffering is a terrible solution for a lot of reasons. It’s a major performance drain on a site.

    I agree with the original argument for the most part here. As long a stock WP install won’t produce this error, there’s no issue. Fix the problem, don’t patch it up with a dirty hack.

    The issue I’ve tackled is trying to get the ending ?> removed from all the WP PHP files, to prevent accidental blank line output from the core files (which happens from time to time). Using output buffering for everything by default just to fix buggy plugins is not going to make it into core.

    Actually even with the hack I’m getting XML errors – and I’ve been all over the place eliminating hard returns in .php files (why are they there anyway ?) – I get this when trying to use Zoundry Raven – as a workround to escape the WP auto-correction… –

    If this hack is unhealthy (and it was the only way I could get feedburner working) then it is up to WP codewriters to GET IT RIGHT ! I do NOT understand php or that much about XML and if WP is all it claims to be then it should work out of the box without me having to worry about it.

    Spend your time getting that right and less on auto correcton which messes up the HTML code – and that I DO understand !

    Moderator Samuel Wood (Otto)

    (@otto42) Admin

    nick: WP does work out of the box. Perfectly, in fact. The RSS feed it produces, with no modifications, is correct.

    Well, I honestly don’t mean to offend anyone here, but I think that simply saying “MY codebase works fine, so it’s not MY problem” is a bit stubborn, as well as a bit naive.

    I am the team lead for a software application that also uses plugins, and we consider it very important to make our software bullet-proof. One of our main architectural goals is to sandbox everything so that even a maliciously written plugin can’t break our application. This is a lot harder to do with php than it is with Java, but at the very least I would think you’d be interested in making your software as robust as possible. The issue I’ve raised is a common one, and it’s not making the plugin developers look incompetent, it’s making the WP developers look incompetent! And yes, I fully understand that the WP developers didn’t write the bug…but the bug is still there.

    If using output buffering is unacceptable, then how about adding a bit of code in the next release that checks the rss/atom feeds each time a plugin is activated? It should be easy enough to detect the extra newlines and refuse to activate the plugin (with a helpful error message, so that plugin writers can quickly spot and fix the problem in their own code.)

    Again, my intention here is to be helpful, not abrasive. I suppose this could be one of those issues where the WP devs get their back up, and nothing I say (no matter how sensible) will change your minds. If so, you’ll just have to forgive my annoyance; I’m going to be stuck patching WordPress by hand from now on, or at least until I can find an alternative that works with plugins *without* forcing me to fix them first.

    Moderator Samuel Wood (Otto)

    (@otto42) Admin

    Well, the problem is that the most common cause of this isn’t a broken plugin. Most plugin developers have figured out and fixed this sort of issue in their own code.

    The most common cause of this is the end user manually editing their wp-config.php file, and having their text editor sticking blank lines at the end of the file. Newer versions of the wp-config-sample.php file, you may note, lack the ending ?> in them, to prevent this problem from occurring.

    Working around bugs in plugins is not something that should be in the core. There’s no “patch” in WordPress that can fix code in somebody else’s unrelated code. It’s a losing battle.

    Working around bugs in plugins is not something that should be in the core. There’s no “patch” in WordPress that can fix code in somebody else’s unrelated code. It’s a losing battle.

    Well, obviously we disagree on this point–although to be fair, I’m not really recommending that you write a “work around” for someone else’s bug so much as I am recommending that you find a way to bullet-proof your code so that it’s not so easy for plugin developers to accidentally break feeds.

    If what you say is true and the main cause of this problem is not plugin developers, but badly edited wp-config.php files, then it sounds like you’ve already done something to make things more bulletproof. Hopefully that means that this issue won’t be so common in the future.

    As for me, I’m still gonna have to go digging to figure out which one of my plugins is misbehaving!

    1. I didn’t TOUCH my config file other than the basic necessities to get WP up and running. As I said PHP and I aren’t best mates so we don’t feel each other up unless absolutely necessary !
    I DID find that there were hard returns, among other places at the end of RSS feed files themselves.
    Unhealthy as these patches are it was THE ONLY way I could find to get a feed up and running. Still can’t get Zoundry to work though…

Viewing 13 replies - 1 through 13 (of 13 total)
  • The topic ‘Easy fix for Common RSS/Atom feed Bug’ is closed to new replies.