Can you leave off the ending ?> tag in a PHP file?
Yes – and in fact, sometimes it’s the BEST thing to do.
I first heard of this in a newslist post, where a member insisted that this should be done rather than ending code with the traditional closing ?> tag.
There’s a very good reason for this in WordPress – if you leave it off your wp-config.php file, then you will avoid the dreaded ‘headers already sent’ message coming from a broken one:
Cannot modify header information – headers already sent by (output started at XXX) in XXX/wp-config.php on line X
The reason is that everything outside of the <?php and ?> tags is considering HTML or text; and so if there is too much following the ending tag in wp-config.php, the system assumes the web page has started. And once the web page has started, the option to send headers is lost – so when WP sends out some headers later, you get that error.
So leaving off ?> is a GOOD thing for wp-config.php – but is it a SAFE thing?
Surprisingly enough, yes. Besides trying it on my server (PHP 4.30, about as old as you can go and still run WordPress), I also checked around:
- The PHP docs on the ?> tag states that “The closing tag of a PHP block at the end of a file is optional, and in some cases omitting it is helpful”.
- Drupal refers back to PHP.net in mentioning it is optional, further pointing out that “PHP.net itself removes the closing delimiter from the end of its files, so this can be seen as a ‘best practice'”.
- Zend has taken it a step further, actually forbidding ending ?> tags in code for the Zend framework: “For files that contain only PHP code, the closing tag (“?>”) is never permitted.”.
Given that so many are leaning towards NOT using it, shall we go through our code and remove it everywhere in a PHP-fueled witch hunt?
No – but in specific files, like wp-config.php, it makes perfect sense.
In all my troubleshooting, I can think of many, many times this header error message came up, and was ultimately traced to that file. Fixing that single file by removing the end tag goes a long way towards solving that problem for many users.
Ultimately, the reason it even IS a problem rests with Windows. Editing the file on Windows computers often adds a linefeed/return combination to each line in the file (on the Linux style computers that run most servers, the lines are ended with a single return character only). The result is the file appears to have two line breaks after the ?> and the file starts outputting HTML (in this case, a blank line).
Point of trivia: PHP ignores the first line break after a closing ?> – it’s the second one that starts the output, and screws it up for later header output.
Eventually, I could see a movement towards never ending a file with the closing PHP tag in codebases like WordPress – but right now, there’s only a few files worthy of immediate attention:
- Obviously, wp-config.php, which has the lion’s shares of maintenance headaches associated with this trailing tag.
- Plugins. Try adding a few blank lines after the ?> in your favorite plugin. Since they get loaded before headers are sent, you’ll end up with the same error message, and problem.
- Any file that can/normally would be edited. Obviously, core WordPress files need no fixing – but plugins that users need to tweak should leave it off. Otherwise, they risk inserting code where they shouldn’t, and risk adding a few blanks.
This research has been an eye opener. From first appearing a possible ‘hack’, it’s obvious that the safe way to write PHP in the future is to leave off the ?> tag. While I’m not planning to retrofit my plugins, certainly new ones are going to get the once over – as a way of making my maintenance (and my user’s blood pressure) a little lower.
