[wp-trac] [WordPress Trac] #47751: PHP 7.4 compatibility fix / accessing arrays/string using curly brace syntax

[WordPress Trac]

#47751: PHP 7.4 compatibility fix / accessing arrays/string using curly brace
syntax
-------------------------+-------------------------------------------------
 Reporter:  jrf          |      Owner:  (none)
     Type:  defect       |     Status:  new
  (bug)                  |
 Priority:  normal       |  Milestone:  5.3
Component:  General      |    Version:
 Severity:  normal       |   Keywords:  has-patch has-unit-tests 2nd-
  Focuses:  coding-      |  opinion
  standards              |
-------------------------+-------------------------------------------------
 PHP used to allow both square brackets and curly braces to be used
 interchangeably for accessing array elements and string offsets.

 {{{#!php
 <?php
 $array = [1, 2];
 echo $array[1]; // prints 2
 echo $array{1}; // also prints 2

 $string = "foo";
 echo $string[0]; // prints "f"
 echo $string{0}; // also prints "f"
 }}}

 The curly bracket syntax is only allowed in a limited set of cases and can
 be confusing for people not used to it.

 PHP 7.4 will now deprecate the curly brace syntax for accessing array
 elements and string offsets and it is expected that support will be
 completely removed in PHP 8.0.

 Ref: https://wiki.php.net/rfc/deprecate_curly_braces_array_access

 == The patches

 A recent Travis build against the current `trunk` already shows unit tests
 failing because of the deprecation errors being thrown on PHP 7.4: https
 ://travis-ci.com/WordPress/wordpress-develop/jobs/218044529

 The WordPress code-base containes 182 instances of curly brace array
 access.

 These 182 can be divided into issues in WP native files and in files from
 four external dependencies:
 ||        ||= # Files =||= # Issues =||
 ||= WP native files =||  4|| 11||
 ||= PemFTP =||  1|| 2||
 ||= POP3 =||  1|| 1||
 ||= Services_JSON =||  1|| 40||
 ||= getID3 =||  7|| 128||


 Similar to #47746, while the issues in external dependencies ''should'' be
 solved there, this may not be a feasible road.

 === PemFTP

 I have not been able to find references to the canonical location where
 this code is publicly maintained, nor has a search of typical source
 repositories yielded anything.

 The canonical URL mentioned in the file docblock points to
 [https://www.phpclasses.org/browse/file/6789.html PHPClasses] where the
 code hasn't been updated for over 10 years.

 With that in mind, I very much doubt there will be a ''new release'' any
 time soon.

 === POP3

 I have not been able to find references to the canonical location where
 this code is publicly maintained, nor has a search of typical source
 repositories yielded anything.

 Based on the file docblock, this external dependency hasn't been updated
 since 2011.

 If anyone can point me to where this code is maintained, please do.


 === Services_JSON

 I have not been able to find references to the canonical location where
 this code is publicly maintained, nor has a search of typical source
 repositories yielded anything.

 The canonical URL mentioned in the file docblock points to a proposal on
 [http://pear.php.net/pepr/pepr-proposal-show.php?id=198 PEAR] where the
 code hasn't been updated for over 14 years.

 As this essentially has been added to PHP core anyway, I doubt there will
 be a publicly maintained canonical version of this code.

 Related #47699

 === getID3

 Now, as for the worst offender... there is a public and actively
 maintained [https://github.com/JamesHeinrich/getID3 GitHub repo]
 available.

 My [https://github.com/JamesHeinrich/getID3/pull/194 pull request]
 containing the fixes for getID3 has already been merged.

 But...
 1. It is unclear when the next version will be released.
 2. WordPress currently includes version `1.9.14-201706111222` (June 2017),
 while the latest release is version `1.9.17`, released February this year
 and version `2.0` is already in `alpha`.

 So a decision would need to be taken about updating the dependency once
 the next version is released.


 == Conclusion

 Based on the above, I will be uploading patches for **''all''** instances
 of the issue, though I will split the patches based on the code origin.

 Like I've said in https://core.trac.wordpress.org/ticket/47746#comment:3 :

 > So, yes, while I agree that the fixes should primarily be made upstream,
 I don't think WP should be throwing deprecation notices when run on PHP
 7.4 while we are waiting for
 > 1) new releases from upstream and
 > 2) the existing WP Core versions of those libraries to be updated.

 A passing build on a branch containing all the patches can be found here:
 https://travis-ci.org/jrfnl/wordpress-develop/builds/561922102

 These patches should cover all instances of this issue in the current
 codebase.
 Based on the current `trunk` in combination with these patches, there are
 no remaining issues.

 == Other notes

 Should there be a guideline in the WordPress Coding Standards Handbook
 that ''curly braces for array access should not be used'' ?

 And if so, maybe now is the time to have another look at #46152, as the
 next version of [https://github.com/PHPCompatibility/PHPCompatibility
 PHPCompatibility] will contain a sniff to detect these issues.

 /cc @pento

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47751>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform