zf1-future
zf1-future copied to clipboard
Shardj
Checklist to confirm PHP 8.2 compatibility
Since PHP has a policy of avoid Breaking Changes in "minor" releases, the library should in theory be compatible with any PHP 8.x. In practice, each PHP release has a small number of breaking changes, which might require small adjustments. (Note that there will be a larger list of new Warnings and Deprecations, but fixing these is not essential to consider the library compatible.)
For PHP 8.2, the manual lists the following incompatible changes. Once we have checked all of them, it should be safe to consider the library "PHP 8.2 compatible".
- [x] DateTime::createFromImmutable() now has a tentative return type of static, previously it was DateTime.
- "Tentative return types" are a concept only introduced in PHP 8.1 (as a step towards a PHP 9.0 or later change); so this library won't care about them at all
- [x] DateTimeImmutable::createFromMutable() now has a tentative return type of static, previously it was DateTimeImmutable.
- As above
- [x] number symbols in relative date formats no longer accept multiple signs, e.g. +-2.
- Searching for "-+" and "+-" shows no relevant code. Seems very unlikely to be a problem.
- [x] ODBC and PDO_ODBC
- as far as I can see, the library doesn't directly support either of these extensions
- [x] glob() now returns an empty array if all paths are restricted by open_basedir. Previously it returned false.
- 9 uses of
glob(); most already assume the result is an array \Zend_Cache_Backend_File::_cleandoes explicitly check forfalse, but only to shortcut the function and avoid aforeachloop
- 9 uses of
- [x] FilesystemIterator::__construct(): prior to PHP 8.2.0, FilesystemIterator::SKIP_DOTS constant was always set and couldn't be disabled.
- No uses.
- [x] strtolower(), strtoupper(), stristr(), stripos(), strripos(), lcfirst(), ucfirst(), ucwords(), and str_ireplace() are no longer locale-sensitive.
- The library never sets the system locale; the only use of
setlocale()is to fetch the current setting (setlocale(LC_ALL, 0))
- The library never sets the system locale; the only use of
- [x] str_split() returns an empty array for an empty string now.
- There are a bunch of uses of this. There is a slim chance that one of them was accidentally relying on this behaviour.
- [x] ksort() and krsort() now do numeric string comparison under SORT_REGULAR using the standard PHP 8 rules now.
- This seems to be about comparing mixed lists of strings and numbers.
- There are a handful of uses of these functions in the library; it's unlikely any are affected, but we could look closely to be sure.
- [x] var_export() no longer omits the leading backslash for exported classes, i.e. these are now fully qualified.
- Non-debug uses are in
bin/classmap_generator.php,library/Zend/CodeGenerator/Php/Parameter.php,library/Zend/Serializer/Adapter/PhpCode.php, andlibrary/Zend/Config/Writer/Array.php - It's unlikely these will break with the extra backslash, but we could test each to be sure.
- Non-debug uses are in
- [x] GlobIterator now returns an empty array if all paths are restricted by open_basedir.
- No uses.
- [x] The following methods now enforce their signature: SplFileInfo::_bad_state_ex(); SplFileObject::getCsvControl(); SplFileObject::fflush(); SplFileObject::ftell(); SplFileObject::fgetc(); SplFileObject::fpassthru()
- Class is referenced in library/Zend/File/PhpClassFile.php and library/Zend/File/ClassFileLocator.php but no use of the affected methods
- [x] SplFileObject::hasChildren() now has a tentative return type of false, previously it was bool. SplFileObject::getChildren() now has a tentative return type of null, previously it was ?RecursiveIterator.
- No uses of SplFileObject.
None of the uses of var_export makes any assumption about the exact shape of the output, only that it's valid PHP. If anything, the change will improve them, by outputting code that could be executed correctly in a namespaced context.
None of the uses of ksort or krsort seem to be making any strong assumptions about the order of data, except in the case of some which are using only numeric keys anyway.
All items in the checklist appear to be verified as compatible:
var_export: ✅ksort/krsort: ✅glob(): Already correctly handles false inZend_Cache_Backend_Filesetlocale(): Mostly used for reading current settings, which is acceptable
Can we consider this officially PHP 8.2 compatible?
I'm about to do some migrations this summer, so I can give feedback afterwards. Basically we are talking here just about the project description change.
https://github.com/Shardj/zf1-future/actions/runs/14320283287/job/40135623330#step:7:1
Maybe that issue should be reviewed?
Hello, Do you have any news about PHP 8.2 compatibility? What potential issues should we expect?
Seems, like we haven't any troubles running current code on the 8.2. At least I got no complains so far, so I'm considering this more-less compatible with 8.2 (more-less, because we are not using all components ofc).
So I can probably mark this PHP 8.2 ready as soon, as next version is released.
