Closing PHP tag in Lithium - php

As you know most PHP sources deprecated inserting closing tag, but I wonder why in Lithium documentation, it is encouraged to include a closing PHP tag? Is there any rational reason for that? Beside that there is some other obsolete style in its documentation. Is Lithium an active project?
Update: Even opening php tag in a file that contains only PHP seems redundant and we include it because currently we have to do that, (if there was a standard file extension for files that have only php code no need for opening tag remained), but more odd is that somebodies even say that we should include a closing tag!

Omitting closing tags is sloppy.
The only excuse anyone ever gives for doing it is that you might accidentally leave some trailing whitespace, causing headers to be sent prematurely. Here's why this justification is completely bogus:
If you have Xdebug installed (and if you don't, you have bigger problems), it'll tell you exactly where your output has started if you try to write a header
I find this kind of behavior symptomatic of an overall lack of attention to detail; chances are, if you got this wrong, there are other things wrong with your code as well (or you have a shitty/poorly-configured editor)
This is completely negated by good QA tooling: we have li3_quality, which is a comprehensive code quality validator
Essentially, people are justifying sloppiness with the worst form of laziness.
If you browse through Lithium's coding standard, you'll notice the high level of attention paid to symmetry. Everything in the coding standard is symmetrical. Including open/close tags. Doing so is never a problem for us, because we have good QA tooling.

Lithium Coding Standards
The link reffered to in the question ... Coding Standards ... is just that, what the Lithium devs believe are the best coding standards for their project. I personally agree that a closing tag is preferable.
While the PHP docs say it's "preferable" to not use the close tag if it's "pure" PHP code (mostly so you don't accidental add white space or something after it) a simple way to avoid that is to not do it in the first place. I prefer leaving in the tag so that ...
The code looks more uniform
To insure server compatibility
For better support of color-coding etc in text editors
This is also somewhat a misunderstanding of how Lithium works ... the examples given are for files that act as Controllers, Models, etc. These files are for the most part not directly accessed by end user requests like the Views are (well for lack of a simpler way to explain it.)
Is Lithium an active project?
As for if Lithium is an "active" project I suggest referring to their ...
git repo https://github.com/UnionOfRAD/lithium
commit history: https://github.com/UnionOfRAD/lithium/graphs/commit-activity
dev branch https://github.com/UnionOfRAD/lithium/tree/dev
dev commit history https://github.com/UnionOfRAD/lithium/commits/dev
As of this post the last dev branch commit was 10 hours ago.
Lithium's use of "short" tags ...
For the record, other examples in the Lithium doc's use the so called PHP "short" tags e.g. <?= ... ?> instead of: <?php ... ?> comes with an important caveat see the docs:
You might have noticed that the above example uses the short tag
syntax to output the contents of a view variable. This syntax is a bit
misleading, as Lithium does not depend on or use short tags: this
output behavior works a bit differently from how it seems. When the
view layer is rendered, each template is processed by a tokenizer
before it is compiled into its final form. During this step something
like this:
<?=$variable; ?>
Is translated into something like this:
<?php echo $h($variable); ?>
The $h() function you see used there escapes HTML. To make a long
story short, this mechanism provides an easy way for you to make sure
all dynamically-generated data is safely landing in your HTML
template.
We highly recommend using the <?= ...; ?> syntax in your views, as
it aids greatly in hardening your application against cross-site
scripting (and related) attack techniques.

Related

PHP 7.2 Apache not executing all php code [duplicate]

Here's the information according to the official documentation:
There are four different pairs of
opening and closing tags which can be
used in PHP. Two of those, <?php ?>
and <script language="php"> </script>,
are always available. The other two
are short tags and ASP style tags, and
can be turned on and off from the
php.ini configuration file. As such,
while some people find short tags and
ASP style tags convenient, they are
less portable, and generally not
recommended.
In my experience most servers do have short tags enabled. Typing
<?=
is far more convenient than typing
<?php echo
The programmers convenience is an important factor, so why are they not recommended?
There must be a clear distinction between the PHP short tag (<?) and shorthand echo tag (<?=)
The former is prohibited by the PHP Coding standard, mostly out of common sense because it's a PITA if you ever have to move your code to a server where it's not supported (and you can't enable it). As you say, lots of shared hosts do support shorttags but "lots" isn't all of them. If you want to share your scripts, it's best to use the full syntax.
Whereas the shorthand echo tag <?= cannot be disabled and therefore is fully acceptable to use.
I agree that <? is easier on programmers than <?php but it is possible to do a bulk find-and-replace as long as you use the same form each time.
I don't buy readability as a reason at all. Most serious developers have the option of syntax highlighting available to them.
As ThiefMaster mentions in the comments, as of PHP 5.4, <?= ... ?> tags are supported everywhere, regardless of shorttags settings. This should mean they're safe to use in portable code but that does mean there's then a dependency on PHP 5.4+. If you want to support pre-5.4 and can't guarantee shorttags, you'll still need to use <?php echo ... ?>.
Also, you need to know that ASP tags <% , %> , <%= , and script tag are removed from PHP 7. So if you would like to support long-term portable code and would like switching to the most modern tools consider changing that parts of code.
I'm too fond of <?=$whatever?> to let it go. Never had a problem with it. I'll wait until it bites me in the ass. In all seriousness, 85% of (my) clients have access to php.ini in the rare occasion they are turned off. The other 15% use mainstream hosting providers, and virtually all of them have them enabled. I love 'em.
Starting with PHP 5.4, the echo shortcut is a separate issue from short tags, as the echo shortcut will always be enabled. It's a fact now:
SVN Revision by Rasmus Lerdorf
Mailing list discussion
So the echo shortcut itself (<?=) is safe to use now.
The problem with this whole discussion lies in the use of PHP as a templating language. No one is arguing that tags should be used in application source files.
However PHP's embeddable syntax allows it to be used as a powerful template language, and templates should be as simple and readable as possible. Many have found it easier to use a much slower, add-on templating engine like Smarty, but for those purists among us who demand fast rendering and a pure code base, PHP is the only way to write templates.
The ONLY valid argument AGAINST the use of short tags is that they aren't supported on all servers. Comments about conflicts with XML documents are ludicrous, because you probably shouldn't be mixing PHP and XML anyway; and if you are, you should be using PHP to output strings of text. Security should never be an issue, because if you're putting sensitive information like database access credentials inside of template files, well then, you've got bigger issues!
Now then, as to the issue of server support, admittedly one has to be aware of their target platform. If shared hosting is a likely target, then short tags should be avoided. But for many professional developers (such as myself), the client acknowledges (and indeed, depends on the fact) that we will be dictating the server requirements. Often I'm responsible for setting up the server myself.
And we NEVER work with a hosting provider that does not give us absolute control of the server configuration -- in such a case we could count on running to much more trouble than just losing short tag support. It just doesn't happen.
So yes -- I agree that the use of short tags should be carefully weighed. But I also firmly believe that it should ALWAYS be an option, and that a developer who is aware of his environment should feel free to use them.
Short tags are coming back thanks to Zend Framework pushing the "PHP as a template language" in their default MVC configuration. I don't see what the debate is about, most of the software you will produce during your lifetime will operate on a server you or your company will control. As long as you keep yourself consistent, there shouldn't be any problems.
UPDATE
After doing quite a bit of work with Magento, which uses long form. As a result, I've switched to the long form of:
<?php and <?php echo
over
<? and <?=
Seems like a small amount of work to assure interoperability.
Because the confusion it can generate with XML declarations. Many people agree with you, though.
An additional concern is the pain it'd generate to code everything with short tags only to find out at the end that the final hosting server has them turned off...
Following is the wonderful flow diagram of the same:
Source: similiar question on Software Engineering Stack Exchange
In case anyone's still paying attention to this... As of PHP 5.4.0 Alpha 1 <?= is always available:
http://php.net/releases/NEWS_5_4_0_alpha1.txt
So it looks like short tags are (a) acceptable and (b) here to stay. For now at least...
http://uk3.php.net/manual/en/language.basic-syntax.phpmode.php has plenty of advice, including:
while some people find short tags and
ASP style tags convenient, they are
less portable, and generally not
recommended.
and
note that if you are embedding PHP
within XML or XHTML you will need to
use the <?php ?> tags to remain
compliant with standards.
and
Using short tags should be avoided
when developing applications or
libraries that are meant for
redistribution, or deployment on PHP
servers which are not under your
control, because short tags may not be
supported on the target server. For
portable, redistributable code, be
sure not to use short tags.
Short tags are not turned on by default in some webservers (shared hosts, etc.), so code portability becomes an issue if you need to move to one of these.
Readability may be an issue for some. Many developers may find that <?php catches the eye as a more obvious marker of the beginning of a code block than <? when you scan a file, particularly if you're stuck with a code base with HTML and PHP tightly inter-woven.
Note: Starting in PHP 5.4 the short tag, <?=, is now always available.
I read this page after looking for information on the topic, and I feel that one major issue has not been mentioned: laziness vs. consistency. The "real" tags for PHP are <?php and ?>. Why? I don't really care. Why would you want to use something else when those are clearly for PHP? <% and %> mean ASP to me, and <script ..... means Javascript (in most cases). So for consistency, fast learning, portability, and simplicity, why not stick to the standard?
On the other hand I agree that short tags in templates (and ONLY in templates) seem useful, but the problem is that we've just spent so much time discussing it here, that it would likely take a very long time to have actually wasted that much time typing the extra three characters of "php"!!
While having many options is nice, it's not at all logical and it can cause problems. Imagine if every programming language allowed 4 or more types of tags: Javascript could be <JS or < script .... or <% or <? JS.... would that be helpful? In the case of PHP the parsing order tends to be in favor of allowing these things, but the language is in many other ways not flexible: it throws notices or errors upon the slightest inconsistency, yet short tags are used often. And when short tags are used on a server that doesn't support them, it can take a very long time to figure out what is wrong since no error is given in some cases.
Finally, I don't think that short tags are the problem here: there are only two logical types of PHP code blocks-- 1) regular PHP code, 2) template echoes.
For the former, I firmly believe that only <?php and ?> should be allowed just to keep everything consistent and portable.
For the latter, the <?=$var?> method is ugly. Why must it be like this? Why not add something much more logical?
<?php $var ?>
That would not do anything (and only in the most remote possibilities could it conflict with something), and that could easily replace the awkward <?= syntax. Or if that's a problem, perhaps they could use <?php=$var?> instead and not worry about inconsistencies.
At the point where there are 4 options for open and close tags and the random addition of a special "echo" tag, PHP may as well have a "custom open/close tags" flag in php.ini or .htaccess. That way designers can choose the one they like best. But for obvious reasons that's overkill. So why allow 4+ options?
As of 2019 I disagree with certain answers here. Recommended to use:
1. Long tags
<?php /* code goes here */ ?>
2. Short echo tags
<?= /* code goes here */ ?>
Reason: They are recommended by the PSR-1 basic coding standard
Other short tags like <? /* code goes here */ ?> are not recommended.
The spec says:
PHP code MUST use the long tags or the short-echo
tags; it MUST NOT use the other tag variations.
One situation that is a little different is when developing a CodeIgniter application. CodeIgniter seems to use the shorttags whenever PHP is being used in a template/view, otherwise with models and controllers it always uses the long tags. It's not a hard and fast rule in the framework, but for the most part the framework and a lot of the source from other uses follows this convention.
My two cents? If you never plan on running the code somewhere else, then use them if you want. I'd rather not have to do a massive search and replace when I realize it was a dumb idea.
<? is disabled by default in newer versions. You can enable this like described Enabling Short Tags in PHP.
I thought it worth mentioning that as of PHP 7:
Short ASP PHP tags <% … %> are gone
Short PHP tabs <? … ?> are still available if short_open_tag is set to true. This is the default.
Since PHP 5.4, Short Print tags <?=… ?> are always enabled, regardless of the short_open_tag setting.
Good riddance to the first one, as it interfered with other languages.
There is now no reason not to use the short print tags, apart from personal preference.
Of course, if you’re writing code to be compatible with legacy versions of PHP 5, you will need to stick to the old rules, but remember that anything before PHP 5.6 is now unsupported.
See: https://secure.php.net/manual/en/language.basic-syntax.phptags.php
Note also the the above reference discourages the second version (<? … ?>) since it may have been disabled:
Note:
As short tags can be disabled it is recommended to only use the normal tags (<?php ?> and <?= ?>) to maximise compatibility.
IMHO people who use short tags often forget to escape whatever they're echoing. It would be nice to have a template engine that escapes by default. I believe Rob A wrote a quick hack to escape short tags in Zend Frameworks apps. If you like short tags because it makes PHP easier to read. Then might Smarty be a better option?
{$myString|escape}
to me that looks better than
<?= htmlspecialchars($myString) ?>
It's good to use them when you work with a MVC framework or CMS that have separate view files. It's fast, less code, not confusing for the designers. Just make sure your server configuration allows using them.
One has to ask what the point of using short tags is.
Quicker to type
MDCore said:
<?= is far more convenient than typing <?php echo
Yes, it is. You save having to type 7 characters * X times throughout your scripts.
However, when a script takes an hour, or 10 hours, or more, to design, develop, and write, how relevant is the few seconds of time not typing those 7 chars here and there for the duration of the script?
Compared to the potential for some core, or all, of you scripts not working if short tags are not turned on, or are on but an update or someone changing the ini file/server config stops them working, other potentials.
The small benefit you gain doesn't comes close to outweighing the severity of the potential problems, that is your site not working, or worse, only parts of it not working and thus a headache to resolve.
Easier to read
This depends on familiarity.
I've always seen and used <?php echo. So while <?= is not hard to read, it's not familiar to me and thus not easier to read.
And with front end/back end developer split (as with most companies) would a front end developer working on those templates be more familiar knowing <?= is equal to "PHP open tag and echo"?
I would say most would be more comfortable with the more logical one. That is, a clear PHP open tag and then what is happening "echo" - <?php echo.
Risk assessment
Issue = entire site or core scripts fail to work;
The potential of issue is very low + severity of outcome is very high = high risk
Conclusion
You save a few seconds here and there not having to type a few chars, but risk a lot for it, and also likely lose readability as a result.
Front or back end coders familiar with <?= are more likely to understand <?php echo, as they're standard PHP things - standard <?php open tag and very well known "echo".
(Even front end coders should know "echo" or they simply wont be working on any code served by a framework).
Whereas the reverse is not as likely, someone is not likely to logically deduce that the equals sign on a PHP short tag is "echo".
To avoid portability issues, start PHP tags with <?php and in case your PHP file is purely PHP, no HTML, you don't need to use the closing tags.
Short tags are acceptable to use in cases where you are certain the server will support it and that your developers will understand it.
Many servers do not support it, and many developers will understand it after seeing it once.
I use full tags to ensure portability, since it's really not that bad.
With that said, a friend of mine said this, in support of alternate standardized asp-style tags, like <% rather than <?, which is a setting in php.ini called asp_tags. Here is his reasoning:
... arbitrary conventions should be
standardized. That is, any time we are
faced with a set of possibilities that
are all of equal value - such as what
weird punctuation our programming
language should use to demarcate
itself - we should pick one standard
way and stick with it. That way we
reduce the learning curve of all
languages (or whatever the things the
convention pertains to).
Sounds good to me, but I don't think any of us can circle the wagons around this cause. In the meantime, I would stick to the full <?php.
Let's face it. PHP is ugly as hell without short tags.
You can enable them in a .htaccess file if you can't get to the php.ini:
php_flag short_open_tag on
If you care about XSS then you should use <?= htmlspecialchars(…) ?> most of the time, so a short tag doesn't make a big difference.
Even if you shorten echo htmlspecialchars() to h(), it's still a problem that you have to remember to add it almost every time (and trying to keep track which data is pre-escaped, which is unescaped-but-harmless only makes mistakes more likely).
I use a templating engine that is secure by default and writes <?php tags for me.
Short tag are alwayes available in php.
So you do not need echo the first statement in your script
example:
$a =10;
<?= $a;//10
echo "Hellow";//
echo "Hellow";
?>
Suddenly you need to use for a single php script then u can
use it.
example:
<html>
<head>
<title></title>
</head>
<body>
<p>hellow everybody<?= hi;?></p>
<p>hellow everybody </p>
<p>hellow everybody </p>
</body>
</html>
3 tags are available in php:
long-form tag that <?php ?> no need to directive any configured
short_open_tag that <? ?> available if short_open_tag option in
php.ini is on
shorten tag <?= since php 5.4.0 it is always available
from php 7.0.0 asp and script tag are removed
<?php ?> are much better to use since developers of this programming language has massively updated their core-language. You can see the difference between the short tags and long tags.
Short tags will be highlighted as light red while the longer ones are highlighted darker!
However, echoing something out, for example: <?=$variable;?> is fine. But prefer the longer tags. <?php echo $variable;?>
Convert <? (without a trailing space) to <?php (with a trailing space):
find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\?(?!php|=|xml|mso| )/<\?php /g'
Convert <? (with a trailing space) to <?php (retaining the trailing space):
find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\? /<\?php /g'
No, and they're being phased out by PHP 6 so if you appreciate code longevity, simply don't use them or the <% ... %> tags.

PHP 5.5 short_open_tag=on Security Hole?

I've upgraded to PHP5.5 and in the PHP.ini now short_open_tag=off and I recognized this because some files are now not running because <? instead of <?php.
Now there are two solutions scouting for any php file and change the open tag to <?php or activate short_open_tag=on
Is there any security problem with the second option?
Not a direct security vulnerability but it could become one given the proper conditions.
First off let's specs standards. In PHP 5.4 and higher the short_open_tag=on directive applies to all short tags except <?= - the echo tag.
Generally it is considered that using short tags all over your code is a bad practice because of portability. I personally do now use short tags.
Since PHP 5.4 and >= 5.4 the short echo tag <?= is always available and not affected by the short_open_tag ini directive. I consider this decision to separate the echo tag from the others a good one.
Actually the PSR Standards suggest this. So:
PSR-1 suggests to only use <?php ?> or <?= ?> (echo short tag) - and no other variations, and PSR-2 suggests to not close the tags in PHP-only files. This may seem strange but sometimes there could be untraceable errors in your code because of a single space (' ') character just before your opening or just after your closing bracket. This is a well known issue. I adhere to both practices as I have seen it all go very wrong because of different tags usage in old projects.
Where did this all begin?
Back in the early days of PHP people started realizing that the PHP tags conflict with those of XML and ASP. Yes you can use <% //code here %> as a open/close tag.
Then it was decided that PHP would use <?php ?> as to distinguish itself from XML and ASP - kind of a top-level namespace for PHP code.
Actually the ASP tags were introduced as a comfortable way to ease adoption of PHP by ASP developers.
ASP tags are handled by the asp_tags ini directive and they should be off.
Again - the debate for the short tags was held and that is why now there is a separation between short tags and the short echo tag. I consider this a good thing. Just replace all short tags in your legacy code.
Now about security.
The only case you should worry about is when you have some user input that somehow ends up going through the PHP interpreter. You will need to strip:
Normal PHP tags
Short PHP tags
Short Echo tags
ASP style tags
Byte-shifted code injection
Anything that has <script language="php"></script>
This last portion - <script language="php"></script> - is very important since it is not being used today (and we're better off without it) but as far as I remember it is still supported by the PHP interpreter. So anything between that HTML script tag will be interpreted as PHP. All this is very well explained here.
What the hell is Byte-shifted code injection?
It's kinda hard to explain but the basic idea is it is obfuscated code injection. So if an attacker somehow is able to inject some PHP code and he/she does not want the maintainer/developer to immediately identify it he could do something like the folowing:
$smth = 'rpub "lbh ner nggnpxrq naq lbhe jrofvgr unf orra gnxra bire";';
eval(str_rot13($smth));
The idea is that the "blob of a sting" is a php code string but byte shifted so it is obfuscated. In my example the eval() will receive
echo "you are attacked and your website has been taken over".
I am using str_rot13() as it is easy to obfuscate a string back and forward, but this could be a custom function based on chr() or ord() or any other string manipulation functions.
The best way to prevent such an attack is to prevent eval() execution. You should be able to do this through the disable_functions ini directive. Parse your code of course! But also disable eval().
This type of attack can be really hard to notice with systems like Wordpress, which store a lot of stuff in the DB, most of them unnecessarily. I've personally seen such code injection done to websites (not those I maintained :D) in one of two ways:
DB corruption (Possible when the application stores something that gets interpreted)
Direct PHP source file corruption - This is much easier to analyze - just diff it against the latest version in a repository or compare it to some source backUp (again via diff).
Hope this helped.
So please start adhering to the PSR Standards.
Do not use short tags except for the echo tag <?=
Disable ASP-style tags
Watch out for code injections.

Object creation in php [duplicate]

Here's the information according to the official documentation:
There are four different pairs of
opening and closing tags which can be
used in PHP. Two of those, <?php ?>
and <script language="php"> </script>,
are always available. The other two
are short tags and ASP style tags, and
can be turned on and off from the
php.ini configuration file. As such,
while some people find short tags and
ASP style tags convenient, they are
less portable, and generally not
recommended.
In my experience most servers do have short tags enabled. Typing
<?=
is far more convenient than typing
<?php echo
The programmers convenience is an important factor, so why are they not recommended?
There must be a clear distinction between the PHP short tag (<?) and shorthand echo tag (<?=)
The former is prohibited by the PHP Coding standard, mostly out of common sense because it's a PITA if you ever have to move your code to a server where it's not supported (and you can't enable it). As you say, lots of shared hosts do support shorttags but "lots" isn't all of them. If you want to share your scripts, it's best to use the full syntax.
Whereas the shorthand echo tag <?= cannot be disabled and therefore is fully acceptable to use.
I agree that <? is easier on programmers than <?php but it is possible to do a bulk find-and-replace as long as you use the same form each time.
I don't buy readability as a reason at all. Most serious developers have the option of syntax highlighting available to them.
As ThiefMaster mentions in the comments, as of PHP 5.4, <?= ... ?> tags are supported everywhere, regardless of shorttags settings. This should mean they're safe to use in portable code but that does mean there's then a dependency on PHP 5.4+. If you want to support pre-5.4 and can't guarantee shorttags, you'll still need to use <?php echo ... ?>.
Also, you need to know that ASP tags <% , %> , <%= , and script tag are removed from PHP 7. So if you would like to support long-term portable code and would like switching to the most modern tools consider changing that parts of code.
I'm too fond of <?=$whatever?> to let it go. Never had a problem with it. I'll wait until it bites me in the ass. In all seriousness, 85% of (my) clients have access to php.ini in the rare occasion they are turned off. The other 15% use mainstream hosting providers, and virtually all of them have them enabled. I love 'em.
Starting with PHP 5.4, the echo shortcut is a separate issue from short tags, as the echo shortcut will always be enabled. It's a fact now:
SVN Revision by Rasmus Lerdorf
Mailing list discussion
So the echo shortcut itself (<?=) is safe to use now.
The problem with this whole discussion lies in the use of PHP as a templating language. No one is arguing that tags should be used in application source files.
However PHP's embeddable syntax allows it to be used as a powerful template language, and templates should be as simple and readable as possible. Many have found it easier to use a much slower, add-on templating engine like Smarty, but for those purists among us who demand fast rendering and a pure code base, PHP is the only way to write templates.
The ONLY valid argument AGAINST the use of short tags is that they aren't supported on all servers. Comments about conflicts with XML documents are ludicrous, because you probably shouldn't be mixing PHP and XML anyway; and if you are, you should be using PHP to output strings of text. Security should never be an issue, because if you're putting sensitive information like database access credentials inside of template files, well then, you've got bigger issues!
Now then, as to the issue of server support, admittedly one has to be aware of their target platform. If shared hosting is a likely target, then short tags should be avoided. But for many professional developers (such as myself), the client acknowledges (and indeed, depends on the fact) that we will be dictating the server requirements. Often I'm responsible for setting up the server myself.
And we NEVER work with a hosting provider that does not give us absolute control of the server configuration -- in such a case we could count on running to much more trouble than just losing short tag support. It just doesn't happen.
So yes -- I agree that the use of short tags should be carefully weighed. But I also firmly believe that it should ALWAYS be an option, and that a developer who is aware of his environment should feel free to use them.
Short tags are coming back thanks to Zend Framework pushing the "PHP as a template language" in their default MVC configuration. I don't see what the debate is about, most of the software you will produce during your lifetime will operate on a server you or your company will control. As long as you keep yourself consistent, there shouldn't be any problems.
UPDATE
After doing quite a bit of work with Magento, which uses long form. As a result, I've switched to the long form of:
<?php and <?php echo
over
<? and <?=
Seems like a small amount of work to assure interoperability.
Because the confusion it can generate with XML declarations. Many people agree with you, though.
An additional concern is the pain it'd generate to code everything with short tags only to find out at the end that the final hosting server has them turned off...
Following is the wonderful flow diagram of the same:
Source: similiar question on Software Engineering Stack Exchange
In case anyone's still paying attention to this... As of PHP 5.4.0 Alpha 1 <?= is always available:
http://php.net/releases/NEWS_5_4_0_alpha1.txt
So it looks like short tags are (a) acceptable and (b) here to stay. For now at least...
http://uk3.php.net/manual/en/language.basic-syntax.phpmode.php has plenty of advice, including:
while some people find short tags and
ASP style tags convenient, they are
less portable, and generally not
recommended.
and
note that if you are embedding PHP
within XML or XHTML you will need to
use the <?php ?> tags to remain
compliant with standards.
and
Using short tags should be avoided
when developing applications or
libraries that are meant for
redistribution, or deployment on PHP
servers which are not under your
control, because short tags may not be
supported on the target server. For
portable, redistributable code, be
sure not to use short tags.
Short tags are not turned on by default in some webservers (shared hosts, etc.), so code portability becomes an issue if you need to move to one of these.
Readability may be an issue for some. Many developers may find that <?php catches the eye as a more obvious marker of the beginning of a code block than <? when you scan a file, particularly if you're stuck with a code base with HTML and PHP tightly inter-woven.
Note: Starting in PHP 5.4 the short tag, <?=, is now always available.
I read this page after looking for information on the topic, and I feel that one major issue has not been mentioned: laziness vs. consistency. The "real" tags for PHP are <?php and ?>. Why? I don't really care. Why would you want to use something else when those are clearly for PHP? <% and %> mean ASP to me, and <script ..... means Javascript (in most cases). So for consistency, fast learning, portability, and simplicity, why not stick to the standard?
On the other hand I agree that short tags in templates (and ONLY in templates) seem useful, but the problem is that we've just spent so much time discussing it here, that it would likely take a very long time to have actually wasted that much time typing the extra three characters of "php"!!
While having many options is nice, it's not at all logical and it can cause problems. Imagine if every programming language allowed 4 or more types of tags: Javascript could be <JS or < script .... or <% or <? JS.... would that be helpful? In the case of PHP the parsing order tends to be in favor of allowing these things, but the language is in many other ways not flexible: it throws notices or errors upon the slightest inconsistency, yet short tags are used often. And when short tags are used on a server that doesn't support them, it can take a very long time to figure out what is wrong since no error is given in some cases.
Finally, I don't think that short tags are the problem here: there are only two logical types of PHP code blocks-- 1) regular PHP code, 2) template echoes.
For the former, I firmly believe that only <?php and ?> should be allowed just to keep everything consistent and portable.
For the latter, the <?=$var?> method is ugly. Why must it be like this? Why not add something much more logical?
<?php $var ?>
That would not do anything (and only in the most remote possibilities could it conflict with something), and that could easily replace the awkward <?= syntax. Or if that's a problem, perhaps they could use <?php=$var?> instead and not worry about inconsistencies.
At the point where there are 4 options for open and close tags and the random addition of a special "echo" tag, PHP may as well have a "custom open/close tags" flag in php.ini or .htaccess. That way designers can choose the one they like best. But for obvious reasons that's overkill. So why allow 4+ options?
As of 2019 I disagree with certain answers here. Recommended to use:
1. Long tags
<?php /* code goes here */ ?>
2. Short echo tags
<?= /* code goes here */ ?>
Reason: They are recommended by the PSR-1 basic coding standard
Other short tags like <? /* code goes here */ ?> are not recommended.
The spec says:
PHP code MUST use the long tags or the short-echo
tags; it MUST NOT use the other tag variations.
One situation that is a little different is when developing a CodeIgniter application. CodeIgniter seems to use the shorttags whenever PHP is being used in a template/view, otherwise with models and controllers it always uses the long tags. It's not a hard and fast rule in the framework, but for the most part the framework and a lot of the source from other uses follows this convention.
My two cents? If you never plan on running the code somewhere else, then use them if you want. I'd rather not have to do a massive search and replace when I realize it was a dumb idea.
<? is disabled by default in newer versions. You can enable this like described Enabling Short Tags in PHP.
I thought it worth mentioning that as of PHP 7:
Short ASP PHP tags <% … %> are gone
Short PHP tabs <? … ?> are still available if short_open_tag is set to true. This is the default.
Since PHP 5.4, Short Print tags <?=… ?> are always enabled, regardless of the short_open_tag setting.
Good riddance to the first one, as it interfered with other languages.
There is now no reason not to use the short print tags, apart from personal preference.
Of course, if you’re writing code to be compatible with legacy versions of PHP 5, you will need to stick to the old rules, but remember that anything before PHP 5.6 is now unsupported.
See: https://secure.php.net/manual/en/language.basic-syntax.phptags.php
Note also the the above reference discourages the second version (<? … ?>) since it may have been disabled:
Note:
As short tags can be disabled it is recommended to only use the normal tags (<?php ?> and <?= ?>) to maximise compatibility.
IMHO people who use short tags often forget to escape whatever they're echoing. It would be nice to have a template engine that escapes by default. I believe Rob A wrote a quick hack to escape short tags in Zend Frameworks apps. If you like short tags because it makes PHP easier to read. Then might Smarty be a better option?
{$myString|escape}
to me that looks better than
<?= htmlspecialchars($myString) ?>
It's good to use them when you work with a MVC framework or CMS that have separate view files. It's fast, less code, not confusing for the designers. Just make sure your server configuration allows using them.
One has to ask what the point of using short tags is.
Quicker to type
MDCore said:
<?= is far more convenient than typing <?php echo
Yes, it is. You save having to type 7 characters * X times throughout your scripts.
However, when a script takes an hour, or 10 hours, or more, to design, develop, and write, how relevant is the few seconds of time not typing those 7 chars here and there for the duration of the script?
Compared to the potential for some core, or all, of you scripts not working if short tags are not turned on, or are on but an update or someone changing the ini file/server config stops them working, other potentials.
The small benefit you gain doesn't comes close to outweighing the severity of the potential problems, that is your site not working, or worse, only parts of it not working and thus a headache to resolve.
Easier to read
This depends on familiarity.
I've always seen and used <?php echo. So while <?= is not hard to read, it's not familiar to me and thus not easier to read.
And with front end/back end developer split (as with most companies) would a front end developer working on those templates be more familiar knowing <?= is equal to "PHP open tag and echo"?
I would say most would be more comfortable with the more logical one. That is, a clear PHP open tag and then what is happening "echo" - <?php echo.
Risk assessment
Issue = entire site or core scripts fail to work;
The potential of issue is very low + severity of outcome is very high = high risk
Conclusion
You save a few seconds here and there not having to type a few chars, but risk a lot for it, and also likely lose readability as a result.
Front or back end coders familiar with <?= are more likely to understand <?php echo, as they're standard PHP things - standard <?php open tag and very well known "echo".
(Even front end coders should know "echo" or they simply wont be working on any code served by a framework).
Whereas the reverse is not as likely, someone is not likely to logically deduce that the equals sign on a PHP short tag is "echo".
To avoid portability issues, start PHP tags with <?php and in case your PHP file is purely PHP, no HTML, you don't need to use the closing tags.
Short tags are acceptable to use in cases where you are certain the server will support it and that your developers will understand it.
Many servers do not support it, and many developers will understand it after seeing it once.
I use full tags to ensure portability, since it's really not that bad.
With that said, a friend of mine said this, in support of alternate standardized asp-style tags, like <% rather than <?, which is a setting in php.ini called asp_tags. Here is his reasoning:
... arbitrary conventions should be
standardized. That is, any time we are
faced with a set of possibilities that
are all of equal value - such as what
weird punctuation our programming
language should use to demarcate
itself - we should pick one standard
way and stick with it. That way we
reduce the learning curve of all
languages (or whatever the things the
convention pertains to).
Sounds good to me, but I don't think any of us can circle the wagons around this cause. In the meantime, I would stick to the full <?php.
Let's face it. PHP is ugly as hell without short tags.
You can enable them in a .htaccess file if you can't get to the php.ini:
php_flag short_open_tag on
If you care about XSS then you should use <?= htmlspecialchars(…) ?> most of the time, so a short tag doesn't make a big difference.
Even if you shorten echo htmlspecialchars() to h(), it's still a problem that you have to remember to add it almost every time (and trying to keep track which data is pre-escaped, which is unescaped-but-harmless only makes mistakes more likely).
I use a templating engine that is secure by default and writes <?php tags for me.
Short tag are alwayes available in php.
So you do not need echo the first statement in your script
example:
$a =10;
<?= $a;//10
echo "Hellow";//
echo "Hellow";
?>
Suddenly you need to use for a single php script then u can
use it.
example:
<html>
<head>
<title></title>
</head>
<body>
<p>hellow everybody<?= hi;?></p>
<p>hellow everybody </p>
<p>hellow everybody </p>
</body>
</html>
3 tags are available in php:
long-form tag that <?php ?> no need to directive any configured
short_open_tag that <? ?> available if short_open_tag option in
php.ini is on
shorten tag <?= since php 5.4.0 it is always available
from php 7.0.0 asp and script tag are removed
<?php ?> are much better to use since developers of this programming language has massively updated their core-language. You can see the difference between the short tags and long tags.
Short tags will be highlighted as light red while the longer ones are highlighted darker!
However, echoing something out, for example: <?=$variable;?> is fine. But prefer the longer tags. <?php echo $variable;?>
Convert <? (without a trailing space) to <?php (with a trailing space):
find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\?(?!php|=|xml|mso| )/<\?php /g'
Convert <? (with a trailing space) to <?php (retaining the trailing space):
find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\? /<\?php /g'
No, and they're being phased out by PHP 6 so if you appreciate code longevity, simply don't use them or the <% ... %> tags.

Is it possible to prevent standard HTML comments from showing up in source code?

I'm going to assume the answer is 'no' here, but since I haven't actually found that answer, I'm asking.
Quite basically, all I want to do is leave some HTML commenting in my files for 'author eyes only', simply to make editing the file later a much more pleasant experience.
<!-- Doing it like this --> leaves nice clean comments but they show up when viewing the page source after output.
I am using PHP, so technically I could <?PHP /* wrap comments in PHP tags */ ?> which would prevent them from being output at all, but if possible I'd like to avoid all of the extra arbitrary PHP tagging that would be needed for commenting throughout the file. After all, the point of commenting is to make the document feel less cluttered and more organized.
Is there anything else I could try or are these my best options?
No, anything in html will show up.
You could, have a script that parses the code, and removes the comments, before it puts it up on the server, and then you would have the original, and the uncommented source.
A tool to accomplish this:
http://code.google.com/p/htmlcompressor/
I guess these are your best options, yes, unless you run the entire HTML output through some sort of cleanup module before being sent to the client.
Anything not wrapped in server side syntax will will be output to the client if not modified on its way out (through template engines, for example). This goes for most (probably all) server side languages).
You could definitely write a parser that uses regex to strip out HTML comments, but unless you're already dealing with a roll-your-own CMS, most likely the work involved in this far outweighs the benefits of not using PHP comments as you suggested.

Are PHP short tags acceptable to use?

Here's the information according to the official documentation:
There are four different pairs of
opening and closing tags which can be
used in PHP. Two of those, <?php ?>
and <script language="php"> </script>,
are always available. The other two
are short tags and ASP style tags, and
can be turned on and off from the
php.ini configuration file. As such,
while some people find short tags and
ASP style tags convenient, they are
less portable, and generally not
recommended.
In my experience most servers do have short tags enabled. Typing
<?=
is far more convenient than typing
<?php echo
The programmers convenience is an important factor, so why are they not recommended?
There must be a clear distinction between the PHP short tag (<?) and shorthand echo tag (<?=)
The former is prohibited by the PHP Coding standard, mostly out of common sense because it's a PITA if you ever have to move your code to a server where it's not supported (and you can't enable it). As you say, lots of shared hosts do support shorttags but "lots" isn't all of them. If you want to share your scripts, it's best to use the full syntax.
Whereas the shorthand echo tag <?= cannot be disabled and therefore is fully acceptable to use.
I agree that <? is easier on programmers than <?php but it is possible to do a bulk find-and-replace as long as you use the same form each time.
I don't buy readability as a reason at all. Most serious developers have the option of syntax highlighting available to them.
As ThiefMaster mentions in the comments, as of PHP 5.4, <?= ... ?> tags are supported everywhere, regardless of shorttags settings. This should mean they're safe to use in portable code but that does mean there's then a dependency on PHP 5.4+. If you want to support pre-5.4 and can't guarantee shorttags, you'll still need to use <?php echo ... ?>.
Also, you need to know that ASP tags <% , %> , <%= , and script tag are removed from PHP 7. So if you would like to support long-term portable code and would like switching to the most modern tools consider changing that parts of code.
I'm too fond of <?=$whatever?> to let it go. Never had a problem with it. I'll wait until it bites me in the ass. In all seriousness, 85% of (my) clients have access to php.ini in the rare occasion they are turned off. The other 15% use mainstream hosting providers, and virtually all of them have them enabled. I love 'em.
Starting with PHP 5.4, the echo shortcut is a separate issue from short tags, as the echo shortcut will always be enabled. It's a fact now:
SVN Revision by Rasmus Lerdorf
Mailing list discussion
So the echo shortcut itself (<?=) is safe to use now.
The problem with this whole discussion lies in the use of PHP as a templating language. No one is arguing that tags should be used in application source files.
However PHP's embeddable syntax allows it to be used as a powerful template language, and templates should be as simple and readable as possible. Many have found it easier to use a much slower, add-on templating engine like Smarty, but for those purists among us who demand fast rendering and a pure code base, PHP is the only way to write templates.
The ONLY valid argument AGAINST the use of short tags is that they aren't supported on all servers. Comments about conflicts with XML documents are ludicrous, because you probably shouldn't be mixing PHP and XML anyway; and if you are, you should be using PHP to output strings of text. Security should never be an issue, because if you're putting sensitive information like database access credentials inside of template files, well then, you've got bigger issues!
Now then, as to the issue of server support, admittedly one has to be aware of their target platform. If shared hosting is a likely target, then short tags should be avoided. But for many professional developers (such as myself), the client acknowledges (and indeed, depends on the fact) that we will be dictating the server requirements. Often I'm responsible for setting up the server myself.
And we NEVER work with a hosting provider that does not give us absolute control of the server configuration -- in such a case we could count on running to much more trouble than just losing short tag support. It just doesn't happen.
So yes -- I agree that the use of short tags should be carefully weighed. But I also firmly believe that it should ALWAYS be an option, and that a developer who is aware of his environment should feel free to use them.
Short tags are coming back thanks to Zend Framework pushing the "PHP as a template language" in their default MVC configuration. I don't see what the debate is about, most of the software you will produce during your lifetime will operate on a server you or your company will control. As long as you keep yourself consistent, there shouldn't be any problems.
UPDATE
After doing quite a bit of work with Magento, which uses long form. As a result, I've switched to the long form of:
<?php and <?php echo
over
<? and <?=
Seems like a small amount of work to assure interoperability.
Because the confusion it can generate with XML declarations. Many people agree with you, though.
An additional concern is the pain it'd generate to code everything with short tags only to find out at the end that the final hosting server has them turned off...
Following is the wonderful flow diagram of the same:
Source: similiar question on Software Engineering Stack Exchange
In case anyone's still paying attention to this... As of PHP 5.4.0 Alpha 1 <?= is always available:
http://php.net/releases/NEWS_5_4_0_alpha1.txt
So it looks like short tags are (a) acceptable and (b) here to stay. For now at least...
http://uk3.php.net/manual/en/language.basic-syntax.phpmode.php has plenty of advice, including:
while some people find short tags and
ASP style tags convenient, they are
less portable, and generally not
recommended.
and
note that if you are embedding PHP
within XML or XHTML you will need to
use the <?php ?> tags to remain
compliant with standards.
and
Using short tags should be avoided
when developing applications or
libraries that are meant for
redistribution, or deployment on PHP
servers which are not under your
control, because short tags may not be
supported on the target server. For
portable, redistributable code, be
sure not to use short tags.
Short tags are not turned on by default in some webservers (shared hosts, etc.), so code portability becomes an issue if you need to move to one of these.
Readability may be an issue for some. Many developers may find that <?php catches the eye as a more obvious marker of the beginning of a code block than <? when you scan a file, particularly if you're stuck with a code base with HTML and PHP tightly inter-woven.
Note: Starting in PHP 5.4 the short tag, <?=, is now always available.
I read this page after looking for information on the topic, and I feel that one major issue has not been mentioned: laziness vs. consistency. The "real" tags for PHP are <?php and ?>. Why? I don't really care. Why would you want to use something else when those are clearly for PHP? <% and %> mean ASP to me, and <script ..... means Javascript (in most cases). So for consistency, fast learning, portability, and simplicity, why not stick to the standard?
On the other hand I agree that short tags in templates (and ONLY in templates) seem useful, but the problem is that we've just spent so much time discussing it here, that it would likely take a very long time to have actually wasted that much time typing the extra three characters of "php"!!
While having many options is nice, it's not at all logical and it can cause problems. Imagine if every programming language allowed 4 or more types of tags: Javascript could be <JS or < script .... or <% or <? JS.... would that be helpful? In the case of PHP the parsing order tends to be in favor of allowing these things, but the language is in many other ways not flexible: it throws notices or errors upon the slightest inconsistency, yet short tags are used often. And when short tags are used on a server that doesn't support them, it can take a very long time to figure out what is wrong since no error is given in some cases.
Finally, I don't think that short tags are the problem here: there are only two logical types of PHP code blocks-- 1) regular PHP code, 2) template echoes.
For the former, I firmly believe that only <?php and ?> should be allowed just to keep everything consistent and portable.
For the latter, the <?=$var?> method is ugly. Why must it be like this? Why not add something much more logical?
<?php $var ?>
That would not do anything (and only in the most remote possibilities could it conflict with something), and that could easily replace the awkward <?= syntax. Or if that's a problem, perhaps they could use <?php=$var?> instead and not worry about inconsistencies.
At the point where there are 4 options for open and close tags and the random addition of a special "echo" tag, PHP may as well have a "custom open/close tags" flag in php.ini or .htaccess. That way designers can choose the one they like best. But for obvious reasons that's overkill. So why allow 4+ options?
As of 2019 I disagree with certain answers here. Recommended to use:
1. Long tags
<?php /* code goes here */ ?>
2. Short echo tags
<?= /* code goes here */ ?>
Reason: They are recommended by the PSR-1 basic coding standard
Other short tags like <? /* code goes here */ ?> are not recommended.
The spec says:
PHP code MUST use the long tags or the short-echo
tags; it MUST NOT use the other tag variations.
One situation that is a little different is when developing a CodeIgniter application. CodeIgniter seems to use the shorttags whenever PHP is being used in a template/view, otherwise with models and controllers it always uses the long tags. It's not a hard and fast rule in the framework, but for the most part the framework and a lot of the source from other uses follows this convention.
My two cents? If you never plan on running the code somewhere else, then use them if you want. I'd rather not have to do a massive search and replace when I realize it was a dumb idea.
<? is disabled by default in newer versions. You can enable this like described Enabling Short Tags in PHP.
I thought it worth mentioning that as of PHP 7:
Short ASP PHP tags <% … %> are gone
Short PHP tabs <? … ?> are still available if short_open_tag is set to true. This is the default.
Since PHP 5.4, Short Print tags <?=… ?> are always enabled, regardless of the short_open_tag setting.
Good riddance to the first one, as it interfered with other languages.
There is now no reason not to use the short print tags, apart from personal preference.
Of course, if you’re writing code to be compatible with legacy versions of PHP 5, you will need to stick to the old rules, but remember that anything before PHP 5.6 is now unsupported.
See: https://secure.php.net/manual/en/language.basic-syntax.phptags.php
Note also the the above reference discourages the second version (<? … ?>) since it may have been disabled:
Note:
As short tags can be disabled it is recommended to only use the normal tags (<?php ?> and <?= ?>) to maximise compatibility.
IMHO people who use short tags often forget to escape whatever they're echoing. It would be nice to have a template engine that escapes by default. I believe Rob A wrote a quick hack to escape short tags in Zend Frameworks apps. If you like short tags because it makes PHP easier to read. Then might Smarty be a better option?
{$myString|escape}
to me that looks better than
<?= htmlspecialchars($myString) ?>
It's good to use them when you work with a MVC framework or CMS that have separate view files. It's fast, less code, not confusing for the designers. Just make sure your server configuration allows using them.
One has to ask what the point of using short tags is.
Quicker to type
MDCore said:
<?= is far more convenient than typing <?php echo
Yes, it is. You save having to type 7 characters * X times throughout your scripts.
However, when a script takes an hour, or 10 hours, or more, to design, develop, and write, how relevant is the few seconds of time not typing those 7 chars here and there for the duration of the script?
Compared to the potential for some core, or all, of you scripts not working if short tags are not turned on, or are on but an update or someone changing the ini file/server config stops them working, other potentials.
The small benefit you gain doesn't comes close to outweighing the severity of the potential problems, that is your site not working, or worse, only parts of it not working and thus a headache to resolve.
Easier to read
This depends on familiarity.
I've always seen and used <?php echo. So while <?= is not hard to read, it's not familiar to me and thus not easier to read.
And with front end/back end developer split (as with most companies) would a front end developer working on those templates be more familiar knowing <?= is equal to "PHP open tag and echo"?
I would say most would be more comfortable with the more logical one. That is, a clear PHP open tag and then what is happening "echo" - <?php echo.
Risk assessment
Issue = entire site or core scripts fail to work;
The potential of issue is very low + severity of outcome is very high = high risk
Conclusion
You save a few seconds here and there not having to type a few chars, but risk a lot for it, and also likely lose readability as a result.
Front or back end coders familiar with <?= are more likely to understand <?php echo, as they're standard PHP things - standard <?php open tag and very well known "echo".
(Even front end coders should know "echo" or they simply wont be working on any code served by a framework).
Whereas the reverse is not as likely, someone is not likely to logically deduce that the equals sign on a PHP short tag is "echo".
To avoid portability issues, start PHP tags with <?php and in case your PHP file is purely PHP, no HTML, you don't need to use the closing tags.
Short tags are acceptable to use in cases where you are certain the server will support it and that your developers will understand it.
Many servers do not support it, and many developers will understand it after seeing it once.
I use full tags to ensure portability, since it's really not that bad.
With that said, a friend of mine said this, in support of alternate standardized asp-style tags, like <% rather than <?, which is a setting in php.ini called asp_tags. Here is his reasoning:
... arbitrary conventions should be
standardized. That is, any time we are
faced with a set of possibilities that
are all of equal value - such as what
weird punctuation our programming
language should use to demarcate
itself - we should pick one standard
way and stick with it. That way we
reduce the learning curve of all
languages (or whatever the things the
convention pertains to).
Sounds good to me, but I don't think any of us can circle the wagons around this cause. In the meantime, I would stick to the full <?php.
Let's face it. PHP is ugly as hell without short tags.
You can enable them in a .htaccess file if you can't get to the php.ini:
php_flag short_open_tag on
If you care about XSS then you should use <?= htmlspecialchars(…) ?> most of the time, so a short tag doesn't make a big difference.
Even if you shorten echo htmlspecialchars() to h(), it's still a problem that you have to remember to add it almost every time (and trying to keep track which data is pre-escaped, which is unescaped-but-harmless only makes mistakes more likely).
I use a templating engine that is secure by default and writes <?php tags for me.
Short tag are alwayes available in php.
So you do not need echo the first statement in your script
example:
$a =10;
<?= $a;//10
echo "Hellow";//
echo "Hellow";
?>
Suddenly you need to use for a single php script then u can
use it.
example:
<html>
<head>
<title></title>
</head>
<body>
<p>hellow everybody<?= hi;?></p>
<p>hellow everybody </p>
<p>hellow everybody </p>
</body>
</html>
3 tags are available in php:
long-form tag that <?php ?> no need to directive any configured
short_open_tag that <? ?> available if short_open_tag option in
php.ini is on
shorten tag <?= since php 5.4.0 it is always available
from php 7.0.0 asp and script tag are removed
<?php ?> are much better to use since developers of this programming language has massively updated their core-language. You can see the difference between the short tags and long tags.
Short tags will be highlighted as light red while the longer ones are highlighted darker!
However, echoing something out, for example: <?=$variable;?> is fine. But prefer the longer tags. <?php echo $variable;?>
Convert <? (without a trailing space) to <?php (with a trailing space):
find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\?(?!php|=|xml|mso| )/<\?php /g'
Convert <? (with a trailing space) to <?php (retaining the trailing space):
find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\? /<\?php /g'
No, and they're being phased out by PHP 6 so if you appreciate code longevity, simply don't use them or the <% ... %> tags.

Categories