Related
I keep reading it is poor practice to use the PHP close tag ?> at the end of the file. The header problem seems irrelevant in the following context (and this is the only good argument so far):
Modern versions of PHP set the output_buffering flag in php.ini
If output buffering is enabled, you can set HTTP headers and cookies after outputting HTML because the returned code is not sent to the browser immediately.
Every good practice book and wiki starts with this 'rule' but nobody offers good reasons.
Is there another good reason to skip the ending PHP tag?
Sending headers earlier than the normal course may have far reaching consequences. Below are just a few of them that happened to come to my mind at the moment:
While current PHP releases may have output buffering on, the actual production servers you will be deploying your code on are far more important than any development or testing machines. And they do not always tend to follow latest PHP trends immediately.
You may have headaches over inexplicable functionality loss. Say, you are implementing some kind payment gateway, and redirect user to a specific URL after successful confirmation by the payment processor. If some kind of PHP error, even a warning, or an excess line ending happens, the payment may remain unprocessed and the user may still seem unbilled. This is also one of the reasons why needless redirection is evil and if redirection is to be used, it must be used with caution.
You may get "Page loading canceled" type of errors in Internet Explorer, even in the most recent versions. This is because an AJAX response/json include contains something that it shouldn't contain, because of the excess line endings in some PHP files, just as I've encountered a few days ago.
If you have some file downloads in your app, they can break too, because of this. And you may not notice it, even after years, since the specific breaking habit of a download depends on the server, the browser, the type and content of the file (and possibly some other factors I don't want to bore you with).
Finally, many PHP frameworks including Symfony, Zend and Laravel (there is no mention of this in the coding guidelines but it follows the suit) and the PSR-2 standard (item 2.2) require omission of the closing tag. PHP manual itself (1,2), Wordpress, Drupal and many other PHP software I guess, advise to do so. If you simply make a habit of following the standard (and setup PHP-CS-Fixer for your code) you can forget the issue. Otherwise you will always need to keep the issue in your mind.
Bonus: a few gotchas (actually currently one) related to these 2 characters:
Even some well-known libraries may contain excess line endings after ?>. An example is Smarty, even the most recent versions of both 2.* and 3.* branch have this. So, as always, watch for third party code. Bonus in bonus: A regex for deleting needless PHP endings: replace (\s*\?>\s*)$ with empty text in all files that contain PHP code.
The reason you should leave off the php closing tag (?>) is so that the programmer doesn't accidentally send extra newline chars.
The reason you shouldn't leave off the php closing tag is because it causes an imbalance in the php tags and any programmer with half a mind can remember to not add extra white-space.
So for your question:
Is there another good reason to skip the ending php tag?
No, there isn't another good reason to skip the ending php tags.
I will finish with some arguments for not bothering with the closing tag:
People are always able to make mistakes, no matter how smart they are.
Adhering to a practice that reduces the number of possible mistakes is (IMHO) a good idea.
PHP is not XML. PHP doesn't need to adhere to XMLs strict standards to be well written and functional. If a missing closing tag annoys you, you're allowed to use a closing tag, it's not a set-in-stone rule one way or the other.
It's a newbie coding style recommendation, well-intentioned, and advised by the manual.
Eschewing ?> however solves just a trickle of the common headers already sent causes (raw output, BOM, notices, etc.) and their follow-up problems.
PHP actually contains some magic to eat up single linebreaks after the ?> closing token. Albeit that has historic issues, and leaves newcomers still susceptible to flaky editors and unawarely shuffling in other whitespace after ?>.
Stylistically some developers prefer to view <?php and ?> as SGML tags / XML processing instructions, implying the balance consistency of a trailing close token. (Which btw, is useful for dependency-conjoining class includes to supplant inefficient file-by-file autoloading.)
Somewhat uncommonly the opening <?php is characterized as PHPs shebang (and fully feasible per binfmt_misc), thereby validating the redundancy of a corresponding close tag.
There's an obvious advise discrepancy between classic PHP syntax guides mandating ?>\n and the more recent ones (PSR-2) agreeing on omission.
(For the record: Zend Framework postulating one over the other does not imply its inherent superiority. It's a misconception that experts were drawn to / target audience of unwieldy APIs).
SCMs and modern IDEs provide builtin solutions mostly alleviating close tag caretaking.
Discouraging any use of the ?> close tag merely delays explaining basic PHP processing behaviour and language semantics to eschew infrequent issues. It is practical still for collaborative software development due to proficiency variations in participants.
Close tag variations
The regular ?> close tag is also known as T_CLOSE_TAG, or thus "close token".
It comprises a few more incarnations, because of PHPs magic newline eating:
?>\n (Unix linefeed)
?>\r (Carriage return, classic MACs)
?>\r\n (CR/LF, on DOS/Win)
PHP doesn't support the Unicode combo linebreak NEL (U+0085) however.
Early PHP versions had IIRC compile-ins limiting platform-agnosticism somewhat (FI even just used > as close marker), which is the likely historic origin of the close-tag-avoidance.
Often overlooked, but until PHP7 removes them, the regular <?php opening token can be validly paired with the rarely used </script> as odd closing token.
The "hard close tag" isn't even one -- just made that term up for analogy. Conceptionally and usage-wise __halt_compiler should however be recognized as close token.
__HALT_COMPILER();
?>
Which basically has the tokenizer discard any code or plain HTML sections thereafter. In particular PHAR stubs make use of that, or its redundant combination with ?> as depicted.
Likewise does a void return; infrequently substitute in include scripts, rendering any ?> with trailing whitespace noneffective.
Then there are all kinds of soft / faux close tag variations; lesser known and seldomly used, but usually per commented-out tokens:
Simple spacing // ? > to evade detection by PHPs tokenizer.
Or fancy Unicode substitutes // ﹖﹥ (U+FE56 SMALL QUESTION MARK, U+FE65 SMALL ANGLE BRACKET) which a regexp can grasp.
Both mean nothing to PHP, but can have practical uses for PHP-unaware or semi-aware external toolkits. Again cat-joined scripts come to mind, with resulting // ? > <?php concatenations that inline-retain the former file sectioning.
So there are context-dependent but practical alternatives to an imperative close tag omission.
Manual babysitting of ?> close tags is not very contemporary either way. There always have been automation tools for that (even if just sed/awk or regex-oneliners). In particular:
phptags tag tidier
https://fossil.include-once.org/phptags/
Which could generally be used to --unclose php tags for third-party code, or rather just fix any (and all) actual whitespace/BOM issues:
phptags --warn --whitespace *.php
It also handles --long tag conversion etc. for runtime/configuration compatibility.
It isn't a tag…
But if you have it, you risk having white space after it.
If you then use it as an include at the top of a document, you could end up inserting white space (i.e. content) before you attempt to send HTTP headers … which isn't allowed.
According to the docs, it's preferable to omit the closing tag if it's at the end of the file for the following reason:
If a file is pure PHP code, it is preferable to omit the PHP closing tag at the end of the file. This prevents accidental whitespace or new lines being added after the PHP closing tag, which may cause unwanted effects because PHP will start output buffering when there is no intention from the programmer to send any output at that point in the script.
PHP Manual > Language Reference > Basic syntax > PHP tags
It's pretty useful not to let the closing ?> in.
The file stays valid to PHP (not a syntax error) and as #David Dorward said it allows to avoid having white space / break-line (anything that can send a header to the browser) after the ?>.
For example,
<?
header("Content-type: image/png");
$img = imagecreatetruecolor ( 10, 10);
imagepng ( $img);
?>
[space here]
[break line here]
won't be valid.
But
<?
header("Content-type: image/png");
$img = imagecreatetruecolor ( 10, 10 );
imagepng ( $img );
will.
For once, you must be lazy to be secure.
Well, I know the reason, but I can't show it:
For files that contain only PHP code, the closing tag (?>) is never
permitted. It is not required by PHP,
and omitting it prevents the
accidental injection of trailing white
space into the response.
Source: http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html
Well, there are two ways of looking at it.
PHP code is nothing more than a set of XML processing instructions, and therefore any file with a .php extension is nothing more than an XML file that just so happens to be parsed for PHP code.
PHP just so happens to share the XML processing instruction format for its open and close tags. Based on that, files with .php extensions MAY be valid XML files, but they don't need to be.
If you believe the first route, then all PHP files require closing end tags. To omit them will create an invalid XML file. Then again, without having an opening <?xml version="1.0" charset="latin-1" ?> declaration, you won't have a valid XML file anyway... So it's not a major issue...
If you believe the second route, that opens the door for two types of .php files:
Files that contain only code (library files for example)
Files that contain native XML and also code (template files for example)
Based on that, code-only files are OK to end without a closing ?> tag. But the XML-code files are not OK to end without a closing ?> since it would invalidate the XML.
But I know what you're thinking. You're thinking what does it matter, you're never going to render a PHP file directly, so who cares if it's valid XML. Well, it does matter if you're designing a template. If it's valid XML/HTML, a normal browser will simply not display the PHP code (it's treated like a comment). So you can mock out the template without needing to run the PHP code within...
I'm not saying this is important. It's just a view that I don't see expressed too often, so what better place to share it...
Personally, I do not close tags in library files, but do in template files... I think it's a personal preference (and coding guideline) based more than anything hard...
In addition to everything that's been said already, I'm going to throw in another reason that was a huge pain for us to debug.
Apache 2.4.6 with PHP 5.4 actually segmentation faults on our production machines when there's empty space behind the closing php tag. I just wasted hours until I finally narrowed down the bug with strace.
Here is the error that Apache throws:
[core:notice] [pid 7842] AH00052: child pid 10218 exit signal Segmentation fault (11)
"Is there another good reason (other than the header problem) to skip the ending php tag?"
You don't want to inadvertently output extraneous whitepace characters when generating binary output, CSV data, or other non-HTML output.
Pros
Would be logical to close any opened tag, like with other languages. Not only X(HT)ML tags, but as well curly braces, brackets...
Less confusing for beginners.
Cons
Avoids headache with adding inadvertently whitespaces after the closing tag, because it breaks the header() function behavior... Some editors or FTP clients / servers are also known to change automatically the end of files (at least, it's their default configuration)
PHP manual says closing tag is optional, and Zend even forbids it.
Conclusion
I would say that the arguments in favor of omitting the tag look stronger (helps to avoid big headache with header() + it's PHP/Zend "recommendation"). I admit that this isn't the most "beautiful" solution I've ever seen in terms of syntax consistency, but what could be better ?
As my question was marked as duplicate of this one, I think it's O.K. to post why NOT omitting closing tag ?> can be for some reasons desired.
With complete Processing Instructions Syntax (<?php ... ?>) PHP source is valid SGML document, which can be parsed and processed without problems with SGML parser. With additional restrictions it can be valid XML/XHTML as well.
Nothing prevents you from writing valid XML/HTML/SGML code. PHP documentation is aware of this. Excerpt:
Note: Also note that if you are embedding PHP within XML or XHTML you will need to use the < ?php ?> tags to remain compliant with standards.
Of course PHP syntax is not strict SGML/XML/HTML and you create a document, which is not SGML/XML/HTML, just like you can turn HTML into XHTML to be XML compliant or not.
At some point you may want to concatenate sources. This will be not as easy as simply doing cat source1.php source2.php if you have inconsistency introduced by omitting closing ?> tags.
Without ?> it's harder to tell if document was left in PHP escape mode or PHP ignore mode (PI tag <?php may have been opened or not). Life is easier if you consistently leave your documents in PHP ignore mode. It's just like work with well formatted HTML documents compared to documents with unclosed, badly nested tags etc.
It seems that some editors like Dreamweaver may have problems with PI left open [1].
If I understand the question correctly, it has to do with output buffering and the affect this might have on closing/ending tags. I am not sure that is an entirely valid question. The problem is that the output buffer does not mean all content is held in memory before sending it out to the client. It means some of the content is.
The programmer can purposely flush the buffer, or the output buffer so does the output buffer option in PHP really change how the closing tag affects coding? I would argue that it does not.
And maybe that is why most of the answers went back to personal style and syntax.
There are 2 possible use of php code:
PHP code such as class definition or function definition
Use PHP as a template language (i.e. in views)
in case 1. the closing tag is totally unusefull, also I would like to see just 1 (one) php open tag and NO (zero) closing tag in such a case. This is a good practice as it make code clean and separate logic from presentation.
For presentation case (2.) some found it is natural to close all tags (even the PHP-processed ones), that leads to confution, as the PHP has in fact 2 separate use case, that should not be mixed: logic/calculus and presentation
I keep reading it is poor practice to use the PHP close tag ?> at the end of the file. The header problem seems irrelevant in the following context (and this is the only good argument so far):
Modern versions of PHP set the output_buffering flag in php.ini
If output buffering is enabled, you can set HTTP headers and cookies after outputting HTML because the returned code is not sent to the browser immediately.
Every good practice book and wiki starts with this 'rule' but nobody offers good reasons.
Is there another good reason to skip the ending PHP tag?
Sending headers earlier than the normal course may have far reaching consequences. Below are just a few of them that happened to come to my mind at the moment:
While current PHP releases may have output buffering on, the actual production servers you will be deploying your code on are far more important than any development or testing machines. And they do not always tend to follow latest PHP trends immediately.
You may have headaches over inexplicable functionality loss. Say, you are implementing some kind payment gateway, and redirect user to a specific URL after successful confirmation by the payment processor. If some kind of PHP error, even a warning, or an excess line ending happens, the payment may remain unprocessed and the user may still seem unbilled. This is also one of the reasons why needless redirection is evil and if redirection is to be used, it must be used with caution.
You may get "Page loading canceled" type of errors in Internet Explorer, even in the most recent versions. This is because an AJAX response/json include contains something that it shouldn't contain, because of the excess line endings in some PHP files, just as I've encountered a few days ago.
If you have some file downloads in your app, they can break too, because of this. And you may not notice it, even after years, since the specific breaking habit of a download depends on the server, the browser, the type and content of the file (and possibly some other factors I don't want to bore you with).
Finally, many PHP frameworks including Symfony, Zend and Laravel (there is no mention of this in the coding guidelines but it follows the suit) and the PSR-2 standard (item 2.2) require omission of the closing tag. PHP manual itself (1,2), Wordpress, Drupal and many other PHP software I guess, advise to do so. If you simply make a habit of following the standard (and setup PHP-CS-Fixer for your code) you can forget the issue. Otherwise you will always need to keep the issue in your mind.
Bonus: a few gotchas (actually currently one) related to these 2 characters:
Even some well-known libraries may contain excess line endings after ?>. An example is Smarty, even the most recent versions of both 2.* and 3.* branch have this. So, as always, watch for third party code. Bonus in bonus: A regex for deleting needless PHP endings: replace (\s*\?>\s*)$ with empty text in all files that contain PHP code.
The reason you should leave off the php closing tag (?>) is so that the programmer doesn't accidentally send extra newline chars.
The reason you shouldn't leave off the php closing tag is because it causes an imbalance in the php tags and any programmer with half a mind can remember to not add extra white-space.
So for your question:
Is there another good reason to skip the ending php tag?
No, there isn't another good reason to skip the ending php tags.
I will finish with some arguments for not bothering with the closing tag:
People are always able to make mistakes, no matter how smart they are.
Adhering to a practice that reduces the number of possible mistakes is (IMHO) a good idea.
PHP is not XML. PHP doesn't need to adhere to XMLs strict standards to be well written and functional. If a missing closing tag annoys you, you're allowed to use a closing tag, it's not a set-in-stone rule one way or the other.
It's a newbie coding style recommendation, well-intentioned, and advised by the manual.
Eschewing ?> however solves just a trickle of the common headers already sent causes (raw output, BOM, notices, etc.) and their follow-up problems.
PHP actually contains some magic to eat up single linebreaks after the ?> closing token. Albeit that has historic issues, and leaves newcomers still susceptible to flaky editors and unawarely shuffling in other whitespace after ?>.
Stylistically some developers prefer to view <?php and ?> as SGML tags / XML processing instructions, implying the balance consistency of a trailing close token. (Which btw, is useful for dependency-conjoining class includes to supplant inefficient file-by-file autoloading.)
Somewhat uncommonly the opening <?php is characterized as PHPs shebang (and fully feasible per binfmt_misc), thereby validating the redundancy of a corresponding close tag.
There's an obvious advise discrepancy between classic PHP syntax guides mandating ?>\n and the more recent ones (PSR-2) agreeing on omission.
(For the record: Zend Framework postulating one over the other does not imply its inherent superiority. It's a misconception that experts were drawn to / target audience of unwieldy APIs).
SCMs and modern IDEs provide builtin solutions mostly alleviating close tag caretaking.
Discouraging any use of the ?> close tag merely delays explaining basic PHP processing behaviour and language semantics to eschew infrequent issues. It is practical still for collaborative software development due to proficiency variations in participants.
Close tag variations
The regular ?> close tag is also known as T_CLOSE_TAG, or thus "close token".
It comprises a few more incarnations, because of PHPs magic newline eating:
?>\n (Unix linefeed)
?>\r (Carriage return, classic MACs)
?>\r\n (CR/LF, on DOS/Win)
PHP doesn't support the Unicode combo linebreak NEL (U+0085) however.
Early PHP versions had IIRC compile-ins limiting platform-agnosticism somewhat (FI even just used > as close marker), which is the likely historic origin of the close-tag-avoidance.
Often overlooked, but until PHP7 removes them, the regular <?php opening token can be validly paired with the rarely used </script> as odd closing token.
The "hard close tag" isn't even one -- just made that term up for analogy. Conceptionally and usage-wise __halt_compiler should however be recognized as close token.
__HALT_COMPILER();
?>
Which basically has the tokenizer discard any code or plain HTML sections thereafter. In particular PHAR stubs make use of that, or its redundant combination with ?> as depicted.
Likewise does a void return; infrequently substitute in include scripts, rendering any ?> with trailing whitespace noneffective.
Then there are all kinds of soft / faux close tag variations; lesser known and seldomly used, but usually per commented-out tokens:
Simple spacing // ? > to evade detection by PHPs tokenizer.
Or fancy Unicode substitutes // ﹖﹥ (U+FE56 SMALL QUESTION MARK, U+FE65 SMALL ANGLE BRACKET) which a regexp can grasp.
Both mean nothing to PHP, but can have practical uses for PHP-unaware or semi-aware external toolkits. Again cat-joined scripts come to mind, with resulting // ? > <?php concatenations that inline-retain the former file sectioning.
So there are context-dependent but practical alternatives to an imperative close tag omission.
Manual babysitting of ?> close tags is not very contemporary either way. There always have been automation tools for that (even if just sed/awk or regex-oneliners). In particular:
phptags tag tidier
https://fossil.include-once.org/phptags/
Which could generally be used to --unclose php tags for third-party code, or rather just fix any (and all) actual whitespace/BOM issues:
phptags --warn --whitespace *.php
It also handles --long tag conversion etc. for runtime/configuration compatibility.
It isn't a tag…
But if you have it, you risk having white space after it.
If you then use it as an include at the top of a document, you could end up inserting white space (i.e. content) before you attempt to send HTTP headers … which isn't allowed.
According to the docs, it's preferable to omit the closing tag if it's at the end of the file for the following reason:
If a file is pure PHP code, it is preferable to omit the PHP closing tag at the end of the file. This prevents accidental whitespace or new lines being added after the PHP closing tag, which may cause unwanted effects because PHP will start output buffering when there is no intention from the programmer to send any output at that point in the script.
PHP Manual > Language Reference > Basic syntax > PHP tags
It's pretty useful not to let the closing ?> in.
The file stays valid to PHP (not a syntax error) and as #David Dorward said it allows to avoid having white space / break-line (anything that can send a header to the browser) after the ?>.
For example,
<?
header("Content-type: image/png");
$img = imagecreatetruecolor ( 10, 10);
imagepng ( $img);
?>
[space here]
[break line here]
won't be valid.
But
<?
header("Content-type: image/png");
$img = imagecreatetruecolor ( 10, 10 );
imagepng ( $img );
will.
For once, you must be lazy to be secure.
Well, I know the reason, but I can't show it:
For files that contain only PHP code, the closing tag (?>) is never
permitted. It is not required by PHP,
and omitting it prevents the
accidental injection of trailing white
space into the response.
Source: http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html
Well, there are two ways of looking at it.
PHP code is nothing more than a set of XML processing instructions, and therefore any file with a .php extension is nothing more than an XML file that just so happens to be parsed for PHP code.
PHP just so happens to share the XML processing instruction format for its open and close tags. Based on that, files with .php extensions MAY be valid XML files, but they don't need to be.
If you believe the first route, then all PHP files require closing end tags. To omit them will create an invalid XML file. Then again, without having an opening <?xml version="1.0" charset="latin-1" ?> declaration, you won't have a valid XML file anyway... So it's not a major issue...
If you believe the second route, that opens the door for two types of .php files:
Files that contain only code (library files for example)
Files that contain native XML and also code (template files for example)
Based on that, code-only files are OK to end without a closing ?> tag. But the XML-code files are not OK to end without a closing ?> since it would invalidate the XML.
But I know what you're thinking. You're thinking what does it matter, you're never going to render a PHP file directly, so who cares if it's valid XML. Well, it does matter if you're designing a template. If it's valid XML/HTML, a normal browser will simply not display the PHP code (it's treated like a comment). So you can mock out the template without needing to run the PHP code within...
I'm not saying this is important. It's just a view that I don't see expressed too often, so what better place to share it...
Personally, I do not close tags in library files, but do in template files... I think it's a personal preference (and coding guideline) based more than anything hard...
In addition to everything that's been said already, I'm going to throw in another reason that was a huge pain for us to debug.
Apache 2.4.6 with PHP 5.4 actually segmentation faults on our production machines when there's empty space behind the closing php tag. I just wasted hours until I finally narrowed down the bug with strace.
Here is the error that Apache throws:
[core:notice] [pid 7842] AH00052: child pid 10218 exit signal Segmentation fault (11)
"Is there another good reason (other than the header problem) to skip the ending php tag?"
You don't want to inadvertently output extraneous whitepace characters when generating binary output, CSV data, or other non-HTML output.
Pros
Would be logical to close any opened tag, like with other languages. Not only X(HT)ML tags, but as well curly braces, brackets...
Less confusing for beginners.
Cons
Avoids headache with adding inadvertently whitespaces after the closing tag, because it breaks the header() function behavior... Some editors or FTP clients / servers are also known to change automatically the end of files (at least, it's their default configuration)
PHP manual says closing tag is optional, and Zend even forbids it.
Conclusion
I would say that the arguments in favor of omitting the tag look stronger (helps to avoid big headache with header() + it's PHP/Zend "recommendation"). I admit that this isn't the most "beautiful" solution I've ever seen in terms of syntax consistency, but what could be better ?
As my question was marked as duplicate of this one, I think it's O.K. to post why NOT omitting closing tag ?> can be for some reasons desired.
With complete Processing Instructions Syntax (<?php ... ?>) PHP source is valid SGML document, which can be parsed and processed without problems with SGML parser. With additional restrictions it can be valid XML/XHTML as well.
Nothing prevents you from writing valid XML/HTML/SGML code. PHP documentation is aware of this. Excerpt:
Note: Also note that if you are embedding PHP within XML or XHTML you will need to use the < ?php ?> tags to remain compliant with standards.
Of course PHP syntax is not strict SGML/XML/HTML and you create a document, which is not SGML/XML/HTML, just like you can turn HTML into XHTML to be XML compliant or not.
At some point you may want to concatenate sources. This will be not as easy as simply doing cat source1.php source2.php if you have inconsistency introduced by omitting closing ?> tags.
Without ?> it's harder to tell if document was left in PHP escape mode or PHP ignore mode (PI tag <?php may have been opened or not). Life is easier if you consistently leave your documents in PHP ignore mode. It's just like work with well formatted HTML documents compared to documents with unclosed, badly nested tags etc.
It seems that some editors like Dreamweaver may have problems with PI left open [1].
If I understand the question correctly, it has to do with output buffering and the affect this might have on closing/ending tags. I am not sure that is an entirely valid question. The problem is that the output buffer does not mean all content is held in memory before sending it out to the client. It means some of the content is.
The programmer can purposely flush the buffer, or the output buffer so does the output buffer option in PHP really change how the closing tag affects coding? I would argue that it does not.
And maybe that is why most of the answers went back to personal style and syntax.
There are 2 possible use of php code:
PHP code such as class definition or function definition
Use PHP as a template language (i.e. in views)
in case 1. the closing tag is totally unusefull, also I would like to see just 1 (one) php open tag and NO (zero) closing tag in such a case. This is a good practice as it make code clean and separate logic from presentation.
For presentation case (2.) some found it is natural to close all tags (even the PHP-processed ones), that leads to confution, as the PHP has in fact 2 separate use case, that should not be mixed: logic/calculus and presentation
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Why do some scripts omit the closing php tag '?>'?
I've been reading some articles about Omitting Closing PHP tags since they say it is a good programming practice in PHP if your .php file doens't contain any other things. There are many questions like that but after I tried what they've done so far worked well on my machine. Maybe it is a fixed issue or something?
But I don't quite understand why it could be a good programming practice since it brings space or something but I've tried this one and works very well.
Master.php
<?php
echo "Master.php";
include "Slave.php";
header("Location:Slave.php");
?>
Slave.php
<?php
echo "Slave.php";
?>
I don't really quite get what the problem should be if I didn't use closing php tag.
Thanks.
The main issue is you may include additional whitespace (but it can be any chars) after the closing ?> (besides one \n which PHP allows, thanks Mario).
This extra whitespace appears to PHP as output to be sent. This makes PHP start sending the response body, therefore making any additional headers being set/modified impossible.
This is hard to debug (as whitespace is generally invisible in text editors) and often the cause of the dreaded Headers already sent error.
the problem with the closing tag is that any whitespace after the last ?> may cause bugs and is very difficult to detect while bug fixing.
It is usually better to NOT end your script with closing PHP tag.
In your case a whitespace could remain after ?> (it is very sneaky and hard to tell where error is if something breaks because of this reason), so it would be considered as output and you won't be able to start session, for example or pass headers in case if you are developing a website.
Just my opinion. I likely never end my scripts with closing tag
The problem comes from having any number of line breaks other than 1: some php parsers get upset if there isn't a newline at that end, but if you have more than one, it is printed since anything outside php tags is considered HTML.
The most common problem is that a library/model file will have an extra line break, causing the headers to be sent long before the page/view is instantiated.
I keep reading it is poor practice to use the PHP close tag ?> at the end of the file. The header problem seems irrelevant in the following context (and this is the only good argument so far):
Modern versions of PHP set the output_buffering flag in php.ini
If output buffering is enabled, you can set HTTP headers and cookies after outputting HTML because the returned code is not sent to the browser immediately.
Every good practice book and wiki starts with this 'rule' but nobody offers good reasons.
Is there another good reason to skip the ending PHP tag?
Sending headers earlier than the normal course may have far reaching consequences. Below are just a few of them that happened to come to my mind at the moment:
While current PHP releases may have output buffering on, the actual production servers you will be deploying your code on are far more important than any development or testing machines. And they do not always tend to follow latest PHP trends immediately.
You may have headaches over inexplicable functionality loss. Say, you are implementing some kind payment gateway, and redirect user to a specific URL after successful confirmation by the payment processor. If some kind of PHP error, even a warning, or an excess line ending happens, the payment may remain unprocessed and the user may still seem unbilled. This is also one of the reasons why needless redirection is evil and if redirection is to be used, it must be used with caution.
You may get "Page loading canceled" type of errors in Internet Explorer, even in the most recent versions. This is because an AJAX response/json include contains something that it shouldn't contain, because of the excess line endings in some PHP files, just as I've encountered a few days ago.
If you have some file downloads in your app, they can break too, because of this. And you may not notice it, even after years, since the specific breaking habit of a download depends on the server, the browser, the type and content of the file (and possibly some other factors I don't want to bore you with).
Finally, many PHP frameworks including Symfony, Zend and Laravel (there is no mention of this in the coding guidelines but it follows the suit) and the PSR-2 standard (item 2.2) require omission of the closing tag. PHP manual itself (1,2), Wordpress, Drupal and many other PHP software I guess, advise to do so. If you simply make a habit of following the standard (and setup PHP-CS-Fixer for your code) you can forget the issue. Otherwise you will always need to keep the issue in your mind.
Bonus: a few gotchas (actually currently one) related to these 2 characters:
Even some well-known libraries may contain excess line endings after ?>. An example is Smarty, even the most recent versions of both 2.* and 3.* branch have this. So, as always, watch for third party code. Bonus in bonus: A regex for deleting needless PHP endings: replace (\s*\?>\s*)$ with empty text in all files that contain PHP code.
The reason you should leave off the php closing tag (?>) is so that the programmer doesn't accidentally send extra newline chars.
The reason you shouldn't leave off the php closing tag is because it causes an imbalance in the php tags and any programmer with half a mind can remember to not add extra white-space.
So for your question:
Is there another good reason to skip the ending php tag?
No, there isn't another good reason to skip the ending php tags.
I will finish with some arguments for not bothering with the closing tag:
People are always able to make mistakes, no matter how smart they are.
Adhering to a practice that reduces the number of possible mistakes is (IMHO) a good idea.
PHP is not XML. PHP doesn't need to adhere to XMLs strict standards to be well written and functional. If a missing closing tag annoys you, you're allowed to use a closing tag, it's not a set-in-stone rule one way or the other.
It's a newbie coding style recommendation, well-intentioned, and advised by the manual.
Eschewing ?> however solves just a trickle of the common headers already sent causes (raw output, BOM, notices, etc.) and their follow-up problems.
PHP actually contains some magic to eat up single linebreaks after the ?> closing token. Albeit that has historic issues, and leaves newcomers still susceptible to flaky editors and unawarely shuffling in other whitespace after ?>.
Stylistically some developers prefer to view <?php and ?> as SGML tags / XML processing instructions, implying the balance consistency of a trailing close token. (Which btw, is useful for dependency-conjoining class includes to supplant inefficient file-by-file autoloading.)
Somewhat uncommonly the opening <?php is characterized as PHPs shebang (and fully feasible per binfmt_misc), thereby validating the redundancy of a corresponding close tag.
There's an obvious advise discrepancy between classic PHP syntax guides mandating ?>\n and the more recent ones (PSR-2) agreeing on omission.
(For the record: Zend Framework postulating one over the other does not imply its inherent superiority. It's a misconception that experts were drawn to / target audience of unwieldy APIs).
SCMs and modern IDEs provide builtin solutions mostly alleviating close tag caretaking.
Discouraging any use of the ?> close tag merely delays explaining basic PHP processing behaviour and language semantics to eschew infrequent issues. It is practical still for collaborative software development due to proficiency variations in participants.
Close tag variations
The regular ?> close tag is also known as T_CLOSE_TAG, or thus "close token".
It comprises a few more incarnations, because of PHPs magic newline eating:
?>\n (Unix linefeed)
?>\r (Carriage return, classic MACs)
?>\r\n (CR/LF, on DOS/Win)
PHP doesn't support the Unicode combo linebreak NEL (U+0085) however.
Early PHP versions had IIRC compile-ins limiting platform-agnosticism somewhat (FI even just used > as close marker), which is the likely historic origin of the close-tag-avoidance.
Often overlooked, but until PHP7 removes them, the regular <?php opening token can be validly paired with the rarely used </script> as odd closing token.
The "hard close tag" isn't even one -- just made that term up for analogy. Conceptionally and usage-wise __halt_compiler should however be recognized as close token.
__HALT_COMPILER();
?>
Which basically has the tokenizer discard any code or plain HTML sections thereafter. In particular PHAR stubs make use of that, or its redundant combination with ?> as depicted.
Likewise does a void return; infrequently substitute in include scripts, rendering any ?> with trailing whitespace noneffective.
Then there are all kinds of soft / faux close tag variations; lesser known and seldomly used, but usually per commented-out tokens:
Simple spacing // ? > to evade detection by PHPs tokenizer.
Or fancy Unicode substitutes // ﹖﹥ (U+FE56 SMALL QUESTION MARK, U+FE65 SMALL ANGLE BRACKET) which a regexp can grasp.
Both mean nothing to PHP, but can have practical uses for PHP-unaware or semi-aware external toolkits. Again cat-joined scripts come to mind, with resulting // ? > <?php concatenations that inline-retain the former file sectioning.
So there are context-dependent but practical alternatives to an imperative close tag omission.
Manual babysitting of ?> close tags is not very contemporary either way. There always have been automation tools for that (even if just sed/awk or regex-oneliners). In particular:
phptags tag tidier
https://fossil.include-once.org/phptags/
Which could generally be used to --unclose php tags for third-party code, or rather just fix any (and all) actual whitespace/BOM issues:
phptags --warn --whitespace *.php
It also handles --long tag conversion etc. for runtime/configuration compatibility.
It isn't a tag…
But if you have it, you risk having white space after it.
If you then use it as an include at the top of a document, you could end up inserting white space (i.e. content) before you attempt to send HTTP headers … which isn't allowed.
According to the docs, it's preferable to omit the closing tag if it's at the end of the file for the following reason:
If a file is pure PHP code, it is preferable to omit the PHP closing tag at the end of the file. This prevents accidental whitespace or new lines being added after the PHP closing tag, which may cause unwanted effects because PHP will start output buffering when there is no intention from the programmer to send any output at that point in the script.
PHP Manual > Language Reference > Basic syntax > PHP tags
It's pretty useful not to let the closing ?> in.
The file stays valid to PHP (not a syntax error) and as #David Dorward said it allows to avoid having white space / break-line (anything that can send a header to the browser) after the ?>.
For example,
<?
header("Content-type: image/png");
$img = imagecreatetruecolor ( 10, 10);
imagepng ( $img);
?>
[space here]
[break line here]
won't be valid.
But
<?
header("Content-type: image/png");
$img = imagecreatetruecolor ( 10, 10 );
imagepng ( $img );
will.
For once, you must be lazy to be secure.
Well, I know the reason, but I can't show it:
For files that contain only PHP code, the closing tag (?>) is never
permitted. It is not required by PHP,
and omitting it prevents the
accidental injection of trailing white
space into the response.
Source: http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html
Well, there are two ways of looking at it.
PHP code is nothing more than a set of XML processing instructions, and therefore any file with a .php extension is nothing more than an XML file that just so happens to be parsed for PHP code.
PHP just so happens to share the XML processing instruction format for its open and close tags. Based on that, files with .php extensions MAY be valid XML files, but they don't need to be.
If you believe the first route, then all PHP files require closing end tags. To omit them will create an invalid XML file. Then again, without having an opening <?xml version="1.0" charset="latin-1" ?> declaration, you won't have a valid XML file anyway... So it's not a major issue...
If you believe the second route, that opens the door for two types of .php files:
Files that contain only code (library files for example)
Files that contain native XML and also code (template files for example)
Based on that, code-only files are OK to end without a closing ?> tag. But the XML-code files are not OK to end without a closing ?> since it would invalidate the XML.
But I know what you're thinking. You're thinking what does it matter, you're never going to render a PHP file directly, so who cares if it's valid XML. Well, it does matter if you're designing a template. If it's valid XML/HTML, a normal browser will simply not display the PHP code (it's treated like a comment). So you can mock out the template without needing to run the PHP code within...
I'm not saying this is important. It's just a view that I don't see expressed too often, so what better place to share it...
Personally, I do not close tags in library files, but do in template files... I think it's a personal preference (and coding guideline) based more than anything hard...
In addition to everything that's been said already, I'm going to throw in another reason that was a huge pain for us to debug.
Apache 2.4.6 with PHP 5.4 actually segmentation faults on our production machines when there's empty space behind the closing php tag. I just wasted hours until I finally narrowed down the bug with strace.
Here is the error that Apache throws:
[core:notice] [pid 7842] AH00052: child pid 10218 exit signal Segmentation fault (11)
"Is there another good reason (other than the header problem) to skip the ending php tag?"
You don't want to inadvertently output extraneous whitepace characters when generating binary output, CSV data, or other non-HTML output.
Pros
Would be logical to close any opened tag, like with other languages. Not only X(HT)ML tags, but as well curly braces, brackets...
Less confusing for beginners.
Cons
Avoids headache with adding inadvertently whitespaces after the closing tag, because it breaks the header() function behavior... Some editors or FTP clients / servers are also known to change automatically the end of files (at least, it's their default configuration)
PHP manual says closing tag is optional, and Zend even forbids it.
Conclusion
I would say that the arguments in favor of omitting the tag look stronger (helps to avoid big headache with header() + it's PHP/Zend "recommendation"). I admit that this isn't the most "beautiful" solution I've ever seen in terms of syntax consistency, but what could be better ?
As my question was marked as duplicate of this one, I think it's O.K. to post why NOT omitting closing tag ?> can be for some reasons desired.
With complete Processing Instructions Syntax (<?php ... ?>) PHP source is valid SGML document, which can be parsed and processed without problems with SGML parser. With additional restrictions it can be valid XML/XHTML as well.
Nothing prevents you from writing valid XML/HTML/SGML code. PHP documentation is aware of this. Excerpt:
Note: Also note that if you are embedding PHP within XML or XHTML you will need to use the < ?php ?> tags to remain compliant with standards.
Of course PHP syntax is not strict SGML/XML/HTML and you create a document, which is not SGML/XML/HTML, just like you can turn HTML into XHTML to be XML compliant or not.
At some point you may want to concatenate sources. This will be not as easy as simply doing cat source1.php source2.php if you have inconsistency introduced by omitting closing ?> tags.
Without ?> it's harder to tell if document was left in PHP escape mode or PHP ignore mode (PI tag <?php may have been opened or not). Life is easier if you consistently leave your documents in PHP ignore mode. It's just like work with well formatted HTML documents compared to documents with unclosed, badly nested tags etc.
It seems that some editors like Dreamweaver may have problems with PI left open [1].
If I understand the question correctly, it has to do with output buffering and the affect this might have on closing/ending tags. I am not sure that is an entirely valid question. The problem is that the output buffer does not mean all content is held in memory before sending it out to the client. It means some of the content is.
The programmer can purposely flush the buffer, or the output buffer so does the output buffer option in PHP really change how the closing tag affects coding? I would argue that it does not.
And maybe that is why most of the answers went back to personal style and syntax.
There are 2 possible use of php code:
PHP code such as class definition or function definition
Use PHP as a template language (i.e. in views)
in case 1. the closing tag is totally unusefull, also I would like to see just 1 (one) php open tag and NO (zero) closing tag in such a case. This is a good practice as it make code clean and separate logic from presentation.
For presentation case (2.) some found it is natural to close all tags (even the PHP-processed ones), that leads to confution, as the PHP has in fact 2 separate use case, that should not be mixed: logic/calculus and presentation
The Zend Framework coding standard mentions the following:
For files that contain only PHP code, the closing tag ("?>") is never permitted. It is not required by PHP, and omitting it prevents the accidental injection of trailing whitespace into the response.
Zend Framework coding standard: file formatting
However I do remember hearing about an issue (with tooling or including maybe?) where files needed to have closing tag.
Does anyone know of any issues (other than the developer issue of wanting symmetry) where you would need to have closing tags or are they generally a bad idea?
Removing the closing tags when you can is probably a best practice really. The reason for that is because if you have any character (even whitespace) outside of the ?> in a php file it can stop thing such as headers to stop working if the character gets sent to the browser before the header gets set.
If you use closing PHP tags then you can easily find files that have been accidentally truncated (e.g. haven't been uploaded completely).
However such problem should be fixed by making filesystem and transfers reliable rather than adding PHP "canary" tags :)
Another possible reason is that PEAR coding standards require it. They require it, because they require it and you're not allowed to question PEAR coding standards.
You could consider the php opening tag for php-only files, as a sort of shebang line (like #!/bin/bash), in that way, you don't need a closing tag.
We follow the ZF standard as well, no closing tag for php-only files. But I've never heard of any tool which couldn't parse a file because of a missing closing tag, and I haven't gotten into any problems as of yet for not using it.
I always write the closing tag for php files, and purposefully don't follow it with spaces or eol.
The standard implies that if the closing tag is omitted, one will be implicitly supplied. But that doesn't exonerate the developer from writing proper html/xml.
And there may be cases where two files are combined outside of html/php processing, and a missing tag would cause extreme grief.
I always put them in because I view them as a fancy closing brace - as when I write conditionals and loops I put in the open/close brace pair before writing code, I do with PHP files.
Whether it's "right" or not, I semi-frequently find myself turning "pure" PHP files into "nonpure", and the closing tag is extremely helpful.
i always use the closing tags, it just doesn't look nice without them. It's also not a valid xml Processing instruction without them (not that you care if the only thing in the file is php)
We use Drupal, which always omits the closing tag, and never had any problems because of it.
Since it always worked for Drupal (and I knew from reading the manual it was optional), I once created a configuration file (which contained only PHP code) without the closing tag. For some reason, it did not work until (at the insistence of a coworker) I added the closing tag. We didn't try to find out the cause at the time.
I have always used the closing tag in code I write; it looks more simmetrical, conceptually "closes" the opening tag, and I am always careful to not leave any extra whitespace after the closing tag.
Checking for coding errors doesn't work when concating multiple files. I use the following shell command to check for errors.
find . -name '*.php' | xargs cat | php -l
Of course the following command still works (and displays the filename of the corrupted file)
find . -name '*.php' | while read filename; do php -l $filename | grep -v 'No syntax errors '; done
But this one is much much slower.
Our office works with e-learning apps built in Flash and we discovered early on that if the closing tag is omitted from the server side scripts then it breaks our communication mechanism with the e-learnng apps.
One caveat to this would be that our debuggng process didn't first try it in a simplified environment to make sure that it wasn't a combination of the missing closing tags and some erroneous output coming from some other script....
In reply to #gabriel1836, the closing tags on the server side are irrelevant when it comes to Flash applications; what's relevant is the payload returned by the server in response to a remoting request by the Flash application. Omitting the closing tag on PHP-only files will affect this only in ensuring that spurious output is not returned prior to headers being sent to your Flash app.
In reply to #CesarB, unless you can give a concrete, reproducible example, all you're doing is spreading FUD. The PHP manual is very clear that the closing tag is optional.