# [RFC] [DISCUSSION] Deprecate PHP's short open tags V2 - Thread: https://externals.io/message/106256 - Original archive: https://news-web.php.net/php.internals/106256 - Started by G. P. B. on 2019-07-23T17:54:48+00:00 - Messages: 33 - RFC: PHP RFC: Deprecate short open tags, again (Declined) — https://externals.io/rfc/deprecate_php_short_tags_v2.md - RFC: Deprecate PHP's Short Open Tags (Obsolete) — https://externals.io/rfc/deprecate_php_short_tags.md - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/106256.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #106256 — G. P. B. — 2019-07-23T17:54:48+00:00 URL: https://externals.io/message/106256#106256 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 . 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 , 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 --- ## #106257 — Rowan Collins — 2019-07-23T19:09:50+00:00 URL: https://externals.io/message/106256#106257 >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] --- ## #106258 — Stanislav Malyshev — 2019-07-23T20:22:01+00:00 URL: https://externals.io/message/106256#106258 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 . 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 --- ## #106259 — Claude Pache — 2019-07-23T20:24:32+00:00 URL: https://externals.io/message/106256#106259 > Le 23 juil. 2019 à 19:54, G. P. B. 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 --- ## #106260 — Reinis Rozitis — 2019-07-23T20:40:53+00:00 URL: https://externals.io/message/106256#106260 > 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 ' 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 " 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 --- ## #106263 — Nikita Popov — 2019-07-23T20:56:03+00:00 URL: https://externals.io/message/106256#106263 On Tue, Jul 23, 2019 at 10:22 PM Stanislav Malyshev wrote: > Hi! > > > […] > Short > > […] > help > > […] > > 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 --- ## #106264 — Stanislav Malyshev — 2019-07-23T20:58:20+00:00 URL: https://externals.io/message/106256#106264 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 --- ## #106265 — Nikita Popov — 2019-07-23T21:03:05+00:00 URL: https://externals.io/message/106256#106265 On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins wrote: > > > […] > > 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 --- ## #106266 — Stanislav Malyshev — 2019-07-23T21:10:11+00:00 URL: https://externals.io/message/106256#106266 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 --- ## #106267 — Rowan Collins — 2019-07-23T21:33:07+00:00 URL: https://externals.io/message/106256#106267 > 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. > > […] > 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] --- ## #106268 — Peter Cowburn — 2019-07-23T21:39:57+00:00 URL: https://externals.io/message/106256#106268 > On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins > wrote: > > > […] > wrote: > > […] > could > > […] > "no" > > […] > > 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. --- ## #106269 — Stanislav Malyshev — 2019-07-23T21:42:45+00:00 URL: https://externals.io/message/106256#106269 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 --- ## #106272 — Mark Randall — 2019-07-24T00:28:53+00:00 URL: https://externals.io/message/106256#106272 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 Hello internals, > https://wiki.php.net/rfc/deprecate_php_short_tags_v2 --- ## #106273 — Mark Randall — 2019-07-24T00:37:42+00:00 URL: https://externals.io/message/106256#106273 > 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 V2 remedies that by maintaining default INI behaviour, as well as > nullifying the possibility of code / data leaks by throwing a compiler > exception if 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 --- ## #106277 — vsuraski@gmail.com — 2019-07-24T03:51:36+00:00 URL: https://externals.io/message/106256#106277 > -----Original Message----- > From: G. P. B. > Sent: Tuesday, July 23, 2019 8:55 PM > To: PHP internals ; Derick Rethans ; > Peter Kokot > 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 . > 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 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 . > 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 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 --- ## #106281 — Nikita Popov — 2019-07-24T12:20:53+00:00 URL: https://externals.io/message/106256#106281 On Tue, Jul 23, 2019 at 11:40 PM Peter Cowburn wrote: > > > > > > […] > > 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 --- ## #106282 — G. P. B. — 2019-07-24T13:27:19+00:00 URL: https://externals.io/message/106256#106282 On Tue, 23 Jul 2019 at 22:22, Stanislav Malyshev wrote: > Hi! > > > […] > Short > > […] > help > > […] > > 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 wrote: > Hi! > > > […] > > 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 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 --- ## #106283 — Chase Peeler — 2019-07-24T13:56:35+00:00 URL: https://externals.io/message/106256#106283 > On Tue, 23 Jul 2019 at 22:22, Stanislav Malyshev > wrote: > > > […] > > On Wed, 24 Jul 2019 at 02:41, Stanislav Malyshev > wrote: > > > […] > > 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. > > > > > […] > > 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: > > > […] > > ini setting. This ini setting is *enabled* by default (if no ini files is > > […] > > 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 --- ## #106284 — Christoph M. Becker — 2019-07-24T14:15:08+00:00 URL: https://externals.io/message/106256#106284 > > > > […] > > 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: > > > […] > > ini setting. This ini setting is *enabled* by default (if no ini files is > > […] > > 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 --- ## #106286 — Zeev Suraski — 2019-07-24T17:10:15+00:00 URL: https://externals.io/message/106256#106286 > 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 - > > […] > > 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: > > > […] > > ini setting. This ini setting is *enabled* by default (if no ini files is > > […] > > 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 --- Next page: https://externals.io/message/106256.md?page=2