WordPress.org

Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

#9610 closed defect (bug) (invalid)

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

Reported by: rmckillen Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: XML-RPC Keywords:
Focuses: Cc:
PR Number:

Description

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"?>

Change History (19)

#1 @Denis-de-Bernardy
11 years ago

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

#2 @Denis-de-Bernardy
11 years ago

  • Milestone Unassigned deleted
  • Resolution set to worksforme
  • Status changed from new to closed

please re-open with feedback

#3 follow-up: @jmulley
11 years ago

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 :)

#4 in reply to: ↑ 3 @jmulley
11 years ago

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.

#5 @Denis-de-Bernardy
11 years ago

err, not making any sense of this

#6 @achmafooma
11 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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.

#7 follow-up: @achmafooma
11 years ago

  • Cc achmafooma added

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.

#8 @peaceablewhale
11 years ago

  • Component changed from Feeds to XML-RPC

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

#9 in reply to: ↑ 7 @Denis-de-Bernardy
11 years ago

  • Resolution set to worksforme
  • Status changed from reopened to closed

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.

#10 follow-up: @achmafooma
11 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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 :-).

#11 in reply to: ↑ 10 @filosofo
11 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

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.

#12 @Denis-de-Bernardy
11 years ago

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.

#13 follow-up: @filosofo
11 years ago

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.

#14 @Denis-de-Bernardy
11 years ago

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

#15 in reply to: ↑ 13 ; follow-up: @miqrogroove
10 years ago

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.

#16 in reply to: ↑ 15 @filosofo
10 years ago

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.

#17 follow-up: @miqrogroove
10 years ago

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

#18 in reply to: ↑ 17 @sivel
10 years ago

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)

#19 @nacin
10 years ago

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

Note: See TracTickets for help on using tickets.