PHP RFC: Deprecate short open tags, again

• Date: 2019-07-23
• Author: George Peter Banyard girgias@php.net, Nikita Popov nikic@php.net
• Status: Declined
• Target version: PHP 7.4
• Implementation: https://github.com/php/php-src/pull/4263
• Counterargument: https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags

This RFC has been granted an exemption to land in PHP 7.4 after feature freeze by the release managers for PHP 7.4 Derick Rethans derick@php.net and Peter Kokot petk@php.net

In addition to <?php, PHP allows opening PHP scripts with just <? if the short_open_tag ini setting is enabled. This RFC proposes to deprecate and remove this configuration-dependent syntax.

The deprecation of short open tags was previously accepted as part of deprecate_php_short_tags. However, a substantial amount of discussion was generated only after the RFC has been accepted, and some concerns were raised over the implementation approach. This RFC supersedes the previous one and proposes a different deprecation approach.

Currently the <? short open tag is controlled by the short_open_tag ini setting. This ini setting is enabled by default (if no ini files is used), but disabled in both php.ini-development and php.ini-production.

If short_open_tag is enabled <? is interpreted as the start of a PHP context. If short_open_tag is disabled, <? is interpreted as literal text without special meaning.

The <?= combined opening and echo tag is not controlled by short_open_tag. It is always available, and will continue to be always available after this RFC.

There are two primary motivations for removing short open tags:

First, short_open_tag is an ini setting that control core language syntax. This means that their use is not possible in portable code, because the code author does not necessarily have the necessary control over the configuration of the deployment environment. Worse than that, code using short open tags deployed on a server using short_open_tag=0 will leak application code, because short open tags are silently ignored.

Nowadays the PHP project has a hard policy against ini settings that affect core language behavior. Short open tags are one of the final leftovers from the time before this policy was in place.

Second, short open tags are not compatible with XML declarations <?xml ... ?> and XML processing instructions <?pi ... ?>. This means that the use of XML in template files is also non-portable: If deployed in an environment with short_open_tag=1, it will cause a syntax error. (Technically a processing instruction could also coincide with valid PHP code and be executed as such, but this is unlikely.)

In PHP 7.4 short_open_tag remains enabled by default: Changing the default could result in code leaks during upgrades, if people rely on the default value rather than explicitly enabling them. Instead:

• If short_open_tag is enabled and <? is used, a single deprecation notice is emitted.
• If short_open_tag is enabled, but <? is never used, no deprecation notice is emitted (as before).
• If short_open_tag is disabled, <? has no special meaning and is interpreted as plain text (as before).

In PHP 8.0 the deprecation notice is converted into a parse error:

• If short_open_tag is enabled, the use of <? is a parse error.
• If short_open_tag is disabled, <? has no special meaning (as before).

In PHP 9.0 support for short_open_tag is dropped entirely:

• <? never has special meaning, it is always interpreted as plain text.

This deprecation and removal plan avoids unintentional code leaks during PHP version upgrades.

While a migration of a legacy codebase from short open tags to standard <?php tags may seem daunting, it can be reliably automated.

For example, the “full_opening_tag” fixer from PHP-CS Fixer can be used. Other coding style and compatibility fixers also provide this functionality.

Short open tags <? will be removed. <?= continues to always be available.

A counterargument for this deprecation proposal is available here. It is supported by Rasmus Lerdorf, Zeev Suraski, Dmitry Stogov, Sara Golemon.

Require a 2/3 majority as per the Voting RFC.

Voting started on 2019-08-06 at 11:30 UTC and is expected to last two (2) weeks until 2019-08-20

Deprecate and remove short open tags as proposed?
Real name	Yes	No
ab (ab)
ajf (ajf)
alcaeus (alcaeus)
andi (andi)
ashnazg (ashnazg)
beberlei (beberlei)
bishop (bishop)
brzuchal (brzuchal)
bwoebi (bwoebi)
carusogabriel (carusogabriel)
colinodell (colinodell)
cschneid (cschneid)
davey (davey)
derick (derick)
dmitry (dmitry)
duncan3dc (duncan3dc)
eliw (eliw)
emir (emir)
frozenfire (frozenfire)
galvao (galvao)
girgias (girgias)
jasny (jasny)
jhdxr (jhdxr)
kalle (kalle)
kaplan (kaplan)
kelunik (kelunik)
kguest (kguest)
kinncj (kinncj)
klaussilveira (klaussilveira)
krakjoe (krakjoe)
kriscraig (kriscraig)
laruence (laruence)
lcobucci (lcobucci)
mansion (mansion)
mcmic (mcmic)
mgocobachi (mgocobachi)
ocramius (ocramius)
ondrej (ondrej)
peehaa (peehaa)
petk (petk)
pollita (pollita)
ralphschindler (ralphschindler)
ramsey (ramsey)
rasmus (rasmus)
reywob (reywob)
salathe (salathe)
santiagolizardo (santiagolizardo)
scorninpc (scorninpc)
sergey (sergey)
stas (stas)
svpernova09 (svpernova09)
trowski (trowski)
wyrihaximus (wyrihaximus)
zeev (zeev)
Final result:	30	24
This poll has been closed.

Version 2 (this one) RFC Vote Announcement on Internals (link to External.io)
Counter arguments to this RFC
Version 2 (this one) RFC Announcement on Internals (link to External.io)
Version 1 of RFC Vote Announcement on Internals (link to External.io)
Version 1 of RFC Announcement on Internals (link to External.io)
Initial feedback on Internals (link to External.io)