unread
Hello Internals,
As there have been no further comments the voting for my RFC [1] to
deprecate PHP's
short open tags has started and will run for two (2) weeks.
Best regards
George P. Banyard
[RFC] [VOTE] Deprecate PHP's short open tags
unread
Finally!!! everybody will be able to parse my xml files with embedded
php!!!!1!1 if I ever wrote one!!!
Sorry for the sarcasm, please don't consider this as a personal attack. The
whole community (not just you) considers short open tags poison because not
XML-compatible... while they use stuff like twig, which is also not
XML-compatible.
This is just beyond my understanding.
But sure, let's keep vilifying this kind stuff and pretend they are the
root cause of PHP's bad rep.
Sorry again for the negativity.
unread
deprecate short closing tag
<?php
/* EOF */
Finally!!! everybody will be able to parse my xml files with embedded
php!!!!1!1 if I ever wrote one!!!Sorry for the sarcasm, please don't consider this as a personal attack. The
whole community (not just you) considers short open tags poison because not
XML-compatible... while they use stuff like twig, which is also not
XML-compatible.This is just beyond my understanding.
But sure, let's keep vilifying this kind stuff and pretend they are the
root cause of PHP's bad rep.Sorry again for the negativity.
unread
Sorry for the sarcasm, please don't consider this as a personal attack. The
whole community (not just you) considers short open tags poison because not
XML-compatible...
This is rather removing another trap from the language. As long as short open tags exist and depend on INI directive, there will be bugs and source
code leaks after moving application to a different environment. Using <?php over <? is the only safe way to write PHP code, and now you need an
external tool to enforce this.
Regards,
Robert Korulczyk
W dniu 10.04.2019 o 23:49, Wes pisze:
Finally!!! everybody will be able to parse my xml files with embedded
php!!!!1!1 if I ever wrote one!!!Sorry for the sarcasm, please don't consider this as a personal attack. The
whole community (not just you) considers short open tags poison because not
XML-compatible... while they use stuff like twig, which is also not
XML-compatible.This is just beyond my understanding.
But sure, let's keep vilifying this kind stuff and pretend they are the
root cause of PHP's bad rep.Sorry again for the negativity.
unread
The
whole community (not just you) considers short open tags poison because not
XML-compatible... while they use stuff like twig, which is also not
XML-compatible.
I can’t say I’ve run into the XML issue in a real environment, but IMO the big ‘problem’ is that they can be disabled, so they can’t be relied upon for anything being distributed outside your own direct control.
Also for the record, I don’t use Twig (The one thing no one can deny is php’s power as a markup templating language.. and then people don’t use it directly? Insanity.)
Cheers
Stephen
unread
Hello Internals,
As there have been no further comments the voting for my RFC [1] to
deprecate PHP's
short open tags has started and will run for two (2) weeks.
Firstly, I apologize for not mentioning this before the vote was opened.
Does the primary (it's probably not fair to call it that, for this RFC)
vote include changing the default (php -n) from On to Off? That's what is
specified in the very concise proposal section, so it seems reasonable to
assume it's the case, but I just want to be sure since the actual vote
question doesn't mention changing the default value.
With the current state of voting, it is looking like we could end up such
that we don't deprecate (and disable by default, maybe) the feature, but
jump straight to removing it. That's not usually how feature removal
works. It would've been better, IMO, to just take the proposal
("Deprecate and disable short_open_tag in PHP 7.4 and remove PHP's short
open tags in PHP 8.0.") and make that a yes/no vote.
Best regards
George P. Banyard
unread
Hello Internals,
As there have been no further comments the voting for my RFC [1] to
deprecate PHP's
short open tags has started and will run for two (2) weeks.Firstly, I apologize for not mentioning this before the vote was opened.
Does the primary (it's probably not fair to call it that, for this RFC)
vote include changing the default (php -n) from On to Off? That's what is
specified in the very concise proposal section, so it seems reasonable to
assume it's the case, but I just want to be sure since the actual vote
question doesn't mention changing the default value.With the current state of voting, it is looking like we could end up such
that we don't deprecate (and disable by default, maybe) the feature, but
jump straight to removing it. That's not usually how feature removal
works. It would've been better, IMO, to just take the proposal
("Deprecate and disable short_open_tag in PHP 7.4 and remove PHP's short
open tags in PHP 8.0.") and make that a yes/no vote.
Hello Peter,
For changing the default from On to Off it more something I realised during
the implementation of the patch that the in-engine default is "On",
which I found to be unexpected (probably because the doc says it's only
enabled with a compile flag) so I changed it.
But the default could stay the same as I'm starting to realise that with
current state of voting we are getting kind of a mess of a split vote as
you said.
It would have been nice that someone would have noticed the problems with
the voting structure before I start it but not to sure how to proceed.
I don't know if people vote against the deprecation notice in PHP 7.4 as
the default value changes because if this is the case maybe leaving the
default
as is and only deprecating would be better?
Also I do agree that having deprecation notices before a feature removal is
wise but from my understanding the RFC which removed the ASP tags also
didn't have deprecation notices, so there is already a precedent for
removing features without warning (not that I agree with it).
So not sure how to proceed ATM and some more feedback would be probably
necessary as it is my first RFC.
Best regards
George P. Banyard
unread
Sorry for the sarcasm, please don't consider this as a personal attack. The
whole community (not just you) considers short open tags poison because not
XML-compatible...This is rather removing another trap from the language. As long as short open tags exist and depend on INI directive, there will be bugs and source
code leaks after moving application to a different environment. Using <?php over <? is the only safe way to write PHP code, and now you need an
external tool to enforce this.
I wouldn't say it is the ONLY safe way. Turning it on permanently would
also solve the problem and there's also allowing '<?[whitespace
character]' as a permanent always-on option. (Native XML compatibility
is a complaint, not a requirement of a language. XML is also basically
dead in my corner of the PHP universe, only ever cropping up on very
rare and very confused occasions.)
It's going to be interesting to see how many people who rely on and
prefer using short open tags in internal systems come out of the
woodwork when PHP 7.4 and 8 drops. Maybe I'm the only one who likes
saving a few characters here and there and thinks code is more readable
without the verbose tag.
The vote is on the knife's edge of passing/failing at the moment and
could go a couple of unusual directions as already noted elsewhere.
This is probably the most interesting RFC vote to happen in a long while.
--
Thomas Hruska
CubicleSoft President
I've got great, time saving software that you will find useful.
And once you find my software useful:
unread
Turning it on permanently would also solve the problem
Well, yes, although it creates "another way of doing the same thing". So far PHP was on a way to remove redundant tags. Permanently enabling of short
open tags looks like a move in the opposite direction.
Personally, I'm surprised by the controversy around this change. So far it was an obvious anti-pattern for me, and never seen anybody who was aware of
the consequences of using <? and still use <? instead <?php on purpose.
Regards,
Robert Korulczyk
W dniu 11.04.2019 o 17:36, Thomas Hruska pisze:
Sorry for the sarcasm, please don't consider this as a personal attack. The
whole community (not just you) considers short open tags poison because not
XML-compatible...This is rather removing another trap from the language. As long as short open tags exist and depend on INI directive, there will be bugs and source
code leaks after moving application to a different environment. Using <?php over <? is the only safe way to write PHP code, and now you need an
external tool to enforce this.I wouldn't say it is the ONLY safe way. Turning it on permanently would also solve the problem and there's also allowing '<?[whitespace character]'
as a permanent always-on option. (Native XML compatibility is a complaint, not a requirement of a language. XML is also basically dead in my corner
of the PHP universe, only ever cropping up on very rare and very confused occasions.)It's going to be interesting to see how many people who rely on and prefer using short open tags in internal systems come out of the woodwork when
PHP 7.4 and 8 drops. Maybe I'm the only one who likes saving a few characters here and there and thinks code is more readable without the verbose tag.The vote is on the knife's edge of passing/failing at the moment and could go a couple of unusual directions as already noted elsewhere. This is
probably the most interesting RFC vote to happen in a long while.
unread
From: Robert Korulczyk [mailto:robert@korulczyk.pl]
Personally, I'm surprised by the controversy around this change. So far it was an
obvious anti-pattern for me, and never seen anybody who was aware of the
consequences of using <? and still use <? instead <?php on purpose.
It's not really a problem for programmers/coders writing new code rather for server providers/administrators (maybe also a reason why such issues are not (or rarely) voiced in a language development internal list) hosting legacy applications where no one wants or there is nobody to fix anything (even more with an automatic third party tool) and then there won't even be a switch (ini option) anymore for backwards compability.
So you are (will be) forced to stay on EOL php version or implement a patch for reverting particular thing in your distro/custom package.
p.s. somewhat similar is the situation with 'mysql' extension which by default prints a lot of deprecated warnings even being in pecl and basically the same wrapper around mysqlnd as mysqli/pdo, but at least there is still an option if your code really requires mysql_*
(and many thanks to the people like Dmitry, Matteo who still make it compatible with the actual php versions).
rr
unread
Hello Internal,
The two weeks of voting have now ended.
The results are 38 for and 18 against (total 56) for the primary vote to
deprecate PHP's short open tag in PHP 7.4.
This passes in favor with 68%.
The results are 42 for and 15 against (total 57) for the secondary vote to
remove PHP's short open tag in PHP 8.
This passes in favor with 74%.
Thanks for everyone who voted on this issue.
Best regards
George P. Banyard
unread
Hello list,
I assume this is only about <?, not <?=.
I do not see this distinction mentioned in the RFC, perhaps I missed it? I
think it would be useful to make this explicit, to avoid possible
confusion.G. P. B. george.banyard@gmail.com schrieb am Mi., 24. Apr. 2019, 13:29:
Hello Internal,
The two weeks of voting have now ended.
The results are 38 for and 18 against (total 56) for the primary vote to
deprecate PHP's short open tag in PHP 7.4.
This passes in favor with 68%.The results are 42 for and 15 against (total 57) for the secondary vote to
remove PHP's short open tag in PHP 8.
This passes in favor with 74%.Thanks for everyone who voted on this issue.
Best regards
George P. Banyard
This is indeed only for the <? tag, it is explecitly mentionnend that the
RFC [1] does not affect the <?= tag in the Unaffected PHP Functionality
section.
Best regards
George P. Banyard
unread
FWIW,
I think it's a bad decision, made against the thoughts of clear majority of core developers - and for hardly a good reason. I believe it illustrates very well why we need to properly define our voting eligibility rules, and I hope someone would be up to the challenge of tackling it (I decided not to pursue it further after the 'abolish' RFC(s)).
A 68% majority which barely clears the 2/3 requirements for something as fundamental as that - with so many core devs against it - we'll deserve all the criticism that will be coming our way in 7.4/8.0 from end users wondering why we needlessly broke their apps and made migration a bit more of a headache.
My 2c.
Zeev
-----Original Message-----
From: G. P. B. george.banyard@gmail.com
Sent: Wednesday, April 24, 2019 2:29 PM
To: PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
Hello Internal,
The two weeks of voting have now ended.
The results are 38 for and 18 against (total 56) for the primary vote to deprecate PHP's short open tag in PHP 7.4.
This passes in favor with 68%.
The results are 42 for and 15 against (total 57) for the secondary vote to remove PHP's short open tag in PHP 8.
This passes in favor with 74%.
Thanks for everyone who voted on this issue.
Best regards
George P. Banyard
unread
A 68% majority which barely clears the 2/3 requirements for something as fundamental as that - with so many core devs against it - we'll deserve all the criticism that will be coming our way in 7.4/8.0 from end users wondering why we needlessly broke their apps and made migration a bit more of a headache.
This is yet another negative move in my forward planning and just
another cross against even bothering with PHP8 ... and PHP7.4 is only
going to complain about things so while I've not even started testing on
PHP7.3, that is likely to be the last version of PHP I will be using ...
once all the warnings are dealt with on PHP7.2 ... I don't think even
the carrot of 'JIT' this time trumps being beaten around the head with
more and more BC changes we will to have to manage and adding 'php' to
every <? that is not a simple <?= in template files goes heavily against
all the other attempts at removing descriptive text elsewhere.
--
Lester Caine - G8HFL
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
unread
A 68% majority which barely clears the 2/3 requirements for something as
fundamental as that - with so many core devs against it - we'll deserve all the
criticism that will be coming our way in 7.4/8.0 from end users wondering why
we needlessly broke their apps and made migration a bit more of a headache.
It's quite interesting to check the karma levels for the voters (might be on a slippery slope here but it feels a bit unfair that someone with just a documentation karma (or no karma at all (at least according to wiki.php.net)) has the same weight on a core option getting removed).
p.s. at least for the deprecation stage for 7.4 the revert patch is simple
rr
unread
A 68% majority which barely clears the 2/3 requirements for something as
fundamental as that - with so many core devs against it - we'll deserve all
the criticism that will be coming our way in 7.4/8.0 from end users
wondering why we needlessly broke their apps and made migration a bit more
of a headache.This is yet another negative move in my forward planning and just
another cross against even bothering with PHP8 ... and PHP7.4 is only
going to complain about things so while I've not even started testing on
PHP7.3, that is likely to be the last version of PHP I will be using ...
once all the warnings are dealt with on PHP7.2 ... I don't think even
the carrot of 'JIT' this time trumps being beaten around the head with
more and more BC changes we will to have to manage and adding 'php' to
every <? that is not a simple <?= in template files goes heavily against
all the other attempts at removing descriptive text elsewhere.Total files scanned: 20,767
Total lines scanned: 4,013,170
Total short open tag references: 6,787
Total files w/ short open tag references: 1,665
If I get started now, maybe I can have everything fixed by the time 8.1 is
released.
--
Lester Caine - G8HFLContact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk--
--
Chase Peeler
chasepeeler@gmail.com
unread
A 68% majority which barely clears the 2/3 requirements for something as fundamental as that - with so many core devs against it - we'll deserve all the criticism that will be coming our way in 7.4/8.0 from end users wondering why we needlessly broke their apps and made migration a bit more of a headache.
This is yet another negative move in my forward planning and just another cross against even bothering with PHP8 ... and PHP7.4 is only going to complain about things so while I've not even started testing on PHP7.3, that is likely to be the last version of PHP I will be using ... once all the warnings are dealt with on PHP7.2 ... I don't think even the carrot of 'JIT' this time trumps being beaten around the head with more and more BC changes we will to have to manage and adding 'php' to every <? that is not a simple <?= in template files goes heavily against all the other attempts at removing descriptive text elsewhere.
--
Lester Caine - G8HFLContact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk--
Of all the things to ‘refuse to upgrade’ over this seems pretty silly. There are multiple tools that will automatically fix this across an entire codebase in seconds. Heck, a sed 1 liner would do it if you want to DIY it.
unread
Of all the things to ‘refuse to upgrade’ over this seems pretty silly. There are multiple tools that will automatically fix this across an entire codebase in seconds. Heck, a sed 1 liner would do it if you want to DIY it.
Another nail rather a reason it it's own right, and I've looked at these
'automatic tools' and until there is one that does not enforce their own
views of code style they are just another nail ... it's bad enough when
tidy TABBED code gets messed up by someone replacing them all with
multiple spaces because that is 'the proper way to do it' ... this is
long established coding style issue not simply automatic edits to code
that IS working perfectly already. It does not 'fixing' simply because
some people don't like it ...
--
Lester Caine - G8HFL
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
unread
Hello,
Hello Internal,
The two weeks of voting have now ended.
The results are 38 for and 18 against (total 56) for the primary vote to
deprecate PHP's short open tag in PHP 7.4.
This passes in favor with 68%.The results are 42 for and 15 against (total 57) for the secondary vote to
remove PHP's short open tag in PHP 8.
This passes in favor with 74%.Thanks for everyone who voted on this issue.
Best regards
George P. Banyard
Great! It was about time this got removed. And it is a perfect timing
also - PHP 8.0 when BC breaking changes can be done. Thank you so much
for moving this forward. People who are thinking of supporting some
legacy applications on the upcoming PHP 8 will be unfortunately a bit
surprised with all the removed features and will have other bigger
issues adjusting their code compared to a really simple replace of <?
with <?php. It's what the software development and progress is also
about.
I think this is a good move.
--
Peter Kokot
unread
If I get started now, maybe I can have everything fixed by the time 8.1 is
released.
Two characters less than this sentence of yours is a 1-liner find/sed script to replace all <? with <?php.
unread
I've looked at these 'automatic tools' and until there is one that does not enforce their own views of code style they are just another nail
While the pre-build rules may not be what you want - something like PHP_CodeSniffer will let you just run a single ‘sniff’ type by passing it’s name.
Or use an IDE that has built-in support for inspections/fixing like this, or, as I said, run sed over your project files. Replacing ‘<? ‘ with ‘<?php ‘ is hardly a complex task.
unread
On Wed, Apr 24, 2019 at 11:02 AM Stephen Reay php-lists@koalephant.com
wrote:
If I get started now, maybe I can have everything fixed by the time 8.1
is
released.Two characters less than this sentence of yours is a 1-liner find/sed
script to replace all<?with<?php.
Would you really feel confident doing a blind find/replace on 6,000+
instances?
what about <?if ... <? wouldn't match that. I have instances of that in
my code, though.
What if I utilize a 3rd party library that, while no longer support, works
fine, but is now broken for no other reason than the fact that <? is no
longer supported? Whether I should be using that library or not is
irrelevant. The fact is, I am, and the fact that I won't be able to use it
in 8.0 is a barrier to me upgrading.
I don't trust mass find/replace tools like php-cs-fixer. Some of our legacy
code is really ugly. Auto-formatting with PhpStorm will break it. I don't
mind using an interactive tool, but that means I have to sit there and hit
Y or N for 6,787 instances. Some of them will probably require me to
actually open the file up and check out the surrounding context as well.
And, what happens if I miss one? I run the risk of code leak.
I think it's great that many of you have code bases that are in pretty good
shape and this change isn't going to have much of an impact on you. That's
not my case, though. It's not the case for a LOT of people. I'm not against
BC breaks - even major ones - if they are justified. I have yet to see any
good justifications for such a massive BC break.
The fact is that this change WILL prevent a lot of people from being able
to upgrade to 8.0 in a timely manner. Anyone that has to justify spending
time to prepare for an upgrade to people that don't understand the benefits
of the upgrade will have an ever harder time trying to justify the extra
time necessary. I also think you are going to find a good number of people
that will upgrade (or use PHP for the first time) unaware of the change.
They'll attempt to load older code that has short tags in it. It won't
work. They'll say "screw it" and use python or node.
Chase Peeler
chasepeeler@gmail.com
unread
If I get started now, maybe I can have everything fixed by the time 8.1 is
released.Two characters less than this sentence of yours is a 1-liner find/sed script to replace all
<?with<?php.
Would you really feel confident doing a blind find/replace on 6,000+ instances?
It’s hardly “blind”. This is what version control is for. You make a change, and then either view the diff locally, and/or commit/push it, and ask others to help review the diff.
I literally just ran the script referenced above on a client project, eyeballed the diff, and committed the changes it made to a branch. Once I’m not in the middle of anything I’ll review it again and then merge it.
what about <?if ...
<?wouldn't match that. I have instances of that in my code, though.
So change the pattern to replace <? followed by anything except an equals sign.
What if I utilize a 3rd party library that, while no longer support, works fine, but is now broken for no other reason than the fact that <? is no longer supported? Whether I should be using that library or not is irrelevant. The fact is, I am, and the fact that I won't be able to use it in 8.0 is a barrier to me upgrading.
You do the same thing as if the library had a security issue or some other bug. If it’s unsupported, you have to support it, or you have to find a replacement. It’s not like you’re dealing with a compiled module that you can’t edit. Run the same fix for short tags on the library.
I don't trust mass find/replace tools like php-cs-fixer. Some of our legacy code is really ugly. Auto-formatting with PhpStorm will break it. I don't mind using an interactive tool, but that means I have to sit there and hit Y or N for 6,787 instances. Some of them will probably require me to actually open the file up and check out the surrounding context as well. And, what happens if I miss one? I run the risk of code leak.
If auto formatting ‘breaks’ your code, you have a bigger problem than short tags.
I think it's great that many of you have code bases that are in pretty good shape and this change isn't going to have much of an impact on you. That's not my case, though. It's not the case for a LOT of people. I'm not against BC breaks - even major ones - if they are justified. I have yet to see any good justifications for such a massive BC break.
The fact is that this change WILL prevent a lot of people from being able to upgrade to 8.0 in a timely manner. Anyone that has to justify spending time to prepare for an upgrade to people that don't understand the benefits of the upgrade will have an ever harder time trying to justify the extra time necessary. I also think you are going to find a good number of people that will upgrade (or use PHP for the first time) unaware of the change. They'll attempt to load older code that has short tags in it. It won't work. They'll say "screw it" and use python or node.
Chase Peeler
chasepeeler@gmail.com <mailto:chasepeeler@gmail.com
unread
On Wed, Apr 24, 2019 at 11:27 AM Stephen Reay php-lists@koalephant.com
wrote:
On Wed, Apr 24, 2019 at 11:02 AM Stephen Reay <php-lists@koalephant.com
mailto:php-lists@koalephant.com> wrote:On 24 Apr 2019, at 21:35, Chase Peeler <chasepeeler@gmail.com <mailto:
chasepeeler@gmail.com>> wrote:If I get started now, maybe I can have everything fixed by the time
8.1 is
released.Two characters less than this sentence of yours is a 1-liner find/sed
script to replace all<?with<?php.
Would you really feel confident doing a blind find/replace on 6,000+
instances?It’s hardly “blind”. This is what version control is for. You make a
change, and then either view the diff locally, and/or commit/push it, and
ask others to help review the diff.I literally just ran the script referenced above on a client project,
eyeballed the diff, and committed the changes it made to a branch. Once I’m
not in the middle of anything I’ll review it again and then merge it.How big of a project? How many changes? You really think 6,787 changes
among 1,656 files can just be eyeballed?
what about <?if ...
<?wouldn't match that. I have instances of that
in my code, though.So change the pattern to replace
<?followed by anything except an
equals sign.<?if => <?phpif wouldn't work. It would have to be <? that is not part of
string (inside quotes, heredoc, etc). Even that could be a legitimate case,
though, if something is using eval, god forbid. '<? ' can be a straight
replacement with '<?php' but anything else '<?(?!php)' gets replaced with
'<?php '
What if I utilize a 3rd party library that, while no longer support,
works fine, but is now broken for no other reason than the fact that <? is
no longer supported? Whether I should be using that library or not is
irrelevant. The fact is, I am, and the fact that I won't be able to use it
in 8.0 is a barrier to me upgrading.You do the same thing as if the library had a security issue or some other
bug. If it’s unsupported, you have to support it, or you have to find a
replacement. It’s not like you’re dealing with a compiled module that you
can’t edit. Run the same fix for short tags on the library.All valid options. Doesn't change the fact that it's more code to update
meaning more time required to prepare for the upgrade.
I don't trust mass find/replace tools like php-cs-fixer. Some of our
legacy code is really ugly. Auto-formatting with PhpStorm will break it. I
don't mind using an interactive tool, but that means I have to sit there
and hit Y or N for 6,787 instances. Some of them will probably require me
to actually open the file up and check out the surrounding context as well.
And, what happens if I miss one? I run the risk of code leak.If auto formatting ‘breaks’ your code, you have a bigger problem than
short tags.I never said that our code was good. Most of our legacy code isn't ever
touched. It's a mess of 10k+ line spaghetti files. It works, and until we
are able to replace it, we just leave it alone. Now we are forced to go in
there and mess with it for something that doesn't even pertain to the
functionality of our application.
Also, you didn't address the issue of missed instances. There is no way to
be 100% sure any automated or manual process of replacing the tags will get
everything. One of the justifications for this RFC was the possibility of
code leak if code with short tags is loaded in an environment that has
short tags disabled. We've decided to fix that by making sure that any code
with short tags will DEFINITELY leak code. That makes a lot of sense.
Eyeballing a diff isn't going to help you find missed instances either.
I think it's great that many of you have code bases that are in pretty
good shape and this change isn't going to have much of an impact on you.
That's not my case, though. It's not the case for a LOT of people. I'm not
against BC breaks - even major ones - if they are justified. I have yet to
see any good justifications for such a massive BC break.The fact is that this change WILL prevent a lot of people from being
able to upgrade to 8.0 in a timely manner. Anyone that has to justify
spending time to prepare for an upgrade to people that don't understand the
benefits of the upgrade will have an ever harder time trying to justify the
extra time necessary. I also think you are going to find a good number of
people that will upgrade (or use PHP for the first time) unaware of the
change. They'll attempt to load older code that has short tags in it. It
won't work. They'll say "screw it" and use python or node.Chase Peeler
chasepeeler@gmail.com mailto:chasepeeler@gmail.comIt's not that I'm against the idea of abolishing short tags. It's that I
don't feel the problems abolishing them will cause are justified by the
reasons given for abolishing them. No matter how easy you think it is to
deal with this, it won't change the fact that it's going to be a barrier to
upgrading for a lot of people. It's going to have a negative impact on 8.0
adoption. It's going to lead to a larger number of people running PHP
versions that have reached EOL. In the end, it's going to hurt the market
share and reputation of PHP.
--
Chase Peeler
chasepeeler@gmail.com
unread
Hello,
I understand that breaking changes always need extra work, but in this case I think it's a quick change. On my code base (mostly legacy with 1.8m lines), I ran this and got 10 matches to check:
grep -rin "<?[^pxi=]" . | grep -v ".git/" | grep -v "Binary file" | grep -v ".js:"
Regards
Thomas
vsuraski@gmail.com hat am 24. April 2019 um 15:41 geschrieben:
FWIW,
I think it's a bad decision, made against the thoughts of clear majority of core developers - and for hardly a good reason. I believe it illustrates very well why we need to properly define our voting eligibility rules, and I hope someone would be up to the challenge of tackling it (I decided not to pursue it further after the 'abolish' RFC(s)).
A 68% majority which barely clears the 2/3 requirements for something as fundamental as that - with so many core devs against it - we'll deserve all the criticism that will be coming our way in 7.4/8.0 from end users wondering why we needlessly broke their apps and made migration a bit more of a headache.
My 2c.
Zeev
-----Original Message-----
From: G. P. B. george.banyard@gmail.com
Sent: Wednesday, April 24, 2019 2:29 PM
To: PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tagsHello Internal,
The two weeks of voting have now ended.
The results are 38 for and 18 against (total 56) for the primary vote to deprecate PHP's short open tag in PHP 7.4.
This passes in favor with 68%.The results are 42 for and 15 against (total 57) for the secondary vote to remove PHP's short open tag in PHP 8.
This passes in favor with 74%.Thanks for everyone who voted on this issue.
Best regards
George P. Banyard
unread
Surely the time for vocal opposition was before voting closed?
And I raised my opposition multiple times. That included one email where I
laid out a case for why each reason listed for the RFC did not justify the
major BC break. No one ever responded to even one of those points.
Peter
On Wed, Apr 24, 2019 at 11:27 AM Stephen Reay php-lists@koalephant.com
wrote:On Wed, Apr 24, 2019 at 11:02 AM Stephen Reay <
php-lists@koalephant.com
mailto:php-lists@koalephant.com> wrote:On 24 Apr 2019, at 21:35, Chase Peeler <chasepeeler@gmail.com
<mailto:
chasepeeler@gmail.com>> wrote:If I get started now, maybe I can have everything fixed by the time
8.1 is
released.Two characters less than this sentence of yours is a 1-liner find/sed
script to replace all<?with<?php.
Would you really feel confident doing a blind find/replace on 6,000+
instances?It’s hardly “blind”. This is what version control is for. You make a
change, and then either view the diff locally, and/or commit/push it,
and
ask others to help review the diff.I literally just ran the script referenced above on a client project,
eyeballed the diff, and committed the changes it made to a branch. Once
I’m
not in the middle of anything I’ll review it again and then merge it.How big of a project? How many changes? You really think 6,787 changes
among 1,656 files can just be eyeballed?what about <?if ...
<?wouldn't match that. I have instances of
that
in my code, though.So change the pattern to replace
<?followed by anything except an
equals sign.<?if => <?phpif wouldn't work. It would have to be <? that is not part
of
string (inside quotes, heredoc, etc). Even that could be a legitimate
case,
though, if something is using eval, god forbid. '<? ' can be a straight
replacement with '<?php' but anything else '<?(?!php)' gets replaced with
'<?php 'What if I utilize a 3rd party library that, while no longer support,
works fine, but is now broken for no other reason than the fact that <?
is
no longer supported? Whether I should be using that library or not is
irrelevant. The fact is, I am, and the fact that I won't be able to use
it
in 8.0 is a barrier to me upgrading.You do the same thing as if the library had a security issue or some
other
bug. If it’s unsupported, you have to support it, or you have to find a
replacement. It’s not like you’re dealing with a compiled module that
you
can’t edit. Run the same fix for short tags on the library.All valid options. Doesn't change the fact that it's more code to update
meaning more time required to prepare for the upgrade.I don't trust mass find/replace tools like php-cs-fixer. Some of our
legacy code is really ugly. Auto-formatting with PhpStorm will break
it. I
don't mind using an interactive tool, but that means I have to sit there
and hit Y or N for 6,787 instances. Some of them will probably require
me
to actually open the file up and check out the surrounding context as
well.
And, what happens if I miss one? I run the risk of code leak.If auto formatting ‘breaks’ your code, you have a bigger problem than
short tags.I never said that our code was good. Most of our legacy code isn't ever
touched. It's a mess of 10k+ line spaghetti files. It works, and until we
are able to replace it, we just leave it alone. Now we are forced to go in
there and mess with it for something that doesn't even pertain to the
functionality of our application.Also, you didn't address the issue of missed instances. There is no way to
be 100% sure any automated or manual process of replacing the tags will
get
everything. One of the justifications for this RFC was the possibility of
code leak if code with short tags is loaded in an environment that has
short tags disabled. We've decided to fix that by making sure that any
code
with short tags will DEFINITELY leak code. That makes a lot of sense.
Eyeballing a diff isn't going to help you find missed instances either.I think it's great that many of you have code bases that are in pretty
good shape and this change isn't going to have much of an impact on you.
That's not my case, though. It's not the case for a LOT of people. I'm
not
against BC breaks - even major ones - if they are justified. I have yet
to
see any good justifications for such a massive BC break.The fact is that this change WILL prevent a lot of people from being
able to upgrade to 8.0 in a timely manner. Anyone that has to justify
spending time to prepare for an upgrade to people that don't understand
the
benefits of the upgrade will have an ever harder time trying to justify
the
extra time necessary. I also think you are going to find a good number
of
people that will upgrade (or use PHP for the first time) unaware of the
change. They'll attempt to load older code that has short tags in it. It
won't work. They'll say "screw it" and use python or node.Chase Peeler
chasepeeler@gmail.com mailto:chasepeeler@gmail.comIt's not that I'm against the idea of abolishing short tags. It's that I
don't feel the problems abolishing them will cause are justified by the
reasons given for abolishing them. No matter how easy you think it is to
deal with this, it won't change the fact that it's going to be a barrier
to
upgrading for a lot of people. It's going to have a negative impact on 8.0
adoption. It's going to lead to a larger number of people running PHP
versions that have reached EOL. In the end, it's going to hurt the market
share and reputation of PHP.--
Chase Peeler
chasepeeler@gmail.com
--
Chase Peeler
chasepeeler@gmail.com
unread
Total files scanned: 20,767
Total lines scanned: 4,013,170
Total short open tag references: 6,787
Total files w/ short open tag references: 1,665
-
Open project in PHPStorm (or equivalent).
-
Run inspections.
-
Click convert short open tags.
Personally I prefer the shorter look of "<? if(...) { ?>" when writing
templates, but not enough to be up in arms about its removal.
If anything I'm more concerned about potential code + data leaks.
Something which was previously perfectly legitimate code, no longer
being considered code, could be quite the problematic situation...
especially if that code happened to be protective logic such as "if"
statements.
<? if ($admin) { ?>
User secret: <?= htmlspecialchars($secret) ?>
<? } ?>
I would have preferred that the parser encountering <? threw a compile
error for quite some time rather than just magically ceasing to be
relevant.
The XML argument holds no weight with me.
--
Mark Randall
unread
Hello,
I understand that breaking changes always need extra work, but in this
case I think it's a quick change. On my code base (mostly legacy with 1.8m
lines), I ran this and got 10 matches to check:Awesome. I got 6,787 over 4m lines.
grep -rin "<?[^pxi=]" . | grep -v ".git/" | grep -v "Binary file" | grep
-v ".js:"Regards
Thomasvsuraski@gmail.com hat am 24. April 2019 um 15:41 geschrieben:
FWIW,
I think it's a bad decision, made against the thoughts of clear majority
of core developers - and for hardly a good reason. I believe it illustrates
very well why we need to properly define our voting eligibility rules, and
I hope someone would be up to the challenge of tackling it (I decided not
to pursue it further after the 'abolish' RFC(s)).A 68% majority which barely clears the 2/3 requirements for something as
fundamental as that - with so many core devs against it - we'll deserve all
the criticism that will be coming our way in 7.4/8.0 from end users
wondering why we needlessly broke their apps and made migration a bit more
of a headache.My 2c.
Zeev
-----Original Message-----
From: G. P. B. george.banyard@gmail.com
Sent: Wednesday, April 24, 2019 2:29 PM
To: PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tagsHello Internal,
The two weeks of voting have now ended.
The results are 38 for and 18 against (total 56) for the primary vote to
deprecate PHP's short open tag in PHP 7.4.
This passes in favor with 68%.The results are 42 for and 15 against (total 57) for the secondary vote
to remove PHP's short open tag in PHP 8.
This passes in favor with 74%.Thanks for everyone who voted on this issue.
Best regards
George P. Banyard
--
--
--
Chase Peeler
chasepeeler@gmail.com
unread
Total files scanned: 20,767
Total lines scanned: 4,013,170
Total short open tag references: 6,787
Total files w/ short open tag references: 1,665
Open project in PHPStorm (or equivalent).
Run inspections.
Click convert short open tags.
As I've mentioned in other posts, I don't trust this to do a blind
find/replace. Some of our legacy code files are REALLY bad. Just doing auto
formatting on them in PhpStorm will break things.
Personally I prefer the shorter look of "<? if(...) { ?>" when writing
templates, but not enough to be up in arms about its removal.I personally don't like using short tags. I haven't used them since there
was a rumor they would be removed in PHP 6. My objections have nothing to
do with me personally wanting to keep using short tags.
If anything I'm more concerned about potential code + data leaks.
One of my major concerns as well. I find it ironic that one of the
justifications for the RFC was the potential for code leaks if code with
short open tags is used in an environment where short open tags are
disabled. The solution to that was to guarantee that code with short open
tags will leak code.
Something which was previously perfectly legitimate code, no longer
being considered code, could be quite the problematic situation...
especially if that code happened to be protective logic such as "if"
statements.Exactly my point. Much of our legacy code is left alone as much as
possible. We go in there when absolutely necessary due to functional
changes in our applications. This change forces us to go in there for
changes that don't relate to application functions and don't provide any
meaningful enhancement to the language itself, either.
<? if ($admin) { ?>
User secret: <?= htmlspecialchars($secret) ?>
<? } ?>I would have preferred that the parser encountering <? threw a compile
error for quite some time rather than just magically ceasing to be
relevant.I agree. I think showing a blank page would be better than leaking code.
The XML argument holds no weight with me.
Me either. I definitely don't think it is serious enough to justify the BC
break given that it can be easily worked around.
--
Mark Randall--
--
Chase Peeler
chasepeeler@gmail.com
unread
Surely the time for vocal opposition was before voting closed?
And actually having a vote would help ...
--
Lester Caine - G8HFL
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
unread
As I've mentioned in other posts, I don't trust this to do a blind
find/replace. Some of our legacy code files are REALLY bad. Just doing auto
formatting on them in PhpStorm will break things.
I believe you may be misinterpreting how these tools work. It's not a
text based find / replace.
Instead, each PHP file is being fully tokenised just as the PHP parser
would (in some cases, it is the PHP parser itself doing it) and then the
short tags are being replaced, and the file reassembled.
The only points you would have to be wary of would be if you were
computer-generating code, as it would not pick up <? used inside string
literals.
--
Mark Randall
unread
Or use an IDE that has built-in support for inspections/fixing like this, or, as I said, run sed over your project files. Replacing ‘<? ‘ with ‘<?php ‘ is hardly a complex task.
But why should I have to bother at all?
As others have indicated <? ?> in templates is tidier and HAVING to add
thousands of 'php' to the templates serves no purpose other than bowing
to other peoples coding styles! There are other easier ways of shooting
myself in the foot especially since <?= is still perfectly acceptable :(
--
Lester Caine - G8HFL
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
unread
Hello,
just a friendly reminder that by the time one writes an email here
these tags can be already replaced with the usual ones. Here is an
example of running php-cs-fixer to replace the legacy tags to the full
opening tags:
php-cs-fixer fix --rules=full_opening_tag --diff --dry-run
/path/to/php/files/with/short/tags
And then actually replacing them (without dry run):
php-cs-fixer fix --rules=full_opening_tag --diff
/path/to/php/files/with/short/tags
--
Peter Kokot
unread
Am 24.04.2019 um 19:01 schrieb Peter Kokot peterkokot@gmail.com:
just a friendly reminder that by the time one writes an email here
these tags can be already replaced with the usual ones.
A friendly reminder that some people are hosting customer code which they do not want to touch but will get support requests once the code breaks.
- Chris
unread
On Wed, Apr 24, 2019 at 1:10 PM Christian Schneider cschneid@cschneid.com
wrote:
Am 24.04.2019 um 19:01 schrieb Peter Kokot peterkokot@gmail.com:
just a friendly reminder that by the time one writes an email here
these tags can be already replaced with the usual ones.A friendly reminder that some people are hosting customer code which they
do not want to touch but will get support requests once the code breaks.Whether we are fixing it proactively or reactively, the bottom line is
that we're making modifications to code that don't fix a bug or provide an
enhancement. It involves risk with no reward.
- Chris
--
--
Chase Peeler
chasepeeler@gmail.com
unread
On Wed, 24 Apr 2019, 19:10 Christian Schneider, cschneid@cschneid.com
wrote:
Am 24.04.2019 um 19:01 schrieb Peter Kokot peterkokot@gmail.com:
just a friendly reminder that by the time one writes an email here
these tags can be already replaced with the usual ones.A friendly reminder that some people are hosting customer code which they
do not want to touch but will get support requests once the code breaks.
- Chris
That's normal? Everyone has projects to maintain, and breaking changes are
common: they're gonna call you for one anyway: if you don't like that, then
you are in the wrong line of business.
unread
Am 24.04.2019 um 19:13 schrieb Marco Pivetta ocramius@gmail.com:
Am 24.04.2019 um 19:01 schrieb Peter Kokot peterkokot@gmail.com:
just a friendly reminder that by the time one writes an email here
these tags can be already replaced with the usual ones.A friendly reminder that some people are hosting customer code which they do not want to touch but will get support requests once the code breaks.
- Chris
That's normal? Everyone has projects to maintain, and breaking changes are common: they're gonna call you for one anyway: if you don't like that, then you are in the wrong line of business.
See Chase Peeler's point: A breaking change should have a reward big enough to justify it.
And that's what where we (including Zeev Suraski and other core developers) disagree.
- Chris
unread
On Wed, 24 Apr 2019, 19:25 Christian Schneider, cschneid@cschneid.com
wrote:
Am 24.04.2019 um 19:13 schrieb Marco Pivetta ocramius@gmail.com:
On Wed, 24 Apr 2019, 19:10 Christian Schneider, cschneid@cschneid.com
wrote:
Am 24.04.2019 um 19:01 schrieb Peter Kokot peterkokot@gmail.com:just a friendly reminder that by the time one writes an email here
these tags can be already replaced with the usual ones.A friendly reminder that some people are hosting customer code which
they do not want to touch but will get support requests once the code
breaks.
- Chris
That's normal? Everyone has projects to maintain, and breaking changes
are common: they're gonna call you for one anyway: if you don't like that,
then you are in the wrong line of business.See Chase Peeler's point: A breaking change should have a reward big
enough to justify it.
And that's what where we (including Zeev Suraski and other core
developers) disagree.
- Chris
Run a fixer: they are out there, and they are extremely stable too.
Also a good chance to finally take a look at code that has been rotting in
a hard drive for too much time.
unread
On Wed, 24 Apr 2019, 19:25 Christian Schneider, cschneid@cschneid.com
wrote:Am 24.04.2019 um 19:13 schrieb Marco Pivetta ocramius@gmail.com:
On Wed, 24 Apr 2019, 19:10 Christian Schneider, <cschneid@cschneid.com
wrote:
Am 24.04.2019 um 19:01 schrieb Peter Kokot peterkokot@gmail.com:
just a friendly reminder that by the time one writes an email here
these tags can be already replaced with the usual ones.A friendly reminder that some people are hosting customer code which
they do not want to touch but will get support requests once the code
breaks.
- Chris
That's normal? Everyone has projects to maintain, and breaking changes
are common: they're gonna call you for one anyway: if you don't like
that,
then you are in the wrong line of business.See Chase Peeler's point: A breaking change should have a reward big
enough to justify it.
And that's what where we (including Zeev Suraski and other core
developers) disagree.
- Chris
Run a fixer: they are out there, and they are extremely stable too.
Also a good chance to finally take a look at code that has been rotting in
a hard drive for too much time.
All of that takes time though. I have 6,787 short opening tags found. Even
if I use a fixer to generate a diff, or, to fix them and then examine the
diff in a pull request... that's going to take a LOT of time. It's going to
start getting messy if I find false positives and need to exclude changes.
It still doesn't address the impact of changes that aren't found. Are you
100% positive that the fixers out there will catch EVERY single instance?
php-cs-fixer doesn't update <? inside of strings. If that's generating
dynamic code, then that's not getting caught.
The output from php-cs-fixer just generated a diff file that was 161,000
lines long. But yea, that's something I can scan through real quick and
make sure nothing is going to get broken. No chance I'll miss something
either.
I would LOVE to have the time to go through our legacy code and clean out
old stuff. We have a lot of technical debt that, while we aren't paying it
off at the moment, it's gaining any interest either. We also have plenty
that is. It's tough to justify putting off the stuff that is gaining
interest to focus on stuff that isn't so we can fix short tags.
I don't work for a software company. I develop an internal application for
a non-software company. There are 2 other developers and enough work for 10
developers. It's going to be VERY hard for me to get management to approve
putting off projects that have a direct impact on our business in order to
upgrade to PHP 8 when that time comes. I think you are going to find that's
a pretty common occurrence, and the adoption rate of PHP 8 is going to be
VERY low. Especially when more and more user-friendly alternatives like
python and node are coming along. It was one thing when the options were
RoR, ASP.NET, and JSP. That's not the ecosystem anymore, and it's only
going to provide additional user friendly opportunities in the next couple
of years leading up to PHP8.
Can someone PLEASE tell me the positive gains this RFC will accomplish that
justifies risking:
1.) Losing market share
2.) losing credibility
3.) removing a large number of libraries that are fine from a technical
aspect, but will stop working due to the existence of <?
4.) new security risks (code leaks that are more likely than the code leaks
the RFC seeks to prevent)
And, please don't use the existence of code fixers to justify this unless
you are willing to demonstrate how it's quick and easy to go through a
161,000 line diff file or are willing to 100% guarantee that the fixer will
not break anything, will not fix anything it shouldn't, and will not miss
anything it should fix.
--
Chase Peeler
chasepeeler@gmail.com
unread
Hi!
A 68% majority which barely clears the 2/3 requirements for something as
fundamental as that - with so many core devs against it - we'll deserve all
the criticism that will be coming our way in 7.4/8.0 from end users
wondering why we needlessly broke their apps and made migration a bit more
of a headache.
I agree. I think it will be a mistake to do this, and it will hurt a lot
of people upgrading to 7.4, and people who voted "yes" seriously
underestimate how much old code is out there. And the benefit of this
change for the user is virtually non-existant (in fact, one of the
listed benefits - "As such source code may leak if PHP relying on the
short open tags is executed on a configuration where this isn't enabled"
- is exactly the situation that would happen when the RFC is implemented).
--
Stas Malyshev
smalyshev@gmail.com
unread
Hello,
On Wed, 24 Apr 2019, 19:25 Christian Schneider, cschneid@cschneid.com
wrote:Am 24.04.2019 um 19:13 schrieb Marco Pivetta ocramius@gmail.com:
On Wed, 24 Apr 2019, 19:10 Christian Schneider, <cschneid@cschneid.com
wrote:
Am 24.04.2019 um 19:01 schrieb Peter Kokot peterkokot@gmail.com:
just a friendly reminder that by the time one writes an email here
these tags can be already replaced with the usual ones.A friendly reminder that some people are hosting customer code which
they do not want to touch but will get support requests once the code
breaks.
- Chris
That's normal? Everyone has projects to maintain, and breaking changes
are common: they're gonna call you for one anyway: if you don't like
that,
then you are in the wrong line of business.See Chase Peeler's point: A breaking change should have a reward big
enough to justify it.
And that's what where we (including Zeev Suraski and other core
developers) disagree.
- Chris
Run a fixer: they are out there, and they are extremely stable too.
Also a good chance to finally take a look at code that has been rotting in
a hard drive for too much time.All of that takes time though. I have 6,787 short opening tags found. Even
if I use a fixer to generate a diff, or, to fix them and then examine the
diff in a pull request... that's going to take a LOT of time. It's going to
start getting messy if I find false positives and need to exclude changes.
It still doesn't address the impact of changes that aren't found. Are you
100% positive that the fixers out there will catch EVERY single instance?
php-cs-fixer doesn't update <? inside of strings. If that's generating
dynamic code, then that's not getting caught.The output from php-cs-fixer just generated a diff file that was 161,000
lines long. But yea, that's something I can scan through real quick and
make sure nothing is going to get broken. No chance I'll miss something
either.I would LOVE to have the time to go through our legacy code and clean out
old stuff. We have a lot of technical debt that, while we aren't paying it
off at the moment, it's gaining any interest either. We also have plenty
that is. It's tough to justify putting off the stuff that is gaining
interest to focus on stuff that isn't so we can fix short tags.I don't work for a software company. I develop an internal application for
a non-software company. There are 2 other developers and enough work for 10
developers. It's going to be VERY hard for me to get management to approve
putting off projects that have a direct impact on our business in order to
upgrade to PHP 8 when that time comes. I think you are going to find that's
a pretty common occurrence, and the adoption rate of PHP 8 is going to be
VERY low. Especially when more and more user-friendly alternatives like
python and node are coming along. It was one thing when the options were
RoR, ASP.NET, and JSP. That's not the ecosystem anymore, and it's only
going to provide additional user friendly opportunities in the next couple
of years leading up to PHP8.Can someone PLEASE tell me the positive gains this RFC will accomplish that
justifies risking:
1.) Losing market share
2.) losing credibility
3.) removing a large number of libraries that are fine from a technical
aspect, but will stop working due to the existence of <?
4.) new security risks (code leaks that are more likely than the code leaks
the RFC seeks to prevent)And, please don't use the existence of code fixers to justify this unless
you are willing to demonstrate how it's quick and easy to go through a
161,000 line diff file or are willing to 100% guarantee that the fixer will
not break anything, will not fix anything it shouldn't, and will not miss
anything it should fix.--
Chase Peeler
chasepeeler@gmail.com
I've done few commits with about 8k files changed with very repeating
changes like this and without breaking anything. It will take you
about 30minutes... Let's say, one hour for also taking a break from
all the scrolling the git diff and to return the merge the next day
after another check or something like this.
The change (speaking for 8k files using short opening tags converted
to <?php) itself takes about 80 seconds with using PHP CS Fixer but
the memory_limit needs to be increased a bit and only relevant change
is done in all files. 8k (or 6k) opening tags is nothing very big
actually.
Then also search for similar occurrences by using a regex for those
edge cases you're mentioning in strings and such (I doubt there are
but ok) and you have this fixed. Then run this app on PHP 8 and you'll
see the other BC breaks that happen due to the major release. Major
releases are meant to break things because otherwise we can only load
the language with new things and maintain old stuff in there for
eternity.
That's why serious apps have support cycles and follow their
frameworks release and life cycle, and in the end also PHP cycle.
Simple as that.
--
Peter Kokot
unread
Hello,
On Wed, Apr 24, 2019 at 1:27 PM Marco Pivetta ocramius@gmail.com
wrote:On Wed, 24 Apr 2019, 19:25 Christian Schneider, <cschneid@cschneid.com
wrote:
Am 24.04.2019 um 19:13 schrieb Marco Pivetta ocramius@gmail.com:
On Wed, 24 Apr 2019, 19:10 Christian Schneider, <
cschneid@cschneid.comwrote:
Am 24.04.2019 um 19:01 schrieb Peter Kokot peterkokot@gmail.com:
just a friendly reminder that by the time one writes an email
here
these tags can be already replaced with the usual ones.A friendly reminder that some people are hosting customer code
which
they do not want to touch but will get support requests once the code
breaks.
- Chris
That's normal? Everyone has projects to maintain, and breaking
changes
are common: they're gonna call you for one anyway: if you don't like
that,
then you are in the wrong line of business.See Chase Peeler's point: A breaking change should have a reward big
enough to justify it.
And that's what where we (including Zeev Suraski and other core
developers) disagree.
- Chris
Run a fixer: they are out there, and they are extremely stable too.
Also a good chance to finally take a look at code that has been
rotting in
a hard drive for too much time.All of that takes time though. I have 6,787 short opening tags found.
Even
if I use a fixer to generate a diff, or, to fix them and then examine the
diff in a pull request... that's going to take a LOT of time. It's going
to
start getting messy if I find false positives and need to exclude
changes.
It still doesn't address the impact of changes that aren't found. Are you
100% positive that the fixers out there will catch EVERY single instance?
php-cs-fixer doesn't update <? inside of strings. If that's generating
dynamic code, then that's not getting caught.The output from php-cs-fixer just generated a diff file that was 161,000
lines long. But yea, that's something I can scan through real quick and
make sure nothing is going to get broken. No chance I'll miss something
either.I would LOVE to have the time to go through our legacy code and clean out
old stuff. We have a lot of technical debt that, while we aren't paying
it
off at the moment, it's gaining any interest either. We also have plenty
that is. It's tough to justify putting off the stuff that is gaining
interest to focus on stuff that isn't so we can fix short tags.I don't work for a software company. I develop an internal application
for
a non-software company. There are 2 other developers and enough work for
10
developers. It's going to be VERY hard for me to get management to
approve
putting off projects that have a direct impact on our business in order
to
upgrade to PHP 8 when that time comes. I think you are going to find
that's
a pretty common occurrence, and the adoption rate of PHP 8 is going to be
VERY low. Especially when more and more user-friendly alternatives like
python and node are coming along. It was one thing when the options were
RoR, ASP.NET, and JSP. That's not the ecosystem anymore, and it's only
going to provide additional user friendly opportunities in the next
couple
of years leading up to PHP8.Can someone PLEASE tell me the positive gains this RFC will accomplish
that
justifies risking:
1.) Losing market share
2.) losing credibility
3.) removing a large number of libraries that are fine from a technical
aspect, but will stop working due to the existence of <?
4.) new security risks (code leaks that are more likely than the code
leaks
the RFC seeks to prevent)And, please don't use the existence of code fixers to justify this unless
you are willing to demonstrate how it's quick and easy to go through a
161,000 line diff file or are willing to 100% guarantee that the fixer
will
not break anything, will not fix anything it shouldn't, and will not miss
anything it should fix.--
Chase Peeler
chasepeeler@gmail.comI've done few commits with about 8k files changed with very repeating
changes like this and without breaking anything. It will take you
about 30minutes... Let's say, one hour for also taking a break from
all the scrolling the git diff and to return the merge the next day
after another check or something like this.The change (speaking for 8k files using short opening tags converted
to <?php) itself takes about 80 seconds with using PHP CS Fixer but
the memory_limit needs to be increased a bit and only relevant change
is done in all files. 8k (or 6k) opening tags is nothing very big
actually.Honestly, the amount of people that have never seen or worked with my
codebase telling me how easy and low risk it will be to make the change are
starting to annoy me.
Can even one of you actually address any of the points I've made about why
the potential negatives of this change far outweigh any potential
positives? Heck, can you even present any potential positives?
Then also search for similar occurrences by using a regex for those
edge cases you're mentioning in strings and such (I doubt there are
but ok) and you have this fixed. Then run this app on PHP 8 and you'll
see the other BC breaks that happen due to the major release. Major
releases are meant to break things because otherwise we can only load
the language with new things and maintain old stuff in there for
eternity.As I've said before - I have no issue with BC breaks. What I have an issue
with is a BC break that has a large potential for negative consequences
that aren't anywhere close to being outweighed by the positive ones. None
of the reasons presented in the RFC justify the downsides. Not a single
person has addressed any of the potential negatives being brought up,
either. They just respond that it's easy to update your code and pretend
like there isn't a potential for negative consequences.
That's why serious apps have support cycles and follow their
frameworks release and life cycle, and in the end also PHP cycle.
Simple as that.I work on an internal application for a non-software company. We are
beholden to the cycles of our business. We try and work in upgrades when
it's possible and we have a lull between major projects or when we can
justify delaying a project in order to perform an upgrade.
--
Peter Kokot--
Unless someone decides to actually discuss the issues I've raised in
previous emails, instead of just telling me how easy it's going to be for
me to update my codebase that they know nothing about, this will be the
last message I'm sending in this thread.
--
Chase Peeler
chasepeeler@gmail.com
unread
Den 2019-04-24 kl. 16:56, skrev Peter Kokot:
Hello,
Hello Internal,
The two weeks of voting have now ended.
The results are 38 for and 18 against (total 56) for the primary vote to
deprecate PHP's short open tag in PHP 7.4.
This passes in favor with 68%.The results are 42 for and 15 against (total 57) for the secondary vote to
remove PHP's short open tag in PHP 8.
This passes in favor with 74%.Thanks for everyone who voted on this issue.
Best regards
George P. Banyard
Great! It was about time this got removed. And it is a perfect timing
also - PHP 8.0 when BC breaking changes can be done. Thank you so much
for moving this forward. People who are thinking of supporting some
legacy applications on the upcoming PHP 8 will be unfortunately a bit
surprised with all the removed features and will have other bigger
issues adjusting their code compared to a really simple replace of <?
with <?php. It's what the software development and progress is also
about.I think this is a good move.
--
Peter Kokot
Hi,
I agree on this to some degree when it comes to your own code that you
control. But,
imagine a relatively big open source library that is maintained with
small resources.
One example I have myself is using a relatively large & well established
open source
library where I'm using the latest version released before Christmas. I
run the site on
PHP 7.3, but I still get warnings regarding the RFC Counting of
non-countable objects
for PHP 7.2 related to this library.
With that experience in mind I wonder how different libraries will fare,
given this
change? One should also have in mind that there has been a discussion on
this
list about extending the support cycle for PHP 7.4 like for 5.6, but to
some degree
it was rejected which doesn't help migration efforts.
r//Björn L
unread
Den 2019-04-24 kl. 19:55, skrev Stanislav Malyshev:
Hi!
A 68% majority which barely clears the 2/3 requirements for something as
fundamental as that - with so many core devs against it - we'll deserve all
the criticism that will be coming our way in 7.4/8.0 from end users
wondering why we needlessly broke their apps and made migration a bit more
of a headache.
I agree. I think it will be a mistake to do this, and it will hurt a lot
of people upgrading to 7.4, and people who voted "yes" seriously
underestimate how much old code is out there. And the benefit of this
change for the user is virtually non-existant (in fact, one of the
listed benefits - "As such source code may leak if PHP relying on the
short open tags is executed on a configuration where this isn't enabled"
- is exactly the situation that would happen when the RFC is implemented).
Hi,
I recall the discussion about extending the support for 7.4 like we had
for 5.6, see:
I read the discussion as it was rejected, but features like this would
benefit from it,
since not only "inhouse" code will need to adapt but also libraries.
So with this feature we put more weight in the migration bucket, but not
so much
benefit. Are we then willing to extend the support for PHP 7.4 given
features like
this? Other BC breaking features will of course also benefit ;-)
r//Björn L
unread
With that experience in mind I wonder how different libraries will fare,
given this > change? One should also have in mind that there has been a discussion on
this list about extending the support cycle for PHP 7.4 like for 5.6, but to
some degree it was rejected which doesn't help migration efforts.
I'm sure Nikita will pop up sometime in the next few days and put his
recently downloaded 1000+ packages through his parser and give us some
figures on how many use short open tags, if he hasn't already done so.
I would naturally expect it to be extremely small, after all it makes no
sense to have a public package which requires a language feature to be
enabled in the INI and which can't be relied upon.
If there's a problem, it will almost certainly be with internal code,
which naturally there's a few million times more of, but that seems very
much in-scope for individual developers to fix if they want to upgrade
to PHP 8.
My main worry is, and remains, that it's being converted to just a "not
parser significant" in PHP 8. The potential for unexpected data / code
leaks is significant.
Until someone can convince me otherwise, I will continue to strongly
believe that <? should lead to a compile-time fatal error for the
foreseeable future (years).
I'm half tempted to RFC it so it can go to a vote.
--
Mark Randall
unread
Den 2019-04-24 kl. 19:43, skrev Chase Peeler:
On Wed, 24 Apr 2019, 19:25 Christian Schneider, cschneid@cschneid.com
wrote:Am 24.04.2019 um 19:13 schrieb Marco Pivetta ocramius@gmail.com:
On Wed, 24 Apr 2019, 19:10 Christian Schneider, <cschneid@cschneid.com
wrote:
Am 24.04.2019 um 19:01 schrieb Peter Kokot peterkokot@gmail.com:just a friendly reminder that by the time one writes an email here
these tags can be already replaced with the usual ones.
A friendly reminder that some people are hosting customer code which
they do not want to touch but will get support requests once the code
breaks.
- Chris
That's normal? Everyone has projects to maintain, and breaking changes
are common: they're gonna call you for one anyway: if you don't like
that,
then you are in the wrong line of business.See Chase Peeler's point: A breaking change should have a reward big
enough to justify it.
And that's what where we (including Zeev Suraski and other core
developers) disagree.
- Chris
Run a fixer: they are out there, and they are extremely stable too.
Also a good chance to finally take a look at code that has been rotting in
a hard drive for too much time.All of that takes time though. I have 6,787 short opening tags found. Even
if I use a fixer to generate a diff, or, to fix them and then examine the
diff in a pull request... that's going to take a LOT of time. It's going to
start getting messy if I find false positives and need to exclude changes.
It still doesn't address the impact of changes that aren't found. Are you
100% positive that the fixers out there will catch EVERY single instance?
php-cs-fixer doesn't update <? inside of strings. If that's generating
dynamic code, then that's not getting caught.The output from php-cs-fixer just generated a diff file that was 161,000
lines long. But yea, that's something I can scan through real quick and
make sure nothing is going to get broken. No chance I'll miss something
either.I would LOVE to have the time to go through our legacy code and clean out
old stuff. We have a lot of technical debt that, while we aren't paying it
off at the moment, it's gaining any interest either. We also have plenty
that is. It's tough to justify putting off the stuff that is gaining
interest to focus on stuff that isn't so we can fix short tags.I don't work for a software company. I develop an internal application for
a non-software company. There are 2 other developers and enough work for 10
developers. It's going to be VERY hard for me to get management to approve
putting off projects that have a direct impact on our business in order to
upgrade to PHP 8 when that time comes. I think you are going to find that's
a pretty common occurrence, and the adoption rate of PHP 8 is going to be
VERY low. Especially when more and more user-friendly alternatives like
python and node are coming along. It was one thing when the options were
RoR, ASP.NET, and JSP. That's not the ecosystem anymore, and it's only
going to provide additional user friendly opportunities in the next couple
of years leading up to PHP8.Can someone PLEASE tell me the positive gains this RFC will accomplish that
justifies risking:
1.) Losing market share
2.) losing credibility
3.) removing a large number of libraries that are fine from a technical
aspect, but will stop working due to the existence of <?
4.) new security risks (code leaks that are more likely than the code leaks
the RFC seeks to prevent)
Hi,
I did a quick check on two open source libraries that I'm using,
namely Smarty templating library and Revive ad server. A quick
glance at hand shows that they both uses the <? tag in their
latest release. Smarty 3.1.33 was released 17/9 2018 and
Revive 4.2.0 was released 23/4 2019.
It would be interesting to see if there is any benefit in fixing this
feature for these two well-established libraries? I think that both
these libraries will adapt, but how long will it take... Regarding
your points above I don't see any added value that this feature
brings for me as a user of these two libraries, since I'm quite
happy with the functionality they provide as is. How then the
developers see it is not up to me to judge.
r//Björn L
unread
Hello,
I personally am not happy with the outcome of the vote. I think
there's no practical benefit to be gained from the proposal and I
don't even understand what has urged the author to make it; I voted No
on both questions.
However, what's done is done and these post-vote protests are getting
ridiculous. Where were you all during discussion and even during the
voting period? I only remember a single person's rant here and barely
any comments on social media about it ... The people who voted Yes may
have weak arguments ("there's tools out there" isn't a good argument
in my book), they may've underestimated the impact of the change or
they may not even care about it. But they cared enough to drop by and
make their views count, while almost nobody cared enough to come here
and say this isn't right. We don't get to force-reverse a decision
that we didn't care enough for when it mattered.
Cheers,
Andrey.
unread
Hello,
Hi,
I did a quick check on two open source libraries that I'm using,
namely Smarty templating library and Revive ad server. A quick
glance at hand shows that they both uses the <? tag in their
latest release. Smarty 3.1.33 was released 17/9 2018 and
Revive 4.2.0 was released 23/4 2019.It would be interesting to see if there is any benefit in fixing this
feature for these two well-established libraries? I think that both
these libraries will adapt, but how long will it take... Regarding
your points above I don't see any added value that this feature
brings for me as a user of these two libraries, since I'm quite
happy with the functionality they provide as is. How then the
developers see it is not up to me to judge.r//Björn L
I'm not sure if we're looking at the same libraries and versions here
but both of these use normal opening tags in the code for quite a
while:
https://github.com/revive-adserver/revive-adserver
https://github.com/smarty-php/smarty
Keywords open source, PHP, and short opening tags don't go together
anymore neither people coding in PHP are using these anymore for a
very long time. If they postpone upgrades and neglect good coding
practices, nothing can help them improve or fix their apps.
Peter Kokot
unread
I did a quick check on two open source libraries that I'm using,
namely Smarty templating library and Revive ad server. A quick
glance at hand shows that they both uses the <? tag in their
latest release. Smarty 3.1.33 was released 17/9 2018 and
Revive 4.2.0 was released 23/4 2019.It would be interesting to see if there is any benefit in fixing this
feature for these two well-established libraries?
At the same time fixes for the PHP7.2 warnings would be helpful! My
templates keep throwing 'count' warnings which currently have been fixed
by simply removing the 'count' and leaving the value blank. That is
until someone who knows how to fix it provides a fix. It's BUILDING
cached templates which can't simply be sanitised by scanning the code base!
--
Lester Caine - G8HFL
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
unread
Den 2019-04-24 kl. 23:38, skrev Peter Kokot:
Hello,
Hi,
I did a quick check on two open source libraries that I'm using,
namely Smarty templating library and Revive ad server. A quick
glance at hand shows that they both uses the <? tag in their
latest release. Smarty 3.1.33 was released 17/9 2018 and
Revive 4.2.0 was released 23/4 2019.It would be interesting to see if there is any benefit in fixing this
feature for these two well-established libraries? I think that both
these libraries will adapt, but how long will it take... Regarding
your points above I don't see any added value that this feature
brings for me as a user of these two libraries, since I'm quite
happy with the functionality they provide as is. How then the
developers see it is not up to me to judge.r//Björn L
I'm not sure if we're looking at the same libraries and versions here
but both of these use normal opening tags in the code for quite a
while:
https://github.com/revive-adserver/revive-adserver
https://github.com/smarty-php/smartyKeywords open source, PHP, and short opening tags don't go together
anymore neither people coding in PHP are using these anymore for a
very long time. If they postpone upgrades and neglect good coding
practices, nothing can help them improve or fix their apps.
Well, checking a bit closer when running the script:
grep -rin "<?[^pxi=]" . | grep ".php" on the source trees I got 13 hits.
None
seems to be critical though. 5 in the Revive case comes from including an
old Smarty 2.6.18 version from 2005.
r//Björn L
unread
Hi!
A friendly reminder that some people are hosting customer code which they
do not want to touch but will get support requests once the code breaks.
- Chris
That's normal? Everyone has projects to maintain, and breaking changes are
common: they're gonna call you for one anyway: if you don't like that, then
you are in the wrong line of business.
I think answering to a valid concern that certain change would increase
breakage and maintenance load with "well, that's what you're paid for,
right?" is not what we expect from the discussion on this list. It's
dismissing rather than discussing. Let's have less of that on the list.
--
Stas Malyshev
smalyshev@gmail.com
unread
Den 2019-04-24 kl. 23:35, skrev Andrey Andreev:
Hello,
I personally am not happy with the outcome of the vote. I think
there's no practical benefit to be gained from the proposal and I
don't even understand what has urged the author to make it; I voted No
on both questions.However, what's done is done and these post-vote protests are getting
ridiculous. Where were you all during discussion and even during the
voting period? I only remember a single person's rant here and barely
any comments on social media about it ... The people who voted Yes may
have weak arguments ("there's tools out there" isn't a good argument
in my book), they may've underestimated the impact of the change or
they may not even care about it. But they cared enough to drop by and
make their views count, while almost nobody cared enough to come here
and say this isn't right. We don't get to force-reverse a decision
that we didn't care enough for when it mattered.Cheers,
Andrey.
You are absolutely right! The only excuse for myself during the
discussion etc
was that I thought it never would pass, so I "slept"... One thing to
consider
though is if the BC break together with other features is big enough to
justify
extended support for 7.4?
r//Björn L
unread
At the same time fixes for the PHP7.2 warnings would be helpful! My
templates keep throwing 'count' warnings which currently have been fixed
by simply removing the 'count' and leaving the value blank. That is
until someone who knows how to fix it provides a fix. It's BUILDING
cached templates which can't simply be sanitised by scanning the code base!
I don't think this belongs to the internals mailing list, so see
http://news.php.net/php.general/326733.
--
Christoph M. Becker
unread
I recall the discussion about extending the support for 7.4 like we had
for 5.6, see:I read the discussion as it was rejected, but features like this would
benefit from it,
since not only "inhouse" code will need to adapt but also libraries.So with this feature we put more weight in the migration bucket, but not
so much
benefit. Are we then willing to extend the support for PHP 7.4 given
features like
this? Other BC breaking features will of course also benefit ;-)
We had an RFC regarding the PHP 5 support timeline[1], so why not have
an RFC regarding the PHP 7 support timeline? Any volunteers?
[1] https://wiki.php.net/rfc/php56timeline
--
Christoph M. Becker
unread
under which fucking stone did you live all the years that there is
something like <? in your code?
Code that has been working perfectly for 20+ years and does not need me
to waste ANY time worrying about because THAT code will carry on running
PHP5.2, but templating does not need a 60% increase in characters to
make it work any differently!
And
go and learn fukcing write proper code, if you still suffer from 'count'
warnings all your code is a mess - period
has no place here either! The 'code' I am writing is to use 'count'
function IN a smarty template and PHP7.2 complains about how SMARTY
expands that in the template ...
--
Lester Caine - G8HFL
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
unread
under which fucking stone did you live all the years that there is
something like <? in your code?Code that has been working perfectly for 20+ years and does not need me
to waste ANY time worrying about because THAT code will carry on running
PHP5.2, but templating does not need a 60% increase in characters to
make it work any differently!And
go and learn fukcing write proper code, if you still suffer from 'count'
warnings all your code is a mess - periodhas no place here either! The 'code' I am writing is to use 'count'
function IN a smarty template and PHP7.2 complains about how SMARTY
expands that in the template ...I also got rude emails sent to me directly by the same person. I responded
asking them to not email me again, and they just responded with another
rude email. I was just going to ignore it, but if he's doing it to other
people, I don't mind speaking up.
--
Lester Caine - G8HFLContact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk--
--
Chase Peeler
chasepeeler@gmail.com
unread
At the same time fixes for the PHP7.2 warnings would be helpful! My
templates keep throwing 'count' warnings which currently have been fixed
by simply removing the 'count' and leaving the value blank. That is
until someone who knows how to fix it provides a fix. It's BUILDING
cached templates which can't simply be sanitised by scanning the code base!
I don't think this belongs to the internals mailing list, so see
http://news.php.net/php.general/326733.
If I was using count then that sort of fix would work. The problem is
in the way SMARTY handles adding 'count' of a smarty variable in a
template ... and certainly I have <? and <?= in the template caches as
well although that may just require going through and wiping every cache
and letting it rebuild. Enabling short tags is always on my check list
since it became a requirement and I see no reason to change that.
--
Lester Caine - G8HFL
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
unread
Hi there,
Am 24.04.2019 um 21:07 schrieb Peter Kokot:
Hello,
Run a fixer: they are out there, and they are extremely stable too.
Also a good chance to finally take a look at code that has been rotting in
a hard drive for too much time.All of that takes time though. I have 6,787 short opening tags found. Even
if I use a fixer to generate a diff, or, to fix them and then examine the
diff in a pull request... that's going to take a LOT of time. It's going to
start getting messy if I find false positives and need to exclude changes.
It still doesn't address the impact of changes that aren't found. Are you
100% positive that the fixers out there will catch EVERY single instance?
php-cs-fixer doesn't update <? inside of strings. If that's generating
dynamic code, then that's not getting caught.The output from php-cs-fixer just generated a diff file that was 161,000
lines long. But yea, that's something I can scan through real quick and
make sure nothing is going to get broken. No chance I'll miss something
either.I would LOVE to have the time to go through our legacy code and clean out
old stuff. We have a lot of technical debt that, while we aren't paying it
off at the moment, it's gaining any interest either. We also have plenty
that is. It's tough to justify putting off the stuff that is gaining
interest to focus on stuff that isn't so we can fix short tags.I don't work for a software company. I develop an internal application for
a non-software company. There are 2 other developers and enough work for 10
developers. It's going to be VERY hard for me to get management to approve
putting off projects that have a direct impact on our business in order to
upgrade to PHP 8 when that time comes. I think you are going to find that's
a pretty common occurrence, and the adoption rate of PHP 8 is going to be
VERY low. Especially when more and more user-friendly alternatives like
python and node are coming along. It was one thing when the options were
RoR, ASP.NET, and JSP. That's not the ecosystem anymore, and it's only
going to provide additional user friendly opportunities in the next couple
of years leading up to PHP8.Can someone PLEASE tell me the positive gains this RFC will accomplish that
justifies risking:
1.) Losing market share
2.) losing credibility
3.) removing a large number of libraries that are fine from a technical
aspect, but will stop working due to the existence of <?
4.) new security risks (code leaks that are more likely than the code leaks
the RFC seeks to prevent)And, please don't use the existence of code fixers to justify this unless
you are willing to demonstrate how it's quick and easy to go through a
161,000 line diff file or are willing to 100% guarantee that the fixer will
not break anything, will not fix anything it shouldn't, and will not miss
anything it should fix.--
Chase Peeler
chasepeeler@gmail.com
I've done few commits with about 8k files changed with very repeating
changes like this and without breaking anything. It will take you
about 30minutes... Let's say, one hour for also taking a break from
all the scrolling the git diff and to return the merge the next day
after another check or something like this.The change (speaking for 8k files using short opening tags converted
to <?php) itself takes about 80 seconds with using PHP CS Fixer but
the memory_limit needs to be increased a bit and only relevant change
is done in all files. 8k (or 6k) opening tags is nothing very big
actually.Then also search for similar occurrences by using a regex for those
edge cases you're mentioning in strings and such (I doubt there are
but ok) and you have this fixed. Then run this app on PHP 8 and you'll
see the other BC breaks that happen due to the major release. Major
releases are meant to break things because otherwise we can only load
the language with new things and maintain old stuff in there for
eternity.That's why serious apps have support cycles and follow their
frameworks release and life cycle, and in the end also PHP cycle.
Simple as that.--
Peter Kokot
Some thoughts and numbers from my side.
Nobody should not use a simple grep or sed like this:
grep -rin "<?[^pxi=]" . | grep ".php"
It does not search in .phtml templates for example. And it has lots of
false-positives.
This is the output in one of my projects:
grep -rin "<?[^pxi=]" . | grep ".php"
./scripts/OpenInviter/autoupdate.php:97:
$start=0;$end=strpos($res,"<?");$signatureBulk=trim(substr($res,$start,$end));$fileStriped=str_replace($signatureBulk,'',$res);
./scripts/XXXX_soap/XXXX_soap.php:1:<?
./scripts/XXXupload.php:67: Text: <input type="text" name="text"
value="<?echo $_REQUEST['text']?>"><br>
./scripts/XXXupload.php:68: Text2: <input type="text"
name="text2" value="<?echo $_REQUEST['empfaenger']?>"><br>
Binary file ./library/phpillow/tests/phpillow/data/image_gif.gif matches
Binary file
./library/phpillow/tests/phpillow/data/.svn/text-base/image_gif.gif.svn-base
matches
./library/ezcomponents/Mail/src/tools.php:225: $pattern =
'/<?"?[a-zA-Z0-9!#$%&'*+-/=?^_{\|}~\.]+\"?@[a-zA-Z0-9!#\$\%\&\'\*\+\-\/=\?\^_{|}~.]+>?$/';
./library/XXXX/SoapApi.php:1:<?
Binary file
./library/dompdf/lib/php-font-lib/sample-fonts/IntelClear-Light.ttf matches
Result:
2 false positives
3 results because "<?" seems to be in random binary files, and "php" is
in the file path. Better check would be:
grep -rin "<?[^pxi=]" . | grep ".php"
2 places found where "<?echo " should be replaced by "<?=" or "<?php "
2 results with a short open tag at the beginning of a file
BUT: That simple grep did only find a small fraction of the problems,
for example .phtml templates were not scanned. Continue reading...
php-cs-fixer with default settings produced a diff file with 3403 lines,
51 line changes:
php php-cs-fixer-v2.phar fix --rules=full_opening_tag --diff --dry-run .
result.txt
Reviewing these 51 changes took 3 minutes. No false positives here, all
of them were at the beginning of files.
BUT: it didn't search in .phtml files. php-cs-fixer by default only
processes .php and .phpt files (depending on the version you are using,
older versions also process .twig files as far as I can see). If you use
it, you may have to add other file extensions like .phtml, .tpl or
similar, depending on your project.
Running php-cs-fixer on .phtml files in that project results in a diff
file with 9527 lines, 1573 line changes just in the .phtml files of that
project. Whao...
I'm not sure if I'm alone, but I have lots of template code like this:
<div class="tableBody"> <? foreach ($this->Xdata as $index => $data) { ?> <div class="tableEntry <? if ($index%2 != 0) echo 'odd';?>">Something</div> <? } ?> </div>Blindly replacing "<? " by "<?php " results in this:
<div class="body"> <?php foreach ($this->Xdata as $index => $data) { ?> <div class="entry <?php if ($index%2 != 0) echo 'odd';?>">Something</div> <?php } ?> </div>The nice visual indenting of the "foreach" with 4 spaces is broken now,
and cannot be fixed, because "<?php " is 6 chars long...
Yes, minor problem of cause, but it looked nice before, and now looks
broken and "wrongly indented".
Some random thoughts:
- What happens to .phar files? Do we have to scan the contents?
- What happens to "executable php files"? They don't have a file
extension, but a shebang "#!/usr/bin/env php", and potentially
short-open-tags in it. - What happens if I miss to add a file extension to php-cs-fixer while
scanning and fixing code I'm not 100% familiar with? Code leak :-( - What happens if I upgrade a server to PHP8, but do not check all
folders and projects on it? - What happens if a Shared Hosting Provider increases the PHP version to
8 automatically for all its customers in the future? Does this happen in
the real world? Pages will not generate a 500 error, they will leak
code, with passwords in it...
Same with system administrators upgrading PHP to 8 without asking
code-owners/developers. Or migrating all projects blindly to a new
server with PHP8 installed. I guess that might happen. I guess, nobody
expects code leaks then...
Looks like a lot of work and problems for everybody... I didn't expect
the RFC to pass, thought that there are too many problems and lots of
work for no benefit :-( And I don't follow internals mailing list on a
daily basis, just check it "every few weeks for something important"...
In the past I was fine with BC breaks, for security, performance, or
similar. Even bigger ones (unable to detect like "Uniform Variablen
Syntax" for example). But this one looks heavy and dangerous for no
benefit...
At least the code leaks must not happen. A Fatal error is a lot better
than a code leak (and easier to find in the error log :-) )...
"Just use php-cs-fixer" sounds easy, but it's a lot more complex, see
problems and thoughts above.
Michael
unread
Hello Internal,
The two weeks of voting have now ended.
The results are 38 for and 18 against (total 56) for the primary vote to
deprecate PHP's short open tag in PHP 7.4.
This passes in favor with 68%.The results are 42 for and 15 against (total 57) for the secondary vote to
remove PHP's short open tag in PHP 8.
This passes in favor with 74%.Thanks for everyone who voted on this issue.
Best regards
George P. Banyard
Since this has passed, I would like to discuss official tool
recommendations when 7.4 and 8 are published. Because users are going
to want that.
sed-based solutions do NOT work. PHP is a complex language and it
requires using the tokenizer to properly replace short open tags. The
PHP-CS-Fixer FullOpeningTag fixer is also completely broken software -
it actually misses common use-cases and it intentionally damages code
and then attempts (and in some cases fails) to revert the damage in the
process. Neither of the two recommended options to date on this list
are valid recommendations for serious software deployment managers.
I also looked at a number of other tools that have popped up on my radar
and found nothing that met my basic criteria of:
- Total control over the transformation process, favoring analysis over
modification. - Zero regexes and relying solely on
token_get_all(). - Does exactly one thing and does it well in as little code as possible
so it can be easily vetted by others.
So I built a tool that meets the above minimum criteria and have already
run it against a fairly extensive codebase (and have shared the tool
with a few concerned folks - you've already seen its output here on-list):
https://github.com/cubiclesoft/php-short-open-tag-finder/
The included test suite (test.php), while a mere 14 lines, presents
suitably difficult scenarios to correctly handle both situations of
having (pre-PHP 8) and not having (post-PHP 8) short open tag support.
The tool correctly parses the test suite in both modes without using any
regexes.
The only downside to the tool is that the 'Y' key on a keyboard might
get broken in the optional '-ask' mode. I did experience a bit of
fatigue with using the tool to modify several thousand files with short
open tags but the transformation was otherwise flawless (i.e. no false
positives or false negatives) and was end-user transparent (i.e. didn't
break anything in production) other than having to go back and do
git-commits on all of the 70+ affected projects afterwards.
I recommend having a short list of vetted, verified tools that meet
specific criteria. Tools that just walk down a directory tree and bulk
modify by default, those that rely on regexes, and those that require
short tags to be enabled to function should all be rejected from
consideration. Recommended tools should also be able to be run by a
wide range of users, including hosting providers who might want to
inform their customers that use short open tags when they plan on
upgrading the host to PHP 8 that they have code on their website that
will probably break.
In summary, I went ahead and wrote a tool, ran it against 9.4 million
lines of real production code, then ran it in '-ask' mode and let it
carefully modify a few thousand files by mashing my 'Y' key a bunch of
times pausing briefly to look at interesting changes (which really only
took a couple of hours and probably lowered the lifespan of that key on
the keyboard a bit). I hope others can benefit from the tool too.
--
Thomas Hruska
CubicleSoft President
I've got great, time saving software that you will find useful.
And once you find my software useful:
unread
sed-based solutions do NOT work.
Neither of the two recommended options to date on this list are valid recommendations for serious software deployment managers.
I have no issue with suggesting tools to fix short opening tags, but lay off the absolute statements.
The approaches mentioned literally do work (because the people who mentioned them used them), they just may not work for your codebase.
unread
little fucker when i write you a private mail keep it private
And as we are on a public forum I will continue to reply to the forum
THAT is how my email client is set up and you can just piss off! It
pisses me off that I get multiple replies normally anyway ...
The fast majority of people who USE PHP would not even know if their
code had <? in or not and as with many BC breaks in the past if their
hosting switches versions in many cases one ends up with white screens.
Even where we are able to use the fancy fixes being used as examples of
'how easy it is to fix' ... this does not help users who would not even
know what a PHP file is :(
--
Lester Caine - G8HFL
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
unread
Le jeudi 25 avril 2019, 00:11:42 CEST Thomas Hruska a écrit :
So I built a tool that meets the above minimum criteria and have already
run it against a fairly extensive codebase (and have shared the tool
with a few concerned folks - you've already seen its output here on-list):
«// (C) 2019 CubicleSoft. All Rights Reserved.» does not meet my minimum criteria.
Tools that just walk down a directory tree and bulk
modify by default, […] should all be rejected from
consideration.
I do not understand why you have a problem with this, the rest of your email seems to suggest you are using git.
Just run the tool and then look at the diff before committing anything.
This makes way more sense than having to manually review each change one by one.
Côme
unread
sed-based solutions do NOT work.
Neither of the two recommended options to date on this list are valid recommendations for serious software deployment managers.I have no issue with suggesting tools to fix short opening tags, but lay off the absolute statements.
The approaches mentioned literally do work (because the people who mentioned them used them), they just may not work for your codebase.
Both the sed and PHP-CS-Fixer solutions recommended on this list would
have broken several of my production applications AND failed to provide
a complete conversion in the process. Hopefully that explains where my
statement came from. Apologies if I came on too strongly here.
I still think that software that works only on a subset of PHP code is a
recipe for disaster.
--
Thomas Hruska
CubicleSoft President
I've got great, time saving software that you will find useful.
And once you find my software useful:
unread
Le jeudi 25 avril 2019, 00:11:42 CEST Thomas Hruska a écrit :
So I built a tool that meets the above minimum criteria and have already
run it against a fairly extensive codebase (and have shared the tool
with a few concerned folks - you've already seen its output here on-list):«// (C) 2019 CubicleSoft. All Rights Reserved.» does not meet my minimum criteria.
From the README:
- Has a liberal open source license. MIT or LGPL, your choice.
Not sure what the problem is here.
Tools that just walk down a directory tree and bulk
modify by default, […] should all be rejected from
consideration.I do not understand why you have a problem with this, the rest of your email seems to suggest you are using git.
Just run the tool and then look at the diff before committing anything.This makes way more sense than having to manually review each change one by one.
I err on the side of caution for a variety of reasons that are off-topic
for this list/thread.
--
Thomas Hruska
CubicleSoft President
I've got great, time saving software that you will find useful.
And once you find my software useful:
unread
Hello Internal,
The two weeks of voting have now ended.
The results are 38 for and 18 against (total 56) for the primary vote to
deprecate PHP's short open tag in PHP 7.4.
This passes in favor with 68%.The results are 42 for and 15 against (total 57) for the secondary vote to
remove PHP's short open tag in PHP 8.
This passes in favor with 74%.Thanks for everyone who voted on this issue.
Best regards
George P. Banyard
By the way, has anyone thought about the GDPR impact of this change?
--
Thomas Hruska
CubicleSoft President
I've got great, time saving software that you will find useful.
And once you find my software useful:
unread
Hello Internal,
The two weeks of voting have now ended.
The results are 38 for and 18 against (total 56) for the primary vote to
deprecate PHP's short open tag in PHP 7.4.
This passes in favor with 68%.The results are 42 for and 15 against (total 57) for the secondary vote to
remove PHP's short open tag in PHP 8.
This passes in favor with 74%.Thanks for everyone who voted on this issue.
Best regards
George P. Banyard
The RFC doesn't mention to much details on the exact implementation of this
removal, but to avoid the potential security nightmare of <? code to
suddenly be printed to screens when people upgrade to 8.0 I would suggest
(props to Bob who mentioned this idea) that we at least keep the INI option
indefinitely and when set to On always cause a fatal error in RINIT with an
error message that mentions the security implications of disabling it and
potentially linking to a PHP documentation page that offers solutions on
how to migrate. This page could also be linked in the deprecation error
message in 7.4
unread
Also imo the reason why people write now (and not in the discussion
phase) because for some time in the voting there wasn't the 2/3 majority
for the 7.4 (so no sense to clutter the list) and now in the end only 1-2
votes make the difference.At least for me, this definitely was the case. When I voted, it was
nowhere near clearing the 2/3 threshold.
You must have voted on the same day the RFC went to voting.
As the next day when I had a chat with Derick for his podcast both votes
had cleared the 2/3 threshold, not with a big supra-majority but it cleared.
And it was above the threshold for the rest of the voting period everytime I
checked (so mas every two days).
So are we now going to need to do daily email during the vote to inform
what is the voting status of our RFC so everyone is in the loop? When
you can simply just check the RFC page or look at PHP RFC Watch? [1]
As I said numerous times in the past, I'm a firm believer that
controversial RFCs (ones that generate a lot of votes with a substantial
number of opposers) should not pass. I think this is important when adding
features - but it's actually a lot more important with deprecations. When
there's substantial doubt whether a deprecation should go through or not,
there should be no doubt at all - it shouldn't. This is one of the
clearest cases if not the clearest one we've had to date.
This IMHO applies to the deprecation vote which includes the default change
(and seems that is where people disagree as more people vote for the removal
without the deprecation notices which seems to point this is the issue)
which in hindsight is a stupid thing to do, but I would have loved that
people
point out to this specific issue (and the voting structure) during the
discussion
or even at the beginning of the vote.
But basing my self on the vote to remove the short open tags in PHP 8, which
cleared with 74% so nearly 3/4 it would need six (6) more "NO" votes
without any
"YES" votes to be on the 2/3 threshold. Whereas the deprecation votes "only"
needs two (2) votes to be on the 2/3 threshold.
So to my understanding of how the RFC process works there would need to be
at
least three (3) "NO" votes for the deprecation to fail (which I think we
can all agree
how I went about is crap and I'm open to changing how this gets implemented
as
seen on the other ML thread and the PR) and at least seven (7) "NO" votes
for the
removal vote.
Process wise we're in a bit of an unchartered territory here, but I don't
think we should let the headache involved with figuring out how to reverse
this decision force us to impose this on our users. It's better to go
through this unpleasantry now than deal with the backlash later.
I mean I don't see how we are in unchartered territory, the vote passed,
sure
with not a huge supra majority but it still passed.
Moreover going about how Twitter [2] reacted (which isn't necessarely a good
metric) it seems a vast majority is in favor of this change.
George, please consider reopening the vote for an extra week. That is
probably the simplest way to move forward from a process standpoint.Zeev
I can consider it but I am really not keen on it.
Because what prevent me from then re-openning the vote again if the vote
then fails?
What happens if the deprecation vote fails but not the removal?
Would this imply changing how it is deprecated which is literally the topic
of the
other thread without any more voting which I'm totally open to how it is
changed?
I don't even mind still having a compile error in PHP 8 when it sees the
token
as I said before I don't really care that much about the timeline.
Best regards
George P. Banyard
[1] https://php-rfc-watch.beberlei.de/
[2] https://twitter.com/nikita_ppv/status/1121040700156579840
unread
I don't even mind still having a compile error in PHP 8 when it sees the
token
I don't have a vote so these are just my 2 cents, but even though I'm all
for removing short open tags entirely, I think that this solution is
excellent for 2 reasons:
- it solves the code leak issue when upgrading blindly from PHP 7 to PHP 8,
and still makes short open tags effectively unusable on PHP 8; it can
therefore make everyone confident that they can then be removed in PHP 9,
as the odds of someone upgrading blindly from PHP 7 to PHP 9 are almost
nonexistent - it allows tools that automatically convert short open tags to standard
open tags to actually work on PHP 8. Because if I'm not mistaken, if these
tools are based ontoken_get_all()and "<?" is not recognized as a token
anymore in PHP 8, these tools would stop working on PHP 8.
Ben
unread
- it allows tools that automatically convert short open tags to standard
open tags to actually work on PHP 8. Because if I'm not mistaken, if these
tools are based ontoken_get_all()and "<?" is not recognized as a token
anymore in PHP 8, these tools would stop working on PHP 8.
It's very much possible to use token_get_all() with short open tag
support disabled and/or removed to convert from short open tags to full
open tags and, in fact, has already been done.
--
Thomas Hruska
CubicleSoft President
I've got great, time saving software that you will find useful.
And once you find my software useful:
unread
Hi!
I don't even mind still having a compile error in PHP 8 when it sees the
token
I thought one of the arguments for the whole enterprise was to enable
<?xml to pass through PHP? Isn't that what the RFC was claiming? So this
obviously won't work with this solution. And the "parser simplification"
claimed by RFC would also not happen, I imagine, since there's still two
separate tokens. So we are already out of at least half the reasons
original RFC has claimed...
Stas Malyshev
smalyshev@gmail.com
unread
As I said numerous times in the past, I'm a firm believer that
controversial RFCs (ones that generate a lot of votes with a substantial
number of opposers) should not pass. I think this is important when
adding
features - but it's actually a lot more important with deprecations.
When
there's substantial doubt whether a deprecation should go through or not,
there should be no doubt at all - it shouldn't. This is one of the
clearest cases if not the clearest one we've had to date.This IMHO applies to the deprecation vote which includes the default
changeFrom my POV it applies to all deprecations, although obviously taking out
something that's been a basic building block for the last 20+ years is
probably more of an issue than some 3rd party utility function.
I think this just boils down to what is an acceptable majority, if 2/3 is
not enough then 3/4
but this is another debate altogether.
(and seems that is where people disagree as more people vote for the removal
without the deprecation notices which seems to point this is the issue)
which in hindsight is a stupid thing to do, but I would have loved that
people
point out to this specific issue (and the voting structure) during the
discussion
or even at the beginning of the vote.But basing my self on the vote to remove the short open tags in PHP 8,
which
cleared with 74% so nearly 3/4 it would need six (6) more "NO" votes
without any
"YES" votes to be on the 2/3 threshold. Whereas the deprecation votes
"only"
needs two (2) votes to be on the 2/3 threshold.That's not how I understood the vote - although honestly, I found the vote
layout to be a bit weird.There are are two issues here:
- Secondary votes only kick in if the primary vote passes. They're also
defined as votes where you only need a simple majority for one of the
options.- The two questions are, in fact, one and the same. Removing a feature
in a major version requires that we first deprecate it in a mini version,
in other words - we can't remove something in 8.0 in case it's not first
deprecated in 7.4.I admit I found this confusing that the two votes were separate, but the
way I understood it, is that we may actually deprecate it at 7.4, without
actually removing it at 8.0, but just keeping it deprecated. The other way
around (removing it in 8.0 without first deprecating it in 7.x) is against
our rules.
This was indeed the intention of the voting structure as I wanted to have a
vote to get see
if people were filling to remove it with PHP 8 or leave it longer in the
Engine.
However looking at how some people voted against the deprecation notice but
for the removal
the only meaningfull conclusion I can come up with is that the change of
the default value is
the issue.
I mean I don't see how we are in unchartered territory, the vote passed,
sure
with not a huge supra majority but it still passed.We're in unchartered territory not from a process perspective, but in
terms of the number of core devs who think it's a really bad idea and the
fact we're rediculously close to the minimum threshold - for something that
should really happen with consensus.
I can see this but is it really unheard of?
Moreover going about how Twitter [2] reacted (which isn't necessarely a
good
metric) it seems a vast majority is in favor of this change.It is, indeed, not a very good or even meaningful metric at all. The
folks which are likely to care about this are almost definitely severely
under-represented both here and on the dev cycles on Twitter.
This may well be true but by the same argument I can say that a lot of
people are for this
even tho they didn't express this as much as those against it.
I can consider it but I am really not keen on it.
I'd sincrerely appreciate it if you did. I'm not fond of fighting
windmills, even less so nowadays than in the past - but I really think
we're making a painful mistake for virtually no gain, and I'm pretty sure
I'm not alone in thinking that. Ultimately, nothing in the RFC is new
compared to what we knew back in 1998 when we decided to have short open
tags. There are no new developments that make it more relevant today than
it was back then - if anything, XML is a lot less important today than it
was back then (when it was all the rage). And unlike 1998, the cost
assocaited with deprecating it now is tremendous. So even if we can argue
whether we took the right decision 20 years ago - there's really no new
grounds to reopen that decision today.
The problem is if we don't address it now it will be even more complicated
when
PHP 9 rolls around and then again. I still believe these short tags are a
legacy
oddity that should be removed.
Because what prevent me from then re-openning the vote again if the vote
then fails?
Nothing really, other than common courtesy.
I was even hoping that the RFC will be withdrawn given the number of nays
from core devs, but that's of course something that is up to you.
In all honesty I didn't check who votes for what as IMHO everybody is
entitled
to their opinion.
What happens if the deprecation vote fails but not the removal?
Would this imply changing how it is deprecated which is literally the
topic of the
other thread without any more voting which I'm totally open to how it is
changed?I don't even mind still having a compile error in PHP 8 when it sees the
token
as I said before I don't really care that much about the timeline.I think the real question this RFC raises is whether we want to deprecate
<?
There are several valid options:
- Do nothing (which probably gets my vote)
- Deprecate it in 7.4, and remove it in 8.0
- Deprecate it in 7.4, and error out over it in 8.0
- Deprecate it in 8.0, and figure out what we want to do with it as we
gear towards 9.0 (which would give us time to gauge the feedback before
taking decisions - something that won't really be possible with 7.4/8.0
given the short timelines)What I don't really think is a possibility is removing it (one way or
another) in 8.0 without first deprecating it in 7.4 (which again, is what I
found a bit confusing about the vote options).I would consider restructuring the questions in a different way than they
currently are and restart the vote:Primary Question - Deprecate short open tags yes/no (requires 2/3
majority)
Secondary Question - which version 7.4/8.0 (simple majority)
Secondary Question - what to do when we remove it - silent removal, error,
something else? (simple majority)Thanks,
Zeev
The problem I have with putting this again to a vote is that it feels
revote until the
outcomes is convenient to me. And going with this logic I feel I could say
let's
redo a vote to deprecate the var keywword as the last vote was 3 years ago
and maybe opinions have changed. It just end in more resentment IMHO.
On Sun, 28 Apr 2019 at 21:46, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
I don't even mind still having a compile error in PHP 8 when it sees the
tokenI thought one of the arguments for the whole enterprise was to enable
<?xml to pass through PHP? Isn't that what the RFC was claiming? So this
obviously won't work with this solution. And the "parser simplification"
claimed by RFC would also not happen, I imagine, since there's still two
separate tokens. So we are already out of at least half the reasons
original RFC has claimed...Stas Malyshev
smalyshev@gmail.com
Oh good to have you onboard for the initial RFC and remove it with PHP 8.
I suppose the discussion is closed then in this case. :)
Best regards
George P. Banyard
unread
Hello,
Hello Internals,
As there have been no further comments the voting for my RFC [1] to
deprecate PHP's
short open tags has started and will run for two (2) weeks.Best regards
George P. Banyard
I want to thank you for this RFC, for your time dedicated to it, for
the actual implementation and everything. You have done everything
correct and also the general idea i.e. removing these legacy tags in
either PHP 8.0 or not was completely correctly pointed out and RFC (at
least according to the current PHP RFC standards) met all the criteria
to get into implementation step. Everyone who is working with PHP
development knows that these short tags are not meant to be used
anymore. Also everything was correctly accepted and the numbers are
correct.
This entire thread is also showing the integrity, intelligence level
of the PHP a bit but one day maybe these legacy leftovers can be
removed, hopefully... Because they really should. So let's not give up
and let's find some normal solution here... RFC and results are quite
clear but maybe Nikita's solution is good enough for all:
- Deprecation warnings in PHP 7.4 (RFC criteria met, people here happy or not)
- PHP 8.0 complete compile error without any option to further use
them anymore (RFC criteria sort of met -!!!, and the reason of
pretending that the legacy apps will work ok on PHP 8.0 also met) - Actual removal in PHP 9 (because this is then the logical next
step). Removing something like this in PHP 8.1 is not following
semantic versioning at all. Either removal in 8.0 or 9.0.
Cheers and thanks.
--
Peter Kokot
unread
Also imo the reason why people write now (and not in the discussion
phase) because for some time in the voting there wasn't the 2/3 majority
for the 7.4 (so no sense to clutter the list) and now in the end only 1-2
votes make the difference.At least for me, this definitely was the case. When I voted, it was
nowhere near clearing the 2/3 threshold.As I said numerous times in the past, I'm a firm believer that
controversial RFCs (ones that generate a lot of votes with a substantial
number of opposers) should not pass. I think this is important when adding
features - but it's actually a lot more important with deprecations. When
there's substantial doubt whether a deprecation should go through or not,
there should be no doubt at all - it shouldn't. This is one of the
clearest cases if not the clearest one we've had to date.
Keep in mind that for example the FFI RFC passed with something like 60%
majority, even lower than this RFC. I think you're cherry-picking a bit
here, when it comes to what should and shouldn't pass ;)
Process wise we're in a bit of an unchartered territory here, but I don't
think we should let the headache involved with figuring out how to reverse
this decision force us to impose this on our users. It's better to go
through this unpleasantry now than deal with the backlash later.
I think that process-wise (if we can't agree on landing some variation of
this, as I've suggested in a separate thread) the right thing to do would
be to draft a new RFC that overrules this one. It can lay out the new
arguments that have come up in the meantime in an orderly manner and be
voted separately.
Nikita
unread
It's absolutely fine to dislike short tags. It's absolutely fine to
believe it shouldn't have been introduced. But the gap between that, and
thinking it's fine to remove it - is very, very big.
And how long after it's removed will '<?=' also get the chop?
--
Lester Caine - G8HFL
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
unread
If we go in this direction, though, then unless George agrees to withdraw
this RFC
Zeev,
I do not think you behaviour is appropriate.
It's not appropriate to put pressure on an RFC author to withdraw an
RFC after it has been voted on.
It's not appropriate to try to change the rules on voting after a vote
has occurred.
Please stop doing this.
We're in unchartered territory not from a process perspective, but in terms
of the number of core devs
I don't believe that is true* (there appear to be core devs on both
sides of the vote) but even if it was, this is not an internal engine
matter, where the decision is going to cause a significant amount of
work for people who work on PHP core. I strongly doubt this type of
RFC is ever going to be reserved for core developers choice only.
For the record I think the result of the vote is dumb, and I hope that
the situation will be resolved before the 7.4 release. And I also
agree that we should have clearer rules about who qualifies for a
vote.
But trying to subvert a vote after it has happened is not appropriate imo.
Nikita Popov has already started a new thread in an attempt to make
the situation be more acceptable. That is the correct way of resolving
problems like this.
Putting pressure on people to bend the rules is not.
cheers
Dan
Ack
- If you'd described it as release managers were all voting on one
side, then it would be true.
unread
On Mon, Apr 29, 2019 at 5:19 PM Dan Ackroyd Danack@basereality.com
wrote:Please stop doing this.
I will gladly do so, once the project starts behaving responsibly again.
Honnestly, this comment right here Zeev just makes me want to not
compromise at all.
I think you seriously lost any hope there was that I'm going to put back
this to a vote.
Why the hell should I start compromising with someone who thinks the
project, and by
extensions the contributors to the project small or large, don't behave
responsibly?!
You say that this deprecation is an insult to our legacy users but you just
casually
insult (at least in my mind) the people who make this project live on.
Or are you just remicinent of ye olden days where core devs decided willy
nilly what
ever they want to do with the project? Because I though the whole idea
behind the RFC
process is to prevent this "closed club" of core dev who can decide
whatever they want.
Also you go on about how 2/3 majority is to small when you self used even
lower margins
to get RFCs accepted. From what I know nothing prevented you to asked a 90%
acceptance
rate on all the RFCs that you proposed/co-authored if you felt that strong
about "consensus"
as the Voting process, to my understanding, only asks for minimums.
And if you think I'm being unreasonable here, well I'm not because my RFC
passed fair and
square while having a longer period then what was required at the time
(which funnily enough
you also love having small voting windows).
And do you think it would have been resonable of me to come complaining
about how my vote
failed if there would have only been 66% in favor instead of the 2/3? You
would have had no
problem then to say that it failed no more discussion needed instead of
draging this along for
about a week after the vote ended.
I was willing to compromise a lot but with all the respect I have for you
Zeev, your sheer arogance
just made any major compromise not a thing I want to pursue anymore.
I'll accept amendments to how the deprecation is handled and implemented
with any ideas that may
arise on the nikic's thread on how to handle it.
And if an RFC amendment is needed I will personaly only accept a vote on
HOW this RFC is implemented
and not a vote on IF this should be done.
And if you are not happy with this, blame yourself.
Best regards
George P. Banyard
unread
On Mon, Apr 29, 2019 at 5:19 PM Dan Ackroyd Danack@basereality.com
wrote:Please stop doing this.
I will gladly do so, once the project starts behaving responsibly again.
Honnestly, this comment right here Zeev just makes me want to not
compromise at all.
I think you seriously lost any hope there was that I'm going to put back
this to a vote.In retrospect, I should have waited for Dan's insulting message to wear off
before replying to it.The fact the RFC included a confusing secondary vote, that was defined
against our RFC rules and may have been misunderstood by folks who voted
(and consequently may have resulted in different outcomes) - is sufficient
grounds to disqualify this vote and require a restarted vote on a fixed RFC
(that can include the amendments you have in mind to make the 8.0 behavior
different from what the RFC proposed).Zeev
I read our voting rules, checked with a few people, and thought about
it for a while, and I still do not know what rule breakage you are
referring to. How did this supposedly break our voting rules? If you
want any support on disqualifying this RFC, you need to clearly state
the violation.
unread
I think this just boils down to what is an acceptable majority, if
2/3 is not enough then 3/4 but this is another debate altogether.I've argued in the past that it would make sense to require a 9/10 majority
for RFCs. Very few RFCs that passed - only cleared a 2/3 majority.
Usually (in the vast majority of cases), it either clears a nearly
unanimous vote - or it doesn't even come close to 2/3.RFCs that have a high number of votes (i.e., that people feel strongly
about), and barely pass the 2/3 mark - are controversial and saw division.
Yes, it means that out of the (almost random) group of people who are
currently enabled to vote by our (flawed) voting system
If you think it's flawed, you know that the RFC process is there for
anybody to change it. Joe already managed twice towards what you
suggested in your stalled RFC:
- https://wiki.php.net/rfc/abolish-short-votes
- https://wiki.php.net/rfc/abolish-narrow-margins (btw, you voted
against this one to raise the barrier from 50%+1 to ⅔rds).
It's absolutely fine to dislike short tags. It's absolutely fine to
believe it shouldn't have been introduced. But the gap between that,
and thinking it's fine to remove it - is very, very big.
But the fact is that the RFC passed. And retroactively changing rules
because somebody don't agree with a decision is making a farce out of
the process.
So what's next? From what I understood, Nikita and George have spoken to
take Nikita's implementation proposals forwards. I'm pretty sure that
this will result in another RFC on which we then can vote.
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
twitter: @derickr and @xdebug
unread
Hi Björn,
I did a quick check on two open source libraries that I'm using,
namely Smarty templating library and Revive ad server. A quick
glance at hand shows that they both uses the <? tag in their
latest release. Smarty 3.1.33 was released 17/9 2018 and
Revive 4.2.0 was released 23/4 2019.
I voted yes, even knowing that I'd have to do some extra OSS work.
Short open tags have been banned possibly 13 years ago in the project
coding standards, but there might still be some leftovers.
I'll make sure that will be corrected soon for Revive and its bundled
Smarty lib fork.
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
unread
Hi!
Why the hell should I start compromising with someone who thinks the
project, and by
extensions the contributors to the project small or large, don't behave
responsibly?!
Without getting into generalities about all contributors over all the
project lifetime, I personally think what happened with this RFC falls
short of the ideal RFC process as we'd like to see it happen in PHP. See
below on that. I don't think it's useful to assign personal blame for
anything here, but I think it may be useful to try and find the ways how
to improve.
You say that this deprecation is an insult to our legacy users but you just
casually
insult (at least in my mind) the people who make this project live on.
Or are you just remicinent of ye olden days where core devs decided willy
nilly what
ever they want to do with the project? Because I though the whole idea
behind the RFC
process is to prevent this "closed club" of core dev who can decide
whatever they want.
There are downsides to that. For example, people voting on RFCs without
actually realizing the full extent of what they are voting for. Like
voting for a change that will start dumping people's sources to the
internet once implemented - without even realizing that would happen. I
don't know, of course, how many of the people voting yes didn't realize
that and how many did but did not care - but the following discussion
shows that this definitely wasn't properly discussed because otherwise
there wouldn't be any point in discussing it anew. And the solutions
proposed so far negate at least half of proposed benefits from the RFC.
So I am thinking - was what happened a good example of a good working
process? Do we think the situation where we're talking about changing
the approach days after the vote is how RFCs should work?
I personally think that the fact that RFC was voted in without
considering a critical BC issue and without even acknowledging it in the
RFC shows we are way too hasty to introduce breaking changes and do not
spend enough thought on evaluating their effects on existing users.
It's very easy to ask people "do you hate short tags?" and get a
resounding "yes". If you asked "do you want any old code that might use
slightly older Smarty or some other not-recently-updated dependency
suddenly spill its guts to the internet starting with 7.4?", the "yes"
might be much less enthusiastic. But that question wasn't asked. And
asking that question - the right question - is our job here. Which, in
my opinion, in this case wasn't done properly - before voting on the
RFC. Good that at least we're doing it after.
I was willing to compromise a lot but with all the respect I have for you
Zeev, your sheer arogance
just made any major compromise not a thing I want to pursue anymore.
This phrasing looks suspiciously like you're basing your decisions in
the matter not on technical merits and concerns about PHP project and
its users, but on your personal grudges. I am certainly hoping this is
just because of an unartful turn of phrase and you want to rephrase that
in a way that does not give this impression.
--
Stas Malyshev
smalyshev@gmail.com
unread
On Sun, Apr 28, 2019 at 11:32 PM G. P. B. george.banyard@gmail.com
wrote:I think this just boils down to what is an acceptable majority, if
2/3 is not enough then 3/4 but this is another debate altogether.I've argued in the past that it would make sense to require a 9/10
majority
for RFCs. Very few RFCs that passed - only cleared a 2/3 majority.
Usually (in the vast majority of cases), it either clears a nearly
unanimous vote - or it doesn't even come close to 2/3.RFCs that have a high number of votes (i.e., that people feel strongly
about), and barely pass the 2/3 mark - are controversial and saw
division.
Yes, it means that out of the (almost random) group of people who are
currently enabled to vote by our (flawed) voting systemIf you think it's flawed
It's not that I think it's flawed - I know it's flawed. It doesn't
implement what was agreed upon when the Voting RFC was enacted.
, you know that the RFC process is there for
anybody to change it. Joe already managed twice towards what you
suggested in your stalled RFC:
- https://wiki.php.net/rfc/abolish-short-votes
- https://wiki.php.net/rfc/abolish-narrow-margins (btw, you voted
against this one to raise the barrier from 50%+1 to ⅔rds).
I'm well aware of it. In doing that, I think we greatly complicated the
prospects of fixing the voting eligibility - which is an infinitely hotter
potato to handle. Both 'abolish' RFCs enjoyed popular support and had very
little touchy subjects - unlike the topic of who gets to vote, or the
prospect of moving to a consensus-based system.
It's absolutely fine to dislike short tags. It's absolutely fine to
believe it shouldn't have been introduced. But the gap between that,
and thinking it's fine to remove it - is very, very big.But the fact is that the RFC passed. And retroactively changing rules
because somebody don't agree with a decision is making a farce out of
the process.
I've detailed the issues with the RFC in my other reply.
I'm well aware that I'm spending quite a bit of 'credit capital' by
weighing in on this, and I'm enjoying it roughly as one would enjoy having
their tooth pulled out without anesthesia (which still pales in comparison
to what it would take to fix our voting process, which will probably be
akin to having an entire set of teeth pull out in the same way). The
reason I'm still doing it is that it's clear this RFC was flawed in its
voting options, its substance, and the level of discussion that surrounded
it (the last one is my opinion, the first two are facts) - and it will have
HUGE implications on hundreds of thousands if not millions of users. So as
I said when I first engaged this thread - as much as I'm 'enjoying' this, I
prefer to take the personal hit and do whatever I can to prevent our users
from taking the hit.
If we are to inflict this hit on our users - we need to have each and every
t crossed and i dotted.
Zeev
unread
Hello,
a bit of fuzz; no need having a dramatic posture either; php RFC system
needs to be matured; the same way
than c++ fellowship (I don't say it was without dramas over the years); in
my opinion there are two many of them
opened at the same time; some targets strictly the userspace; some language
features and finally other regards
the zend engine (absolute on purpose); maybe they should not be discussed
on the same list.
tschüss!
On Sun, Apr 28, 2019 at 11:32 PM G. P. B. george.banyard@gmail.com
wrote:I think this just boils down to what is an acceptable majority, if
2/3 is not enough then 3/4 but this is another debate altogether.I've argued in the past that it would make sense to require a 9/10
majority
for RFCs. Very few RFCs that passed - only cleared a 2/3 majority.
Usually (in the vast majority of cases), it either clears a nearly
unanimous vote - or it doesn't even come close to 2/3.RFCs that have a high number of votes (i.e., that people feel strongly
about), and barely pass the 2/3 mark - are controversial and saw
division.
Yes, it means that out of the (almost random) group of people who are
currently enabled to vote by our (flawed) voting systemIf you think it's flawed
It's not that I think it's flawed - I know it's flawed. It doesn't
implement what was agreed upon when the Voting RFC was enacted., you know that the RFC process is there for
anybody to change it. Joe already managed twice towards what you
suggested in your stalled RFC:
- https://wiki.php.net/rfc/abolish-short-votes
- https://wiki.php.net/rfc/abolish-narrow-margins (btw, you voted
against this one to raise the barrier from 50%+1 to ⅔rds).I'm well aware of it. In doing that, I think we greatly complicated the
prospects of fixing the voting eligibility - which is an infinitely hotter
potato to handle. Both 'abolish' RFCs enjoyed popular support and had very
little touchy subjects - unlike the topic of who gets to vote, or the
prospect of moving to a consensus-based system.It's absolutely fine to dislike short tags. It's absolutely fine to
believe it shouldn't have been introduced. But the gap between that,
and thinking it's fine to remove it - is very, very big.But the fact is that the RFC passed. And retroactively changing rules
because somebody don't agree with a decision is making a farce out of
the process.I've detailed the issues with the RFC in my other reply.
I'm well aware that I'm spending quite a bit of 'credit capital' by
weighing in on this, and I'm enjoying it roughly as one would enjoy having
their tooth pulled out without anesthesia (which still pales in comparison
to what it would take to fix our voting process, which will probably be
akin to having an entire set of teeth pull out in the same way). The
reason I'm still doing it is that it's clear this RFC was flawed in its
voting options, its substance, and the level of discussion that surrounded
it (the last one is my opinion, the first two are facts) - and it will have
HUGE implications on hundreds of thousands if not millions of users. So as
I said when I first engaged this thread - as much as I'm 'enjoying' this, I
prefer to take the personal hit and do whatever I can to prevent our users
from taking the hit.If we are to inflict this hit on our users - we need to have each and every
t crossed and i dotted.Zeev
unread
Hello,
On Sun, Apr 28, 2019 at 11:32 PM G. P. B. george.banyard@gmail.com
wrote:I think this just boils down to what is an acceptable majority, if
2/3 is not enough then 3/4 but this is another debate altogether.I've argued in the past that it would make sense to require a 9/10
majority
for RFCs. Very few RFCs that passed - only cleared a 2/3 majority.
Usually (in the vast majority of cases), it either clears a nearly
unanimous vote - or it doesn't even come close to 2/3.RFCs that have a high number of votes (i.e., that people feel strongly
about), and barely pass the 2/3 mark - are controversial and saw
division.
Yes, it means that out of the (almost random) group of people who are
currently enabled to vote by our (flawed) voting systemIf you think it's flawed
It's not that I think it's flawed - I know it's flawed. It doesn't
implement what was agreed upon when the Voting RFC was enacted., you know that the RFC process is there for
anybody to change it. Joe already managed twice towards what you
suggested in your stalled RFC:
- https://wiki.php.net/rfc/abolish-short-votes
- https://wiki.php.net/rfc/abolish-narrow-margins (btw, you voted
against this one to raise the barrier from 50%+1 to ⅔rds).I'm well aware of it. In doing that, I think we greatly complicated the
prospects of fixing the voting eligibility - which is an infinitely hotter
potato to handle. Both 'abolish' RFCs enjoyed popular support and had very
little touchy subjects - unlike the topic of who gets to vote, or the
prospect of moving to a consensus-based system.It's absolutely fine to dislike short tags. It's absolutely fine to
believe it shouldn't have been introduced. But the gap between that,
and thinking it's fine to remove it - is very, very big.But the fact is that the RFC passed. And retroactively changing rules
because somebody don't agree with a decision is making a farce out of
the process.I've detailed the issues with the RFC in my other reply.
I'm well aware that I'm spending quite a bit of 'credit capital' by
weighing in on this, and I'm enjoying it roughly as one would enjoy having
their tooth pulled out without anesthesia (which still pales in comparison
to what it would take to fix our voting process, which will probably be
akin to having an entire set of teeth pull out in the same way). The
reason I'm still doing it is that it's clear this RFC was flawed in its
voting options, its substance, and the level of discussion that surrounded
it (the last one is my opinion, the first two are facts) - and it will have
HUGE implications on hundreds of thousands if not millions of users. So as
I said when I first engaged this thread - as much as I'm 'enjoying' this, I
prefer to take the personal hit and do whatever I can to prevent our users
from taking the hit.If we are to inflict this hit on our users - we need to have each and every
t crossed and i dotted.Zeev
Some languages out there have an idiom for this kind of a situation:
This thread right here is making an elephant out of the fly. Meaning
something is exaggerating or make something more serious than it
actually is.
Worth noting another inconsistency here that we've missed. PHP 7.4 has
introduced many BC breaks actually already. Without this level of
problems:
- *nix build system now uses pkg-config and basically has changed so
many configure options that building this is a completely new chapter
on its own - removed wddx
- removed interbase
- entire Backward Incompatible Changes section in the UPGRADING file:
https://github.com/php/php-src/blob/PHP-7.4/UPGRADING
The deprecation in PHP 7.4 (or even if there wouldn't be any
deprecation here at all) and removal of some short tags in PHP 8 is
the least of users problems I think.
If the next RFC on this topic would happen (in my opinion it is
pointless) it should make only something more clear. That is how to
remove them. In PHP 8.0 directly as is now the result of this RFC or
in PHP 9.0 removal and in PHP 8.0 using a compilation error. Anything
in between is a more or less a revert of the original RFC which would
then come to a question of why making these RFCs at all and why voting
even matters.
Without these kind of "hacks" PHP wouldn't even move forward anymore.
Contributing to it would be in most cases only maintenance, fixing
bugs and compatibility with platforms out there. So nothing exciting
anymore like making it more syntactically correct, more logical etc.
(these are very important changes also beside new functionality and
extensions).
--
Peter Kokot
unread
Some random thoughts:
- What happens to .phar files? Do we have to scan the contents?
Phar relies upon the engine's tokenizer. If your phar build script uses <?,
then you need an engine that supports <? to build your phar. If your phar
contains files that each use <?, you need an engine that supports <? to run
your phar.
$ cat create-test.phar.php
<?php
$phar = new Phar('test.phar');
$phar['index.php'] = '<? echo "I am a short tag" . PHP_EOL;';
$stub = $phar->createDefaultStub('index.php');
$phar->setStub($stub);
$ php -d phar.readonly=Off create-test.phar.php
$ php -d short_open_tag=On test.phar
I am a short tag
$ php -d short_open_tag=Off test.phar
<? echo "I am a short tag" . PHP_EOL;
This is the same problem library maintainers face: one can't distribute a
phar using <? anywhere and expect it to run everywhere. Since phar files
are far more portable than say a zip file of code - like being directly
runnable from the command line - engine compatibility is a primary concern
for phar distributors. Of course, if one wrote phar for controlled
distribution, then one might not have considered this angle. These are the
folks we need to worry about in this deprecation.
So, yes, any extant .phar files using <? need to be re-built with contents
using <?php. Note that means phar contents created by string need to be
manually checked for <? as well. Said another way, php-cs-fixer would not
fix my phar example from above, because <? is embedded in a string. The
grep+sed solution might work for that [1].
In my opinion, both as maintainer of the phar extension and a long-time
user of PHP, we need engine-enforced deprecation sooner rather than later.
We should also move toward outright removal at a prudent speed. But I would
caution that if long, long-time community members and lodestars are saying
"outright removal in 8.0 is too soon" then we should heed that. Once we
remove it, it's gone and there's no going back.
[1] A phar file scanner looking for instances of <? inside a phar could
also be written. I'd be willing to lead that development if there's
interest.
unread
Hi!
Worth noting another inconsistency here that we've missed. PHP 7.4 has
introduced many BC breaks actually already. Without this level of
problems:
Exactly, without. There's a difference between removing an unmaintained
extension which is barely used and setting people up for displaying
their sources if they use slightly outdated libraries. And there's a
difference between explicitly making a decision and not even bothering
to discuss this mammoth of a BC break until the vote is finished. So to
me it's more like "elephant in the room" scenario - we've got a process
failure here. We are on the course to correct it, but it's a failure
nevertheless.
The deprecation in PHP 7.4 (or even if there wouldn't be any
deprecation here at all) and removal of some short tags in PHP 8 is
the least of users problems I think.
You mean wddx removal is much bigger problem for users than the
potential for their code to be sent out instead of executed? If so, we
must be living in very different words, because for me the former is a
blip on the margin of the radar and the latter is a "world on fire, do
not upgrade under any circumstances" scenario. I could easily ignore the
former and I wouldn't dare to upgrade any production for the latter
without long process of verification that would 100% ensure there's no
bad tags hiding in any code, any dependency, any library, etc. Maybe
it's what the RFC authors want, but it's certainly a giant difference in
BC impact.
Without these kind of "hacks" PHP wouldn't even move forward anymore.
Contributing to it would be in most cases only maintenance, fixing
bugs and compatibility with platforms out there. So nothing exciting
There's a lot to do in PHP without breaking things. How much time you've
got?
Stas Malyshev
smalyshev@gmail.com
unread
Hi!
Worth noting another inconsistency here that we've missed. PHP 7.4 has
introduced many BC breaks actually already. Without this level of
problems:Exactly, without. There's a difference between removing an unmaintained
extension which is barely used and setting people up for displaying
their sources if they use slightly outdated libraries. And there's a
difference between explicitly making a decision and not even bothering
to discuss this mammoth of a BC break until the vote is finished. So to
me it's more like "elephant in the room" scenario - we've got a process
failure here. We are on the course to correct it, but it's a failure
nevertheless.
It is a BC break nevertheless no matter how much time it takes to
change the code. The level of the impact cannot be measured like this.
Every app will have different things to fix. So saying that this
particular change will break the internet is not realistic without any
numbers. If PHP is on a course to fix the BC break strategy then good
(for example, BC breaks allowed in major releases, minor releases
including only new features etc). Upgrading PHP version would be then
a breeze probably but very complex to maintain the code in the repo
(at least according to the release cycles of 5+ years to get to a
major version). However, I'm not sure I'm seeing such direction or
anyone expressing it to do this at least according to many here and
even this discussion. Because, from what I think here more is that
we're discussing how to keep the short tags forever and how to remove
them as soon as possible. There is a difference in what people want
here. And majority of those not in favour of the removal in PHP 8,
want them to have forever and basically want to change the issue of
removing the tags in the first place. I haven't seen any step forward
from this point yet and what kind of a different removal strategy
(compared to Nikita's suggestion) would work.
The deprecation in PHP 7.4 (or even if there wouldn't be any
deprecation here at all) and removal of some short tags in PHP 8 is
the least of users problems I think.You mean wddx removal is much bigger problem for users than the
potential for their code to be sent out instead of executed? If so, we
must be living in very different words, because for me the former is a
blip on the margin of the radar and the latter is a "world on fire, do
not upgrade under any circumstances" scenario. I could easily ignore the
former and I wouldn't dare to upgrade any production for the latter
without long process of verification that would 100% ensure there's no
bad tags hiding in any code, any dependency, any library, etc. Maybe
it's what the RFC authors want, but it's certainly a giant difference in
BC impact.
I haven't seen code with short tags for such a long time now that this
is for me a problem on a scale of a fly. Because we've simply upgraded
all very very long time ago or in other words even never thought of
writing something in these tags anymore. Well, obviously this might be
for someone else a problem on a scale of an elephant, that I don't
know and probably won't understand fully. But, also at least now this
discussion and also RFC brought this thing out - short open tags
shouldn't be used anymore in any case. :) Because obviously a very
large number of people would like to have more clear definition of
what is opening PHP tag.
--
Peter Kokot
unread
I haven't seen code with short tags for such a long time now that this
is for me a problem on a scale of a fly. Because we've simply upgraded
all very very long time ago or in other words even never thought of
writing something in these tags anymore.
I think it's important to remember that for every piece of actual code
that's seen in the wild on the internet, there's likely a couple of
orders of magnitude more that never leaves the proprietary servers /
repositories of individual companies -- Code that has been written over
a great many years that could always rely on short open tags being there
because it's company code on company servers running php.inis
configured by company staff.
The code exposure is secondary IMO. I mean, it's certainly bad, but
developers will be faced with a much more catastrophic issue to contend
with, and that's the somewhat terrifying issue of logical control
operations silently ceasing to exist.
<? if ($admin) { ?>
Super Secret: <?= htmlspecialchars($secret) ?>
<? } ?>
If people are so adamant about getting rid of it (as opposed to just
making it always available) then I think Nikita needs to bring forward
his proposals as an RFC with all due haste, as it's quite clear the
current plan cannot go forward as-is.
--
Mark Randall
unread
Hi!
Every app will have different things to fix. So saying that this
particular change will break the internet is not realistic without any
numbers. If PHP is on a course to fix the BC break strategy then good
I am not saying it will break the internet. Nobody does. What I am
saying it creates a huge and serious risk (both operational and
security) for people upgrading, and I am not sure why it is being
dismissed roughly as "well, BC happens, what you gonna do..." In my
opinion, it's not a kind of issue one should be dismissing. It's not a
regular low-grade BC break, it's a serious and dangerous one. Probably
one of the most dangerous - in its current state, as voted - among all
present in the release.
even this discussion. Because, from what I think here more is that
we're discussing how to keep the short tags forever and how to remove
them as soon as possible. There is a difference in what people want
I don't think dealing in absolutes here is helpful. There are more
options than "ASAP" and "never". And I feel that the RFC as-is have not
considered them thoroughly enough - otherwise I can not see how the
issue of spilling out the source has not been handled.
removing the tags in the first place. I haven't seen any step forward
from this point yet and what kind of a different removal strategy
(compared to Nikita's suggestion) would work.
Whatever removal strategy there is, it should not be "let's switch the
default in 7.4, remove the whole token completely in 8.0 and let people
that have <? in their code have it spilled out like groceries from a
torn paperbag".
I personally think that whatever meager benefit we get from the removal
at the end (?xml thing? ridiculously narrow use case. parser
simplification? by removing one tag out of dozens? minuscule. etc.) but
if there are so many people that hate it, well, we can go ahead and work
on removal. But not in the way that creates problems much worse than the
current state.
I haven't seen code with short tags for such a long time now that this
is for me a problem on a scale of a fly. Because we've simply upgraded
You must realize you haven't seen 99.999% of existing PHP code, and
that's probably if you look at a lot of code? Massive amounts of code
are not public. Massive amounts of code are using old library versions
and old dependencies, a lot of them not easily upgradable to latest
versions because the surrounding code is old too and newest versions
break it.
The fact that you personally haven't seen such code and it's not a
problem for you doesn't mean a lot if you purport to take
responsibility over the needs of millions of PHP users. Voting on RFC
should not be an expression of a personal opinion and only it, if it is
we have a grotesque situation where personal whims of barely 50 random
people decide things for millions. This can only work if each of these
people realizes the responsibility inherent in the decisions being taken
and considers the impact that their vote would have not only for their
personal needs, but for other users too.
know and probably won't understand fully. But, also at least now this
discussion and also RFC brought this thing out - short open tags
shouldn't be used anymore in any case. :) Because obviously a very
There's a very big distance from recommending not using short tags to
removing short tags from the parser. We've just voted for covering this
distance in two releases. I think this would be a costly mistake. There
are ways of doing it properly - Nikita's proposal could be one of them.
Stas Malyshev
smalyshev@gmail.com
unread
Hi,
Hi!
Every app will have different things to fix. So saying that this
particular change will break the internet is not realistic without any
numbers. If PHP is on a course to fix the BC break strategy then goodI am not saying it will break the internet. Nobody does. What I am
saying it creates a huge and serious risk (both operational and
security) for people upgrading, and I am not sure why it is being
dismissed roughly as "well, BC happens, what you gonna do..." In my
opinion, it's not a kind of issue one should be dismissing. It's not a
regular low-grade BC break, it's a serious and dangerous one. Probably
one of the most dangerous - in its current state, as voted - among all
present in the release.
Btw, the core can veto a rfc if it actually creates big troubles, just to
end a circular discussion.
I am not asking to do it, but this is an option if really all core
developers consider it very harmful.
best,
Pierre
unread
Evening internals,
I am not going to go into the details of every email which got sent in the
past two days as I am busy with Exam revision.
Main take away that I got from the previous emails:
-
No discussion:
It is indeed true that there hasn't been a lot (to not say none) of
discussion after the announcement but I hadn't gotten any reply after I
replied to the people who commented on it so, in my mind if there is no
more discussion I don't see why I should have waited longer to bring the
RFC to a vote. -
Voting structure:
If the voting structure was that confusion, sending a message to the ML
like Peter Cowburn (@salathe) did would have allowed me to stop the vote
fix the structure and bring it back to a vote.
Saying that it was confusion after the vote is ended is IMHO just a way to
not assume responsibility and get your way because the result doesn't
pleases you.
No I don't see the rationale that saying the removal vote isn't an
implementation detail because from my perspective it is.
Because if not wouldn't the secondary vote on the JIT [1] RFC also not be
an implementation detail in this case?
Even though you could say how it was presented it is not a secondary vote
but then you can also considered it as a primary vote, and having multiple
primary votes in an RFC is allowed per the Voting RFC [2].
And if even then this doesn't seem right just render void the secondary
vote, no need to render void the whole RFC as the primary vote does respect
the Voting RFC.
As to why these issues haven't been addressed during the standard RFC
process, I have a couple of theories but I don't think they are worth
putting on this list.
On this note, if I missed anything important please send it my way and I
will try to respond to it ASAP but it could well be another 2 days or more
before I respond.
Best regards
George P. Banyard
unread
Not trying to rush anyone to something they have no energy working on
anymore here but what's the plan here then? And what plan is there
with these short tags on the long run?
unread
Hello,
Not trying to rush anyone to something they have no energy working on
anymore here but what's the plan here then? And what plan is there
with these short tags on the long run?
I'm just checking then why is this RFC in the pending implementation
state if basically we're on a way to have the short opening tags in
PHP for ever... Maybe we should then enable them by default to have
the other way around situation of having both tags for few 10 years
and then ditch the long one if it's not going to be deprecated in PHP
7.4 and decided what to do with them?
https://wiki.php.net/rfc/deprecate_php_short_tags
--
Peter Kokot
unread
Hello,
Not trying to rush anyone to something they have no energy working on
anymore here but what's the plan here then? And what plan is there
with these short tags on the long run?I'm just checking then why is this RFC in the pending implementation
state if basically we're on a way to have the short opening tags in
PHP for ever... Maybe we should then enable them by default to have
the other way around situation of having both tags for few 10 years
and then ditch the long one if it's not going to be deprecated in PHP
7.4 and decided what to do with them?
Girgias has put up a new implementation at
https://github.com/php/php-src/pull/4263.
If short_open_tag=On and <? is used, a single deprecation warning is
thrown. short_open_tag=On remains the default, so there will be no
accidental code leakage due to changed defaults. If short_open_tag=Off,
then <? in the code are ignored as usual.
I believe that addresses the implementation concerns and we can go ahead
with landing this RFC.
Nikita
unread
Seems good to me.
Short tags have long presented a risk of code leakage and lack of portability, since they are dependent on an ini setting which not everyone has enabled.
Hopefully this can land in time for PHP 7.4.
From: Nikita Popov nikita.ppv@gmail.com
Sent: Monday, June 17, 2019 5:55 AM
To: Peter Kokot
Cc: Zeev Suraski; G. P. B.; Stanislav Malyshev; Derick Rethans; PHP Internals List
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
Hello,
Not trying to rush anyone to something they have no energy working on
anymore here but what's the plan here then? And what plan is there
with these short tags on the long run?I'm just checking then why is this RFC in the pending implementation
state if basically we're on a way to have the short opening tags in
PHP for ever... Maybe we should then enable them by default to have
the other way around situation of having both tags for few 10 years
and then ditch the long one if it's not going to be deprecated in PHP
7.4 and decided what to do with them?
Girgias has put up a new implementation at
https://github.com/php/php-src/pull/4263.
If short_open_tag=On and <? is used, a single deprecation warning is
thrown. short_open_tag=On remains the default, so there will be no
accidental code leakage due to changed defaults. If short_open_tag=Off,
then <? in the code are ignored as usual.
I believe that addresses the implementation concerns and we can go ahead
with landing this RFC.
Nikita