[PHP-DEV] [RFC] Deprecate PHP's short open tags

  104922
March 25, 2019 13:02 george.banyard@gmail.com ("G. P. B.")
Hello internals,

I would like to start the discussion about the deprecation of PHP's short
open tags:
https://wiki.php.net/rfc/deprecate_php_short_tags

As this is my first RFC all feedback is welcome.
However, due to the nature of the RFC and it being self-contained, the
planned date to
beginning voting this RFC is after the mandatory two weeks discussion
period and would
start on Monday the 8th of April (2019-04-08) and be open for two weeks
until Monday the
22nd of April (2019-04-22).

Best regards

George P. Banyard
  104926
March 25, 2019 13:52 r@roze.lv ("Reinis Rozitis")
> I would like to start the discussion about the deprecation of PHP's short open > tags: > https://wiki.php.net/rfc/deprecate_php_short_tags
Hi, I did read the initial thread about this and now the RFC and it doesn't really state what is the reason of removing the short tags besides this one line: "PHP has provided over the years different ways to indicate the beginning of PHP code other than the standard " Is there a (noticeable) speed improvement or does it make the parser/engine more simple? Is it wrong to provide different ways to indicate the start of php code? Since the short 'https://w3techs.com/technologies/details/pl-php/all/all rr
  104928
March 25, 2019 14:05 chasepeeler@gmail.com (Chase Peeler)
On Mon, Mar 25, 2019 at 9:52 AM Reinis Rozitis <r@roze.lv> wrote:

> > I would like to start the discussion about the deprecation of PHP's > short open > > tags: > > https://wiki.php.net/rfc/deprecate_php_short_tags > > Hi, > I did read the initial thread about this and now the RFC and it doesn't > really state what is the reason of removing the short tags besides this one > line: > "PHP has provided over the years different ways to indicate the beginning > of PHP code other than the standard " > > Is there a (noticeable) speed improvement or does it make the > parser/engine more simple? Is it wrong to provide different ways to > indicate the start of php code? > Since the short ' > I'm still unclear on the advantages as well
> Also considering there is somewhat low adoption of new php versions [1] a > change which brakes a lot of legacy code might even further push back the > switch to modern/current versions (at least now even if the defaults > disable the short tags, there is an option to reenable the functionality). > Obviously you could say that those using old versions won't be affected > anyways and those using php 7.x and waiting for 8.x will use recent > application code and also won't notice this deprecation, but in my opinion > (and praxes) it isn't always the case. > > Our application (an internal webapp) has a large amount of legacy code that we try to avoid messing with because we are actively rebuilding
everything. Everytime there is a BC break we have to go back into that legacy code. So, while any active development of our application uses "recent application code" that is that difficult to maintain, we still have a lot of spaghetti code that we rarely have to deal with except when it comes time to upgrade PHP. This often leads to the upgrades getting pushed out further and further. I'm not against BC breaks. They are a necessary evil to make PHP a better language. However, I think there should be a clear reason why the advantages outweigh the disadvantages. I'm not seeing that in this case.
> [1] https://w3techs.com/technologies/details/pl-php/all/all > > rr > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Chase Peeler chasepeeler@gmail.com
  104945
March 25, 2019 18:02 george.banyard@gmail.com ("G. P. B.")
Seems like the discussion is split between this thread and the previous one..
This is maybe due to me not linking the RFC announcement email in the RFC
immediately and I apologize for this inconvenience.
I will try to answer to most things within the announcement thread. If I
missed someone could they please notify me.

On Mon, 25 Mar 2019 at 14:52, Reinis Rozitis <r@roze.lv> wrote:

> Hi, > I did read the initial thread about this and now the RFC and it doesn't > really state what is the reason of removing the short tags besides this one > line: > "PHP has provided over the years different ways to indicate the beginning > of PHP code other than the standard " > > Is there a (noticeable) speed improvement or does it make the > parser/engine more simple? Is it wrong to provide different ways to > indicate the start of php code? > Since the short '
You could argue that '> Also considering there is somewhat low adoption of new php versions [1] a > change which brakes a lot of legacy code might even further push back the > switch to modern/current versions (at least now even if the defaults > disable the short tags, there is an option to reenable the functionality).. > Obviously you could say that those using old versions won't be affected > anyways and those using php 7.x and waiting for 8.x will use recent > application code and also won't notice this deprecation, but in my opinion > (and praxes) it isn't always the case. > > [1] https://w3techs.com/technologies/details/pl-php/all/all > > rr >
Just as a reminder exposing PHP's version can be disabled with the "expose_php" INI setting. Maybe this is just me idealising stuff but as there is automatics tooling (as pointed out by Côme Chilliet) I would suppose that upgrading from PHP 7 to PHP 8 wouldn't be harder if PHP's short open tags get removed. On Mon, 25 Mar 2019 at 16:38, Andrey Andreev <narf@devilix.net> wrote:
> OK, so why not flip it and make it always available instead? I'm aware > of the potential XML conflict, but I've personally never seen it, so > to me that looks like the lesser evil compared to a massive BC break. > > Cheers, > Andrey.
Technically this is already the case, the default in the engine is to enable PHP's short open tags, however both INI config templates provided with PHP (php.ini-developement and php.ini-production) disable PHP's short open tags. So if PHP's short open tags are to be considered "full class" open tags this should be represented in the INI templates. But I won't be the one pushing for this change. On Mon, 25 Mar 2019 at 16:16, Johannes Schlüter <johannes@schlueters.de> wrote:
> On Mo, 2019-03-25 at 09:38 -0500, Sara Golemon wrote: > > > > As we stand now, code using short open tags works when those tags are > > enabled. As we'd stand in the future, that code would not work. > > That > > level of BC break requires a strong justification. > > The code would not simply "not work" but even potentially leak to the > client (as PHP would not treat it as code) which could leak credentials > or other sensitive information. >
I think this can be an interesting point to add to the RFC as why to deprecate the short open tags. I still think that long-term goal should be that language behavior
> doesn't depend on ini configuration. > > [...] > > johannes >
This is mostly my reasonning on why bringing this RFC to the table. On Mon, 25 Mar 2019 at 17:21, Rasmus Schultz <rasmus@mindplay.dk> wrote:
> For the record, we're a mid-size organization, building a modern product on > PHP 7 with a PSR-based stack. > > We've shunned template engines and rely heavily on short open tags and > alternative control-structures - mainly because we insist on static > analysis and IDE support, which we get by manually type-hinting a single > view-model variable $view at the beginning of each template. > > No other template engine gives us what we want in terms of static analysis, > type-checking or IDE support. > > The choice to rebuild a very large product in PHP vs e.g. Node, at the > time, was in part motivated by PHP's template features - which, while it > may look pretty verbose and ugly on the surface, has a huge advantage over > basically anything else, e.g. static analysis with various QA tools, > automated refactorings (rename etc.) in PHP Storm, and so on. > > The loss of this feature would be a substantial setback for our > organization - for which there is no really good replacement.
This is an interesting use case, however may I ask why using '
  104949
March 25, 2019 19:42 narf@devilix.net (Andrey Andreev)
Hi,

On Mon, Mar 25, 2019 at 8:02 PM G. P. B. banyard@gmail.com> wrote:
> > On Mon, 25 Mar 2019 at 16:38, Andrey Andreev <narf@devilix.net> wrote: >> >> OK, so why not flip it and make it always available instead? I'm aware >> of the potential XML conflict, but I've personally never seen it, so >> to me that looks like the lesser evil compared to a massive BC break. >> >> Cheers, >> Andrey. > > > Technically this is already the case, the default in the engine is to enable PHP's short open tags, however both INI config templates provided > with PHP (php.ini-developement and php.ini-production) disable PHP's short open tags. > So if PHP's short open tags are to be considered "full class" open tags this should be represented in the INI templates. But I won't be the > one pushing for this change. >
We're talking about removal of the INI setting ... Aside of saying you wouldn't be personally pushing for what I suggested, I don't get the point of what you wrote. Cheers, Andrey.
  105015
March 29, 2019 20:33 george.banyard@gmail.com ("G. P. B.")
On Mon, 25 Mar 2019 at 20:42, Andrey Andreev <narf@devilix.net> wrote:

> Hi, > > On Mon, Mar 25, 2019 at 8:02 PM G. P. B. banyard@gmail.com> wrote: > > > > On Mon, 25 Mar 2019 at 16:38, Andrey Andreev <narf@devilix.net> wrote: > >> > >> OK, so why not flip it and make it always available instead? I'm aware > >> of the potential XML conflict, but I've personally never seen it, so > >> to me that looks like the lesser evil compared to a massive BC break. > >> > >> Cheers, > >> Andrey. > > > > > > Technically this is already the case, the default in the engine is to > enable PHP's short open tags, however both INI config templates provided > > with PHP (php.ini-developement and php.ini-production) disable PHP's > short open tags. > > So if PHP's short open tags are to be considered "full class" open tags > this should be represented in the INI templates. But I won't be the > > one pushing for this change. > > > > We're talking about removal of the INI setting ... Aside of saying you > wouldn't be personally pushing for what I suggested, I don't get the > point of what you wrote. > > Cheers, > Andrey. >
The point of what I wrote was to clarify what is the default value in-engine of short open tags. Also updated the RFC with the fact that using PHP's short open tags may leaks source code if used when those aren't not enabled. Best regards George P. Banyard
  105161
April 9, 2019 08:43 george.banyard@gmail.com ("G. P. B.")
Hello Internals,

Slightly later than expected but I will put the RFC to voting tomorrow if
no other discussion arises.
Also did some slight improvement to the RFC by adding a link to
PHP-CS-FIXER which can automatically
convert PHP's short open tags to the standard one and also added a Feedback
section to include Peter's
Facebook poll.

Best regards

George P. Banyard
  104940
March 25, 2019 15:45 thruska@cubiclesoft.com (Thomas Hruska)
On 3/25/2019 6:02 AM, G. P. B. wrote:
> Hello internals, > > I would like to start the discussion about the deprecation of PHP's short > open tags: > https://wiki.php.net/rfc/deprecate_php_short_tags > > As this is my first RFC all feedback is welcome. > However, due to the nature of the RFC and it being self-contained, the > planned date to > beginning voting this RFC is after the mandatory two weeks discussion > period and would > start on Monday the 8th of April (2019-04-08) and be open for two weeks > until Monday the > 22nd of April (2019-04-22). > > Best regards > > George P. Banyard
If this moves forward, I, and many others, will demand a formal, fully supported utility for locating and automatically transforming all usages of short open tags on the system. That is, a scanner to locate every line of code that uses them with options to change the code automatically. (I don't know of anyone who is going to eagerly sift through a giant mess of grep output.) I manage hundreds of *internal* software applications that use short open tags. This proposal, as it stands, will *flood* log files with deprecation notices in 7.4 and risks exposure of/leaking information like database credentials and various secrets like XSRF token bases if someone simply updates to PHP 8 (e.g. upgrades the OS, which has a PHP 8 package). It would be incredibly short-sighted to deprecate and remove this but not offer tools to developers and deployers to find code that needs to be changed before doing the upgrade. This proposal contains at least one system security issue. OS package managers (apt, yum, etc.) will have to deploy either the aforementioned scanner/updater tool and/or look specifically at the relevant existing PHP INI setting during upgrade paths and possibly reject the system upgrade if it finds even one usage of short open tags on the system. When I write public, open source software, I always use '' since important secrets like that are generally shunted into a nicely formatted 'settings.php' file. However, code like ' would break but '' would not - the latter, IMO, being more readable anyway. This doesn't change the fact that I'd still want a utility to automatically locate upgrade issues. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ And once you find my software useful: http://cubiclesoft.com/donate/
  104943
March 25, 2019 16:16 come@opensides.be (=?ISO-8859-1?Q?C=F4me?= Chilliet)
Le lundi 25 mars 2019, 08:45:22 CET Thomas Hruska a écrit :
> If this moves forward, I, and many others, will demand a formal, fully > supported utility for locating and automatically transforming all usages > of short open tags on the system. That is, a scanner to locate every > line of code that uses them with options to change the code > automatically.
You can use the fixer "full_opening_tag" of php-cs-fixer: https://cs.symfony.com/ There is also "no_short_echo_tag" if you want to replace "
  104946
March 25, 2019 18:18 peterkokot@gmail.com (Peter Kokot)
Hello,

On Mon, 25 Mar 2019 at 14:02, G. P. B. banyard@gmail.com> wrote:
> > Hello internals, > > I would like to start the discussion about the deprecation of PHP's short > open tags: > https://wiki.php.net/rfc/deprecate_php_short_tags > > As this is my first RFC all feedback is welcome. > However, due to the nature of the RFC and it being self-contained, the > planned date to > beginning voting this RFC is after the mandatory two weeks discussion > period and would > start on Monday the 8th of April (2019-04-08) and be open for two weeks > until Monday the > 22nd of April (2019-04-22). > > Best regards > > George P. Banyard
Short opening tags are by default disabled in the php.ini settings on the majority of PHP installations. This means that writing modern PHP code shouldn't use these anymore because the code isn't properly portable or let's say it is less portable. On top of all removing these would also simplify things a bit - one opening tag for the same thing less. Also, a quick opinion based poll has been done in the PHP.earth Facebook group [1] with ~96% in favour of the removal. So, +1 for removing these and simplify things more. There are only two tags really needed in PHP templating engines https://fb.com/groups/2204685680/permalink/10157687999015681/ Best regards. -- Peter Kokot
  104947
March 25, 2019 19:19 robehickman@gmail.com (Robert Hickman)
As long as it dosn't remove 'peterkokot@gmail.com> wrote:
> > Hello, > > On Mon, 25 Mar 2019 at 14:02, G. P. B. banyard@gmail.com> wrote: > > > > Hello internals, > > > > I would like to start the discussion about the deprecation of PHP's short > > open tags: > > https://wiki.php.net/rfc/deprecate_php_short_tags > > > > As this is my first RFC all feedback is welcome. > > However, due to the nature of the RFC and it being self-contained, the > > planned date to > > beginning voting this RFC is after the mandatory two weeks discussion > > period and would > > start on Monday the 8th of April (2019-04-08) and be open for two weeks > > until Monday the > > 22nd of April (2019-04-22). > > > > Best regards > > > > George P. Banyard > > Short opening tags are by default disabled in the php.ini settings on > the majority of PHP installations. This means that writing modern PHP > code shouldn't use these anymore because the code isn't properly > portable or let's say it is less portable. On top of all removing > these would also simplify things a bit - one opening tag for the same > thing less. > > Also, a quick opinion based poll has been done in the PHP.earth > Facebook group [1] with ~96% in favour of the removal. > > So, +1 for removing these and simplify things more. There are only two > tags really needed in PHP templating engines > [1]: https://fb.com/groups/2204685680/permalink/10157687999015681/ > > Best regards. > > -- > Peter Kokot > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >