[RFC] [DISCUSSION] Deprecate PHP's short open tags V2

Hello internals,

Due to the controversy after the initial vote on the Deprecate PHP's Short
Open Tag RFC [1] here is a new RFC to deprecate them written with the help
of Nikita Popov nikic@php.net.

This RFC is targeting PHP 7.4 and has an exemption to land after the
feature freeze granted by the Release Managers of PHP 7.4 Derick Rethans <
derick@php.net> and Peter Kokot petk@php.net, CCed to this email.

https://wiki.php.net/rfc/deprecate_php_short_tags_v2

Discussion is expected to last 2 weeks followed by a 2 week vote such that
this RFC may land in PHP7.4Beta3 as per the timeline. [2]

The only point of contention of this RFC that I potentially see is the
removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0
instead of it being removed in PHP 9 after it having had a whole major
version release cycle.

Best regards

George P. Banyard

[1] https://wiki.php.net/rfc/deprecate_php_short_tags
[2] https://wiki.php.net/todo/php74

The only point of contention of this RFC that I potentially see is the
removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0
instead of it being removed in PHP 9 after it having had a whole major
version release cycle.

Given that you've already predicted that this will be controversial, could you provide some rationale for it? Unless there's a major burden in maintaining the parser error behaviour for a few years, waiting for the next major version would seem both safer and more in line with official versioning policy.

As with deprecation itself, any violation of the "no breaking changes" rule, however slight, should have an explicit justification. If I had a vote, any RFC omitting such a justification would receive an automatic "no" from me.

Regards,

--
Rowan Collins
[IMSoP]

Hi!

Due to the controversy after the initial vote on the Deprecate PHP's Short
Open Tag RFC [1] here is a new RFC to deprecate them written with the help
of Nikita Popov nikic@php.net.

Could you please explain what has changed since the last time we
discussed it that makes it necessary to bring the second RFC on the same
topic? Did any arguments about the dangers of removing the short tags
somehow became invalid? If yes, then how? What necessitates changing the
results of that RFC almost immediately after it was implemented?

In the RFC, I read:

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.

I am not sure how it is supposed to be an argument for making such
behavior the default. Could you explain?

--
Stas Malyshev
smalyshev@gmail.com

Le 23 juil. 2019 à 19:54, G. P. B. george.banyard@gmail.com a écrit :

The only point of contention of this RFC that I potentially see is the
removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0
instead of it being removed in PHP 9 after it having had a whole major
version release cycle.

Realistically, a non-negligible proportion of users will jump from PHP 7.x to 8.1 or 8.2; so that having the parse error behaviour in 8.0 only is in no way safer for them. It is more reasonable to keep the parse error behaviour for all 8.x versions.

—Claude

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.

While this RFC is a much better way of deprecating the feature (looking at the previous votes it most likely will happen), the reasoning/text (main point) is still odd:

• if the code author wants a portable code he HAS the necessary control over it and can always follow the coding guidelines and write it using '<?php'

• contrary the control/option is taken away from the server administrator (the deployment environment provider) that if there is a project/code that uses short tags there is no way to support that anymore besides altering the code (for what he might not have the necessary control).

rr

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.

That's precisely what this RFC is intended to prevent.

By deprecating and simply removing the functionality, as implied by
the previous RFC and initially implemented
[https://github.com/php/php-src/pull/3975/], we would make such code
immediately visible in PHP 8.0. This RFC removes that danger by amending
the 8.0 behaviour to explicitly detecting the tags and throwing a
ParseError.

I am not sure how it is supposed to be an argument for making such
behavior the default.

This RFC does not make anything the default that is not already;
instead, it keeps the INI option as it was before, but changes its
behaviour:

• In 7.4, the first use of "<?" with short_open_tag enabled raises a
  deprecation notice, but no other behaviour changes (as appropriate for a
  minor version)
• In 8.0, any use of "<?" with short_open_tag enabled throws a ParseError

Arguably, this could be considered a new implementation of the previous
RFC, but it seems prudent to put it through the RFC process a second
time to to avoid claims that it has bypassed the process in some way.
Presumably if it doesn't achieve consensus, the previous plan would
remain in effect.

Regards,

--
Rowan Collins
[IMSoP]

Hi!

That's precisely what this RFC is intended to prevent.

This RFC does nothing to eliminate code written for short-tags - it is
impossible to eliminate with any RFC, in fact, it is impossible to
eliminate at all. So the only question is what is happening when server
is encountering such code.

immediately visible in PHP 8.0. This RFC removes that danger by amending
the 8.0 behaviour to explicitly detecting the tags and throwing a
ParseError.

But only for 8.0. So if you have a bad luck of skipping .0 and going
directly for .1 you're still in the same trouble.

--
Stas Malyshev
smalyshev@gmail.com

On Tue, Jul 23, 2019 at 10:22 PM Stanislav Malyshev smalyshev@gmail.com
wrote:

Hi!

Due to the controversy after the initial vote on the Deprecate PHP's
Short
Open Tag RFC [1] here is a new RFC to deprecate them written with the
help
of Nikita Popov nikic@php.net.

Could you please explain what has changed since the last time we
discussed it that makes it necessary to bring the second RFC on the same
topic? Did any arguments about the dangers of removing the short tags
somehow became invalid? If yes, then how? What necessitates changing the
results of that RFC almost immediately after it was implemented?

Sorry, but ... what? I feel like there must be some miscommunication here.
This RFC is intended as a courtesy, because the previous one was
accepted, but quite a few concerns were raised afterward and Zeev has
suggested that the question should be reevaluated in a new RFC. This is it.

I did not want to just merge the original (accepted!) implementation after
the controversial discussion it triggered, but after reading this, I
realize that I just wasted my time here. So much for being nice and giving
people a fair change to reevaluate the proposal in light of the new
arguments that have been brought forward. I guess that next time I'll just
go ahead and merge things.

Regards,
Nikita

Hi!

I did not want to just merge the original (accepted!) implementation
after the controversial discussion it triggered, but after reading this,
I realize that I just wasted my time here. So much for being nice and
giving people a fair change to reevaluate the proposal in light of the
new arguments that have been brought forward. I guess that next time
I'll just go ahead and merge things.

I think nicer would be to explain why we need second RFC and what it
adds to the previous one. If I didn't get some context, please explain.

--
Stas Malyshev
smalyshev@gmail.com

On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins rowan.collins@gmail.com
wrote:

The only point of contention of this RFC that I potentially see is the
removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0
instead of it being removed in PHP 9 after it having had a whole major
version release cycle.

Given that you've already predicted that this will be controversial, could
you provide some rationale for it? Unless there's a major burden in
maintaining the parser error behaviour for a few years, waiting for the
next major version would seem both safer and more in line with official
versioning policy.

As with deprecation itself, any violation of the "no breaking changes"
rule, however slight, should have an explicit justification. If I had a
vote, any RFC omitting such a justification would receive an automatic "no"
from me.

I agree. I don't think there's a pressing need to do the "full removal" in
PHP 8.1 in particular, so it makes more sense to this in the next major
version (9.0), as usual.

Nikita

Hi!

I agree. I don't think there's a pressing need to do the "full removal" in
PHP 8.1 in particular, so it makes more sense to this in the next major
version (9.0), as usual.

This may be more acceptable, if we are sure there would be no short tags
code remaining anywhere by the time of 9.0.

Stas Malyshev
smalyshev@gmail.com

This RFC does nothing to eliminate code written for short-tags - it is
impossible to eliminate with any RFC, in fact, it is impossible to
eliminate at all.

It does more to eliminate it than the previous RFC, by having at least
one version where it generates an error, rather than being silently ignored.

So the only question is what is happening when server
is encountering such code.

Yes, which is exactly what this RFC is changing, because although the
previous RFC was accepted, concerns were raised that the details hadn't
been fully considered.

immediately visible in PHP 8.0. This RFC removes that danger by amending
the 8.0 behaviour to explicitly detecting the tags and throwing a
ParseError.
But only for 8.0. So if you have a bad luck of skipping .0 and going
directly for .1 you're still in the same trouble.

Yes, as I said elsewhere, I think 9.0 is a much better time for the full
removal, and I hope the RFC will be amended appropriately.

However, to reiterate, either is still later than the previous RFC.

Regards,

--
Rowan Collins
[IMSoP]

On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins rowan.collins@gmail.com
wrote:

On 23 July 2019 18:54:48 BST, "G. P. B." george.banyard@gmail.com
wrote:

The only point of contention of this RFC that I potentially see is the
removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0
instead of it being removed in PHP 9 after it having had a whole major
version release cycle.

Given that you've already predicted that this will be controversial,
could
you provide some rationale for it? Unless there's a major burden in
maintaining the parser error behaviour for a few years, waiting for the
next major version would seem both safer and more in line with official
versioning policy.

As with deprecation itself, any violation of the "no breaking changes"
rule, however slight, should have an explicit justification. If I had a
vote, any RFC omitting such a justification would receive an automatic
"no"
from me.

I agree. I don't think there's a pressing need to do the "full removal" in
PHP 8.1 in particular, so it makes more sense to this in the next major
version (9.0), as usual.

Nikita

Would you (George, Nikita) consider removing the details about the eventual
removal of the feature from this RFC? We can run with the error for a
bunch of releases / years, and see what happens. I don't see why we should
necessarily decide now on something that might be 5 years or more away.

Hi!

Would you (George, Nikita) consider removing the details about the eventual
removal of the feature from this RFC? We can run with the error for a
bunch of releases / years, and see what happens. I don't see why we should
necessarily decide now on something that might be 5 years or more away.

That sounds like a good idea - nothing prevents us from talking about
the removal once we are in the vicinity of 9.0 and have better picture
of whether any short tags code is out there or everybody is already
enlightened.

--
Stas Malyshev
smalyshev@gmail.com

I continue to find motivations #1 and #3 utterly bizarre, especially
that "open tags not being compatible with XML" is still being used as a
justification.

That said, the depreciation and removal process looks solid, with the
exception of complete removal in PHP 8.1.

I must question if people are really so desperate to use <? in plain
text (for XML?) that it needs to be removed with such haste, especially
as its continued existence at that point would be strictly as a security
feature.

If I may make one suggestion, I see the depreciation message is quite
plain. One would not be stretching the bounds of reasonableness too far
to suggest the creation of a dedicated page on php.net that contains a
description, a link to csfixer etc, and then that link be included in
the depreciation message itself.

--
Mark Randall

Hello internals,
https://wiki.php.net/rfc/deprecate_php_short_tags_v2

I think nicer would be to explain why we need second RFC and what it
adds to the previous one. If I didn't get some context, please explain.

The previous one, as written, carried a high probability of silently
leaking both code and data, but these arguments against it only gained
prominence after the RFC had already passed.

V2 remedies that by maintaining default INI behaviour, as well as
nullifying the possibility of code / data leaks by throwing a compiler
exception if <? is encountered (and enabled), thus denying the VM an
opportunity to execute a file which contains potentially leaky code.

If short tags are to be removed, V2 is a significantly more reasonable
way of going about it.

--
Mark Randall

Hi!

V2 remedies that by maintaining default INI behaviour, as well as
nullifying the possibility of code / data leaks by throwing a compiler
exception if <? is encountered (and enabled), thus denying the VM an
opportunity to execute a file which contains potentially leaky code.

Oh, I thought it was already agreed upon... I thought the RFC somehow
modifies upon that. I think parse error for 8.x would be acceptable.

--
Stas Malyshev
smalyshev@gmail.com

-----Original Message-----
From: G. P. B. george.banyard@gmail.com
Sent: Tuesday, July 23, 2019 8:55 PM
To: PHP internals internals@lists.php.net; Derick Rethans derick@php.net;
Peter Kokot petk@php.net
Subject: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

Hello internals,

Due to the controversy after the initial vote on the Deprecate PHP's Short Open
Tag RFC [1] here is a new RFC to deprecate them written with the help of Nikita
Popov nikic@php.net.

George,

Thanks for creating a new RFC instead of going into a bit of a procedural limbo. I appreciate that.

Everyone,

Much of the feedback for v2 was around the problematic idea of changing behavior between 8.0 and 8.1, but little was said on the premise of the proposal itself. Much like the original RFC, the rationale for this deprecation remains quite weak. The differences are that it's clearer now (3 separate motivations were rightfully condensed into just 1), and the bogus motivation that this would somehow simplify the parser was removed. But same as with the original RFC - this RFC creates the impression of a problem that doesn't really exist, and then provides a way of fixing it - while the 'do nothing' option remains a vastly superior outcome in terms of gain vs. harm.

The simple reality is this:

• Absolutely nothing changed about <? since its introduction in 1998, for better or for worse. The reasoning - about portable code/ini settings, as well as XML - was there 21 years ago when it was introduced - and still, it was introduced.
• If anything, XML became a lot less relevant. There were intense discussions about <? back in 1998, since back then - <? was all the rage. It was perceived as one of the most basic and fundamental building blocks of the future Web to be - as SOAP was beginning to form up and everyone thought this was the future of Web-based services, as well as virtually anything else - from config files to databases. Reality, as we all know, took slightly different turns - and XML is a lot less relevant today than it was 21 years ago. It looks categorically anachronistic to care more about it today than we did back then.
• Short tags were never intended for portable code, and users who use it know that very well. From the get go, <?php was introduced as the portable start tag - and let's be honest with ourselves - everyone who remotely cares about portability (as well as many if not most of those who don't) - use it exclusively. Virtually all frameworks and projects have coding standards that disallow short tags. You need to purposely turn it on in your own deployment - people and companies who use it use it exclusively for internal purposes.

Which, in turn, translates to this:

• The motivation for removing short tags today is a lot weaker than the motivation was not to add it in the first place back in 1998 (XML being a lot less important). This makes for an unreasonable basis for deprecation.
• Perhaps it was a mistake adding it in the first place, perhaps not. Either way - the motivation for proactively removing it - and hurting users in the process - is simply not nearly sufficient when weighting the gain/harm balance: Everyone who's not using it (presumably, mostly everyone reading this message) will be unaffected. Everyone who is using it will be remarkably unimpressed with the weak reasoning for removing it, and rightfully so.

This is a clear net-loss RFC if I've ever seen one. I'm saying that as someone who (like most of you) never uses short tags, but at the same time is not missionary against those who are and have been peacefully using them for potentially decades.

I do think that these counterpoints should be represented in the RFC, as many folks vote on RFCs without regularly reading all messages on internals@. I'll be happy to add them (of course, in a condensed summarized fashion).

Thanks,

Zeev

[Had an issue with my email client, apologies if it ends up being sent
twice]

Hello internals,

Due to the controversy after the initial vote on the Deprecate PHP's Short
Open Tag RFC [1] here is a new RFC to deprecate them written with the help
of Nikita Popov nikic@php.net.

George,

Thanks for creating a new RFC instead of going into a bit of a procedural
limbo. I appreciate that.

Everyone,

Much of the feedback for v2 was around the problematic idea of changing
behavior between 8.0 and 8.1, but little was said on the premise of the
proposal itself. Much like the original RFC, the rationale for this
deprecation remains quite weak. The differences are that it's clearer now
(3 separate motivations were rightfully condensed into just 1), and the
bogus motivation that this would somehow simplify the parser was removed.
But same as with the original RFC - this RFC creates the impression of a
problem that doesn't really exist, and then provides a way of fixing it -
while the 'do nothing' option remains a vastly superior outcome in terms of
gain vs. harm.

The simple reality is this:

• Absolutely nothing changed about <? since its introduction in 1998, for
  better or for worse. The reasoning - about portable code/ini settings, as
  well as XML - was there 21 years ago when it was introduced - and still, it
  was introduced.

• If anything, XML became a lot less relevant. There were intense
  discussions about <? back in 1998, since back then - <? was all the rage.
  It was perceived as one of the most basic and fundamental building blocks
  of the future Web to be - as SOAP was beginning to form up and everyone
  thought this was the future of Web-based services, as well as virtually
  anything else - from config files to databases. Reality, as we all know,
  took slightly different turns - and XML is a lot less relevant today than
  it was 21 years ago. It looks categorically anachronistic to care more
  about it today than we did back then.

• Short tags were never intended for portable code, and users who use it
  know that very well. From the get go, <?php was introduced as the portable
  start tag - and let's be honest with ourselves - everyone who remotely
  cares about portability (as well as many if not most of those who don't) -
  use it exclusively. Virtually all frameworks and projects have coding
  standards that disallow short tags. You need to purposely turn it on in
  your own deployment - people and companies who use it use it exclusively
  for internal purposes.

Which, in turn, translates to this:

• The motivation for removing short tags today is a lot weaker than the
  motivation was not to add it in the first place back in 1998 (XML being a
  lot less important). This makes for an unreasonable basis for deprecation.

• Perhaps it was a mistake adding it in the first place, perhaps not.
  Either way - the motivation for proactively removing it - and hurting users
  in the process - is simply not nearly sufficient when weighting the
  gain/harm balance: Everyone who's not using it (presumably, mostly
  everyone reading this message) will be unaffected. Everyone who is using
  it will be remarkably unimpressed with the weak reasoning for removing it,
  and rightfully so.

This is a clear net-loss RFC if I've ever seen one. I'm saying that as
someone who (like most of you) never uses short tags, but at the same time
is not missionary against those who are and have been peacefully using them
for potentially decades.

I do think that these counterpoints should be represented in the RFC, as
many folks vote on RFCs without regularly reading all messages on internals@.
I'll be happy to add them (of course, in a condensed summarized fashion).

Thanks,

Zeev

I did not want to just merge the original (accepted!) implementation after
the controversial discussion it triggered, but after reading this, I
realize that I just wasted my time here. So much for being nice and giving
people a fair change to reevaluate the proposal in light of the new
arguments that have been brought forward. I guess that next time I'll just
go ahead and merge things.

• The motivation for removing short tags today is a lot weaker than the
  motivation was not to add it in the first place back in 1998 (XML being a
  lot less important). This makes for an unreasonable basis for deprecation.

I think it fair to say:

1. The RFC to remove short open tags passed
2. The backwards-compatibility break is contentious

I move an alternative motion: that short open tags do not change in PHP
7.4, throw a deprecation warning in PHP 8.X, and what happens next (e.g.
removal) is left for a future, PHP 9 RFC. The manual is updated to say they
are deprecated and will be removed in future, to dissuade new usage.

Sure, this is "kicking the can" down the road. It's also a proposal I hope
both sides can support.

Peter

On Tue, Jul 23, 2019 at 11:40 PM Peter Cowburn petercowburn@gmail.com
wrote:

On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins rowan.collins@gmail.com
wrote:

On 23 July 2019 18:54:48 BST, "G. P. B." george.banyard@gmail.com
wrote:

The only point of contention of this RFC that I potentially see is the
removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0
instead of it being removed in PHP 9 after it having had a whole major
version release cycle.

Given that you've already predicted that this will be controversial,
could
you provide some rationale for it? Unless there's a major burden in
maintaining the parser error behaviour for a few years, waiting for the
next major version would seem both safer and more in line with official
versioning policy.

As with deprecation itself, any violation of the "no breaking changes"
rule, however slight, should have an explicit justification. If I had a
vote, any RFC omitting such a justification would receive an automatic
"no"
from me.

I agree. I don't think there's a pressing need to do the "full removal" in
PHP 8.1 in particular, so it makes more sense to this in the next major
version (9.0), as usual.

Nikita

Would you (George, Nikita) consider removing the details about the
eventual removal of the feature from this RFC? We can run with the error
for a bunch of releases / years, and see what happens. I don't see why we
should necessarily decide now on something that might be 5 years or more
away.

I don't see a benefit in leaving this open-ended and prefer to have a fixed
timeline for this. The full removal in 9.0 is already very, very
conservative. Using short tags will have produced a fatal error for a whole
major version at that point. If necessary the question can be reevaluated
at that time, but the burden of proof must be on the people arguing an
additional delay, not the other way around.

Nikita

On Tue, 23 Jul 2019 at 22:22, Stanislav Malyshev smalyshev@gmail.com
wrote:

Hi!

Due to the controversy after the initial vote on the Deprecate PHP's
Short
Open Tag RFC [1] here is a new RFC to deprecate them written with the
help
of Nikita Popov nikic@php.net.

Could you please explain what has changed since the last time we
discussed it that makes it necessary to bring the second RFC on the same
topic?

On Wed, 24 Jul 2019 at 02:41, Stanislav Malyshev smalyshev@gmail.com
wrote:

Hi!

V2 remedies that by maintaining default INI behaviour, as well as
nullifying the possibility of code / data leaks by throwing a compiler
exception if <? is encountered (and enabled), thus denying the VM an
opportunity to execute a file which contains potentially leaky code.

Oh, I thought it was already agreed upon... I thought the RFC somehow
modifies upon that. I think parse error for 8.x would be acceptable.

--
Stas Malyshev
smalyshev@gmail.com

Nothing, this is a courtesy vote as the implementation proposed in this RFC
is the one which would be used to implement the previous RFC even though
it is not the one proposed initially.

Now if we can all agree that this can land without needing to go through
this
whole process I think everybody wins: we all don't need to spend time on
this,
it can be merged as it, the RMs could re-tag Beta 1 (which may will need to
happen because of some problems with the wincache extension from what
I'm seeing) which puts less strain on them IMHO.
Because I'm pretty sure I'm one of the most annoyed to need to go through
this process once again.
Is this going to happen? Probably not so here we are.

• [Short tags] You need to purposely turn it on in your own deployment -
  people and companies who use it use it exclusively for internal purposes.

This is just plain wrong since PHP 5.4 as it is enabled by default and you
need to actively turn it OFF as which can be seen on https://3v4l.org [1]
as it doesn't use any INI configuration files. Now as stated in the RFC:

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.

which is probably why most of us - and most users - think that it needs to
be implicitly enabled.

I've modified the RFC to state the removal of the short_open-tags in PHP
9.0.

Best regards

George P. Banyard

[1] https://3v4l.org/kKDI9

On Tue, 23 Jul 2019 at 22:22, Stanislav Malyshev smalyshev@gmail.com
wrote:

Hi!

Due to the controversy after the initial vote on the Deprecate PHP's
Short
Open Tag RFC [1] here is a new RFC to deprecate them written with the
help
of Nikita Popov nikic@php.net.

Could you please explain what has changed since the last time we
discussed it that makes it necessary to bring the second RFC on the same
topic?

On Wed, 24 Jul 2019 at 02:41, Stanislav Malyshev smalyshev@gmail.com
wrote:

Hi!

V2 remedies that by maintaining default INI behaviour, as well as
nullifying the possibility of code / data leaks by throwing a compiler
exception if <? is encountered (and enabled), thus denying the VM an
opportunity to execute a file which contains potentially leaky code.

Oh, I thought it was already agreed upon... I thought the RFC somehow
modifies upon that. I think parse error for 8.x would be acceptable.

--
Stas Malyshev
smalyshev@gmail.com

Nothing, this is a courtesy vote as the implementation proposed in this RFC
is the one which would be used to implement the previous RFC even though
it is not the one proposed initially.

Now if we can all agree that this can land without needing to go through
this
whole process I think everybody wins: we all don't need to spend time on
this,
it can be merged as it, the RMs could re-tag Beta 1 (which may will need to
happen because of some problems with the wincache extension from what
I'm seeing) which puts less strain on them IMHO.
Because I'm pretty sure I'm one of the most annoyed to need to go through
this process once again.
Is this going to happen? Probably not so here we are.

• [Short tags] You need to purposely turn it on in your own deployment -
  people and companies who use it use it exclusively for internal purposes.

This is just plain wrong since PHP 5.4 as it is enabled by default and you
need to actively turn it OFF as which can be seen on https://3v4l.org [1]
as it doesn't use any INI configuration files. Now as stated in the RFC:

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.

which is probably why most of us - and most users - think that it needs to
be implicitly enabled.

I've modified the RFC to state the removal of the short_open-tags in PHP
9.0.

Best regards

George P. Banyard

[1] https://3v4l.org/kKDI9

I was very vocal in regards to the first RFC (both before and after the
vote) so I figured I'd should say something about this RFC.

My overall opinion remains the same: There is still no justification for
removing short tags that justifies the BC break. I pretty much agree with
everything Zeev said in his email. That being said, I think this RFC
handles the deprecation process much better. My objections to the previous
RFC were two-fold: 1.) benefits didn't outweigh harms and 2.)
deprecation/removal path was dangerous and harmful.

I still think #1 applies to this RFC. I do not think #2 does. While I agree
with some others that the it might be better to postpone the decision about
the ultimate removal to a later date, I don't think slating it for 9.0 is
that big of a deal. I think it also gives people much more time to adapt
than previous road maps.

--
Chase Peeler
chasepeeler@gmail.com

• [Short tags] You need to purposely turn it on in your own deployment -
  people and companies who use it use it exclusively for internal purposes.

This is just plain wrong since PHP 5.4 as it is enabled by default and you
need to actively turn it OFF as which can be seen on https://3v4l.org [1]
as it doesn't use any INI configuration files. Now as stated in the RFC:

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.

which is probably why most of us - and most users - think that it needs to
be implicitly enabled.

Maybe the configuration option --(en|dis)able-short-tags adds to this
confusion.

Thanks,
Christoph

Now if we can all agree that this can land without needing to go through
this
whole process I think everybody wins: we all don't need to spend time on
this,
it can be merged as it, the RMs could re-tag Beta 1 (which may will need to
happen because of some problems with the wincache extension from what
I'm seeing) which puts less strain on them IMHO.

Everybody wins - except for our users.

• [Short tags] You need to purposely turn it on in your own deployment -

people and companies who use it use it exclusively for internal purposes.

This is just plain wrong since PHP 5.4 as it is enabled by default and you
need to actively turn it OFF as which can be seen on https://3v4l.org [1]
as it doesn't use any INI configuration files. Now as stated in the RFC:

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.

I admit I did not recall the hardcoded default was to enable short tags.
However, there's probably a good reason for this - it hardly matters -
since the vast majority of deployments (all Linux distros, XAMPP, in short

• pretty much everything) use one of these configuration files (or a
  derivative of them) and install it to be loaded by default. So it's not
  "simply not true", it is true in the vast majority of real world cases -
  for Ubuntu & friends, for CentOS & friends, even for XAMPP - and probably
  most others, except for maybe those who build from source and don't use one
  of these files.

Zeev

On Tue, Jul 23, 2019 at 11:40 PM Peter Cowburn petercowburn@gmail.com
wrote:

On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins rowan.collins@gmail.com
wrote:

On 23 July 2019 18:54:48 BST, "G. P. B." george.banyard@gmail.com
wrote:

The only point of contention of this RFC that I potentially see is the
removal in PHP 8.1 after short open tags being a Parse Error in PHP
8.0
instead of it being removed in PHP 9 after it having had a whole major
version release cycle.

Given that you've already predicted that this will be controversial,
could
you provide some rationale for it? Unless there's a major burden in
maintaining the parser error behaviour for a few years, waiting for the
next major version would seem both safer and more in line with official
versioning policy.

As with deprecation itself, any violation of the "no breaking changes"
rule, however slight, should have an explicit justification. If I had a
vote, any RFC omitting such a justification would receive an automatic
"no"
from me.

I agree. I don't think there's a pressing need to do the "full removal"
in
PHP 8.1 in particular, so it makes more sense to this in the next major
version (9.0), as usual.

Nikita

Would you (George, Nikita) consider removing the details about the
eventual removal of the feature from this RFC? We can run with the error
for a bunch of releases / years, and see what happens. I don't see why we
should necessarily decide now on something that might be 5 years or more
away.

I don't see a benefit in leaving this open-ended and prefer to have a
fixed timeline for this. The full removal in 9.0 is already very, very
conservative. Using short tags will have produced a fatal error for a whole
major version at that point. If necessary the question can be reevaluated
at that time, but the burden of proof must be on the people arguing an
additional delay, not the other way around.

Hypothetically, it can be re-evaluated sooner, particularly if "everyone"
in the PHP ecosystem appears to respond very well once the deprecation and
error stages happen. In fact, I wouldn't want "but we voted for 9.0" to be
a point being made if/when that discussion comes along. My point is that
the removal release/date, in my opinion, is a detail that we don't need to
be concerned with right now and it's just adding noise. You disagree, and
that's totally okay.

Nikita

Hypothetically, it can be re-evaluated sooner, particularly if "everyone"
in the PHP ecosystem appears to respond very well once the deprecation and
error stages happen. In fact, I wouldn't want "but we voted for 9.0" to be
a point being made if/when that discussion comes along. My point is that
the removal release/date, in my opinion, is a detail that we don't need to
be concerned with right now and it's just adding noise. You disagree, and
that's totally okay.

Regardless of when we have the conversation, I will remain opposed to
removing it any time before 9.0.

There's very little justification for removing it in the first place, so I
can't imagine what justification there'd be to remove it 2 or 3 years
earlier.

The only advantage I can see of delaying the debate is to leave open the
possibility of keeping the error into 10.0. If that becomes necessary, it
will be a sign that something has gone wrong, because it will imply that
takeup of 8.x was so low that people are still running code where this
syntax is used. Sadly, given the current zeal for removing working
features, I fear that may happen.

Regards,

Rowan Collins
[IMSoP]