prevent inadvertent output from included files

[mm6]

A couple days ago I accidentally broke all my feeds and XMLRPC by introducing a newline in my theme's functions.php file. This caused a newline before the xml declaration in the generated XML which breaks XML parsers.

It got me thinking if there was a way to ignore the output from an included file that should never generate any output. What if the include was wrapped in this?

ob_start()
include(STYLESHEETPATH . '/functions.php');
ob_end_clean()

If anyone thinks is a good idea I can make a patch.

[Otto42]

I think this is an interesting idea, but I'd say that it might be worth expanding the idea to prevent *all* output prior to the actual theme files being called.

In other words, ob_start in the root index.php, then ob_end_clean in the template-loader.php.

I don't think this will impact cookies and headers and such, but some testing would need to be done there.

[jacobsantos]

Dude.

Just remove ?> from the end of all of your library files.

This idea is inane and quite hackish. No offense.

[jacobsantos]

Also remember, one newline is okay. Two new lines is NOT OKAY.

[mm6]

Something like this would automatically fix these types of problems in all present and future themes. Trying to proactively fix something which causes subtle breakage of major site functionality is not "inane and hackish".

Your solution is to rely on all theme authors and modifiers to do something that not a lot of people know about and seems wrong (people are used to closing tag-type things that they opened). The large majority of themes (including the default Wordpress theme) include closing ?>.

[mm6]

And a single newline after ?> in a theme's functions.php will break a lot of XML parsers, breaking feeds and XMLRPC responses for the site.

[mm6]

Scratch the previous comment. It does take two newlines. Forgot about the one the editor adds, but it only takes one added intentionally.

[DD32]

Yes, wraping it in an output buffer *would* prevent errors from occuring.

However, Its mearly preventing the displayment of an error which the user, a plugin, or a core file introduces, The error should be corrected, not worked around.

It would also break any sites which use the output buffer for things such as gziping the content AFAIK.

[Otto42]

Replying to DD32:

It would also break any sites which use the output buffer for things such as gziping the content AFAIK.

No, it wouldn't. You can have nested output buffers.

[DD32]

You can have nested output buffers

Ah, Didnt realise that :) cheers Otto

[jacobsantos]

Sorry, let me explain it better.

It is hackish because there is a better fix: remove the ending ?> from the ends of the files.

This is a known problem with a known solution. Sorry, but during your journey as a programmer you will find stuff to be not as they seem and on some of them, you are SOL.

You comment of having an closing ?>, because there is an opening PHP tag is inaccurate. PHP is not a markup language, does not require the closing PHP tag. To compare a programming language with markup language isn't logical. Just because you can put markup in with the code, doesn't mean anything. If you check the Opcodes or the assembly, you will see that it doesn't matter to PHP. Also, during the compile stage of PHP, all of the included files are combined anyway, therefore it stands to reason that you don't actually need the closing tag because PHP doesn't need it.

However, the coding standards of WordPress state that all files might have the closing PHP tag and that leaves us where we are today.

The known solutions are:

1. Remove the whitespace causing the problem.
2. Remove the closing PHP characters '?>'.

Those are the only two, anything else should not be considered. I'll further explain. The time it would take you to build the solution, test the solution and then support the solution doesn't seem worth it. Want happens when there is an included file outside of the output caching? You might face the same problem.

If prevention is what you are trying to do then write a script that removes the closing PHP tag from all of the library files for your system. You can even build a plugin which does this for other people. It isn't difficult.