line breaks in functions.php result in invalid XML in RSS feed

[rmckillen]

This issue impacts the functions.php file regardless of theme in use, so the problem is with the Wordpress core.

If the functions.php file contains these 2 lines of code, there are no problems:

<?php code ?>
<?php more code ?>

If the functions.php file contains these 3 lines (2nd line being blank) of code:

<?php code ?>

<?php more code ?>

The primary RSS feed generated by Wordpress contains invalid XML. According to Firefox:

XML Parsing Error: XML or text declaration not at start of entity
Location: ​http://popjab.com/feed/
Line Number 2, Column 1:
<?xml version="1.0" encoding="UTF-8"?>

[Denis-de-Bernardy]

works fine for me. any odds you've a plugin that's doing some harm?

[Denis-de-Bernardy]

please re-open with feedback

[jmulley]

Download the new file. This only affects around 1,000 downloaders, most of which have downloaded the new file. This isn't a new release, just a new zip. It fixes the problem :)

[jmulley]

As I forgot to state before, it only fixes the problem in a clean install. So my guess is that it's a phpMyAdmin thing.

[Denis-de-Bernardy]

err, not making any sense of this

[achmafooma]

I just ran into this. In your theme's functions.php file, if you have an empty line OUTSIDE of PHP tags, it screws up BOTH the RSS feeds and the XMLRPC XML, which causes errors in feed readers and XMLRPC tools (like WordPress BlackBerry & iPhone apps).

In your active theme's functions.php add:

code
?>

<?php
more code

That BLANK LINE is the important bit. After putting this in your active theme's functions.php file, going to ​http://site.com/feed or ​http://site.com/xmlrpc?rdp you'll get the blank line at the top of the XML files, making them invalid.

[achmafooma]

One more thing: This occurs even with ALL plugins disabled, so it's clearly an issue with WP. If I can provide any more useful information please just let me know.

[peaceablewhale]

The problem in feed should have been fixed by [10952]. Moving this to XML-RPC.

[Denis-de-Bernardy]

Replying to achmafooma:

One more thing: This occurs even with ALL plugins disabled, so it's clearly an issue with WP. If I can provide any more useful information please just let me know.

nope, it's an issue in your theme's function.php, which you described.

[achmafooma]

Denis-- I understand that the problem is set in motion by the issue in the theme's function.php..... BUT why on earth would an erroneous blank line in functions.php screw up both the RSS feeds and XML-RPC functionality? One should not effect the other like this.

This gave me a huge amount of headache in tracking down the problem since nothing in my functions.php should have been effecting RSS/XML-RPC, and nothing in the way the problem presented itself (blank space at the start of the XML files) would have pointed me back to functions.php. I only figured it out when I stumbled upon this bug report.

To me, this is definitely a bug either in how WP parses functions.php files or in how WP generates the XML for RSS / XML-RPC. A blank line in functions.php (even if this is incorrect/improper) should not inexplicably put a blank line on top of WP-generated XML and break RSS / XML-RPC!

Don't want to get into a war here; another 'closed/worksforme' and I'll quietly drop it :-).

[filosofo]

Replying to achmafooma:

To me, this is definitely a bug either in how WP parses functions.php files or in how WP generates the XML for RSS / XML-RPC. A blank line in functions.php (even if this is incorrect/improper) should not inexplicably put a blank line on top of WP-generated XML and break RSS / XML-RPC!

No, it's how PHP works. Lines outside of closing PHP tags are printed. As the active theme's functions.php file is always included, the extra line is always printed, causing the error.

[Denis-de-Bernardy]

Yes, but there's nothing one can do about it. A blank line is a blank line. Some XML parsers and validators, however, don't play well with blank lines inserted before the XML declaration. I'd suggest you complain with Feedburner and the W3C on this one. :-)

Anyway, you can dodge the problem by issuing ob_start()/ob_end_clean() statements before and after including wp-settings.php, from within your wp-config.php file, at the risk of losing some plugin functionality if anything tries to override WP on the init hook.

Apart from this, though, there truly is nothing that WP can do about it... The XML that gets output is perfectly valid, and WP in itself inserts no blank lines. If one gets added in a theme's functions.php file, well... there really isn't much that can be done, is there? We wouldn't even be able to tell the user without adding an output buffer in core... :-|

I'd have left it open pending dev feedback had filosofo not closed it already. But I sincerely doubt it would have gotten fixed anyway... Picture a function.php file or a plugin that bails on a request, and tries to output something outside of WP depending on a $_GET parameter, and then die. PHP 5.2 platforms would then return fatal errors if instantiated objects are used on the shutdown hook, since the shutdown hook wouldn't be declared yet with its ob_flush procedure.

[filosofo]

A "fix" might be to leave off closing PHP tags in sample plugins and themes and encourage people to leave them off as best practice.

[Denis-de-Bernardy]

that too, but his sample code tells another story. :-)

[miqrogroove]

Replying to filosofo:

A "fix" might be to leave off closing PHP tags in sample plugins and themes and encourage people to leave them off as best practice.

That's a bit crazy. Advise them to do this:

return;
?>

It prevents any blank lines from printing.

[filosofo]

Replying to miqrogroove:

Replying to filosofo:

A "fix" might be to leave off closing PHP tags in sample plugins and themes and encourage people to leave them off as best practice.

That's a bit crazy.

My crazy has ​precedent.

[miqrogroove]

yeah well they also forbid carriage returns and tabs. Just try explaining that to the average plugin author. :P

[sivel]

Replying to miqrogroove:

yeah well they also forbid carriage returns and tabs. Just try explaining that to the average plugin author. :P

By the way, we *do* recommend leaving off the last ?>. For a few examples see wp-config.php of functions.php in twentyten.

In reason we are still commenting on a closed ticket? (rhetorical question)

[nacin]

We leave off the last ?> on core files that may see user edits. That means wp-config.php and theme functions.php. See also #10633