[RFC] [VOTE] Deprecate PHP's short open tags

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

Hello, On Wed, 24 Apr 2019 at 13:29, G. P. B. <george.banyard@gmail.com> wrote:

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.

On 4/24/2019 4:28 AM, G. P. B. wrote:

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.

On 4/24/2019 4:28 AM, G. P. B. wrote:

By the way, has anyone thought about the GDPR impact of this change?

On Wed, Apr 24, 2019 at 1:29 PM G. P. B. <george.banyard@gmail.com> wrote:

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