PHP 5.4 and Short Tags
One thing in particular is tripping people up: the short open tag. I’ve had a few questions on this so here’s the advice I am giving to clients and friends.
What Actually Changed
The short_open_tag configuration directive was removed, but the short echo syntax <?= is always available.
How To Upgrade Your Codebase
- If you have
<?=in your templates, leave it alone, those will still work - If you have short tags
<?in your code, including in any of your libraries, then you need to do a global find-and-replace and turn them all into<?php
If you have short tags somewhere in your codebase, you probably won’t get errors, you’ll just suddenly start seeing PHP code in your output as PHP doesn’t recognise the tag and therefore doesn’t evaluate the code! To find them, try searching for <? followed by a whitespace character.
Hopefully that helps; there are a few gotchas to getting upgraded from older versions (especially from PHP 5.2) but this particular gotcha really isn’t a problem and the instructions here should see you through.
Another annoying problem we’re grappling with while upgrading PHP for a Drupal 7 site is session handling. Authentication is breaking on some browsers across platforms because Drupal’s session creation method is silently failing to generate a session.
https://www.drupal.org/node/2385567 <– this link claims that PHP 5.6.5 fixes this bug, but we're experiencing it on PHP 5.6.7 :(
This is a note about it on php.net https://bugs.php.net/bug.php?id=68331
Thanks for sharing, hopefully that one gets sorted out pretty quickly!
The short_open_tag INI directive was not removed in PHP 5.4 and hasn’t been removed to this day, even the bleeding edge PHP 7.0.0alpha2 has this INI directive available.
What happened in PHP 5.4.0 was that the short echo syntax (<?=) was decoupled from short_open_tag, so that the short echo syntax is always available regardless of what short_open_tag was configured as.
That being said, the advice is (as it has always been) to not use the short opening tag (<?) in your code for the simple reason that the code will not function when short_open_tag is turned off.
The short_open_tag option hasn’t been removed, it still exists in PHP 7 (https://github.com/php/php-src/blob/master/php.ini-production#L202 and https://github.com/php/php-src/blob/7aa7627172c11979ec45c2db85f99182812ee59d/main/main.c#L514).
The only thing that changed is <?= works when short_open_tag is on/off. It's still perfectly acceptable to use <? if short_open_tag is set to 1/true/on.
A little note on finding those tags – they don’t necessarily need a whitespace following them. [code][/code] works too, ugly as it may seem. Use a regex with a negative lookahead to be certain to find them all, and be sure to include XML as an exlusion: [code]/<\?(?!php|=|xml)/[/code]
As for replacing them automatically, it's a bit trickier. Perhaps obviously, [code][/code] will throw a parse error, so you’ll want to throw a space character in the end of that replacement string IF it’s not already followed by a whitespace (wouldn’t want any of those silly old trailing spaces or double spaces, would we now). Probably there’s a clever regex to do all that in one go, but the easier thing to do might be to just make two passes of it:
[code]/ “<?php "
/ “<?php"[/code]
Finally… and my condolences to folks with large legacy codebases, but it should be said: review the replacements manually. There may very well be exceptions that shouldn't be replaced. I know Smarty used to try and match opening PHP tags (including short tags) in a lexer for whatever reason, although I can't find that in the current version. Maybe there's some obscure sanitisation function that checks for PHP tags. I've found several exceptions in that vein in legacy codebases when refactoring them, so just be on your guard for that sort of thing. If you use PhpStorm to refactor, keep an extra eye on anything on the section "Usage in string constants".