CodeIgniter4
CodeIgniter4 copied to clipboard
Dev: PHP 8.4 support
PHP 8.4 requires CodeIgniter 4.6.0 or later.
References:
- https://wiki.php.net/todo/php84
- https://wiki.php.net/rfc/deprecations_php_8_4
- https://php.watch/versions/8.4
- #7850
TODO:
- [x] update docs
- #9138
- [x] add PHP 8.4 to GitHub Action PHPUnit testing
- #9137
- #9133
- [x] session.sid_length INI setting is deprecated
- https://wiki.php.net/rfc/deprecations_php_8_4#sessionsid_length_and_sessionsid_bits_per_character
- #9139
- #9135
- [x] Implicitly nullable parameter declarations deprecated
- https://php.watch/versions/8.4/implicitly-marking-parameter-type-nullable-deprecated
- #9140
- [x]
DateTime(Immutable)::createFromTimestamp()comaptibility- https://php.watch/versions/8.4/datetime-createFromTimestamp
- #9105
- #9134
- [x] CURL_HTTP_VERSION_3
- https://php.watch/articles/php-curl-http3
- #9145
- [ ] Dependent packages
- [ ] Psalm
- [ ] Faker
- [ ] vfsStream
- [ ] Kint
- [ ] Predis
- [ ] Update highest versions to
8.4in GitHub Action flows - [ ] Update Issue Template
- [ ] remove
--ignore-platform-req=phpin composer.json"post-autoload-dump"- See #9137
@codeigniter4/core-team How do we handle the Deprecations of session.sid_length and session.sid_bits_per_character? They are deprecated in PHP 8.4, but it still works in 8.x. So we can't replace the current code. https://github.com/codeigniter4/CodeIgniter4/blob/f2e560f90c88cc82964f7b5f44819bd47ee4f323/system/Session/Handlers/FileHandler.php#L315-L316
current defaults of a 32 character hexadecimal session ID.
Should I keep the regular expression for '[0-9a-f]' for compatibility?
Should I keep the regular expression for '[0-9a-f]' for compatibility?
In PHP9, yes. But in PHP 8.x, the INI settings still work, but the deprecation error makes CI4 stop executing.
The deprecation is geared towards security. Why not follow the new default of 32 chars length at 4bits? It would be a breaking change but I think the impact would be low.
@paulbalandan That is also a possibility. If we do so, do we introduce the breaking change to v4.5.x ?
I think we can introduce partial PHP 8.4 support in 4.5.x, then tackle this BC deprecation in 4.6. What do you think?
I agree with @paulbalandan - we should follow the default values. The possible impact on users will be negligible, and it will save us from complicating the code unnecessarily.
If we plan to release v4.6 right after/before PHP 8.4 (November 21), I would be in favor of adding these changes there.
What do you mean by "partial PHP 8.4 support in 4.5.x" ? Unless we address the session sid deprecations and Time::createFromTimestamp() method signature change, 4.5.x will not work on PHP 8.4.
If we don't support PHP 8.4 in 4.5.x, we don't need to introduce breaking changes for PHP 8.4. Then, we can make all breaking changes in v4.6.0 to make it compatible with PHP 8.4. This way is simple to develop.
And we have time, so I think we can release v4.6.0 right after PHP 8.4 release. But I don't know if it's okay that 4.5.x doesn't support PHP 8.4.
I would like to decide whether 4.5.x will support PHP 8.4 or not.
I would like to decide whether 4.5.x will support PHP 8.4 or not.
Personally, I have no problem with adding support for PHP 8.4 only in v4.6.
This seems like a pretty good opportunity to "force" an upgrade to the latest version of the framework.
This seems like a pretty good opportunity to "force" an upgrade to the latest version of the framework.
It might be a good idea.
I was thinking of silencing the deprecations in 4.5.x then fix them on 4.6, but in retrospect I think that's a band-aid solution. In this case, I support having PHP 8.4 on 4.6+.
Constant CURL_HTTP_VERSION_3 merged in PHP 8.4, will support?
Do I understand correctly? Need to fix exit; => exit();
https://wiki.php.net/rfc/exit-as-function
CI 4 contains the code:
https://github.com/search?q=repo%3Acodeigniter4%2FCodeIgniter4++exit%3B&type=code
@neznaika0 No. But replacing exit with exit() may be better.
These are ideas for future proposals that are not part of this RFC: Deprecate using exit without parentheses https://wiki.php.net/rfc/exit-as-function#future_scope
$ php -v
PHP 8.4.0-dev (cli) (built: Aug 5 2024 00:57:29) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.4.0-dev, Copyright (c) Zend Technologies
with Zend OPcache v8.4.0-dev, Copyright (c), by Zend Technologies
bash-3.2$ php -a
Interactive shell
php > exit;
php >
Problem 1
- Root composer.json requires codeigniter4/framework ^4.2.7 -> satisfiable by codeigniter4/framework[v4.2.7, ..., v4.5.5].
- codeigniter4/framework[v4.2.7, ..., v4.4.8] require laminas/laminas-escaper ^2.9 -> satisfiable by laminas/laminas-escaper[2.9.0, ..., 2.14.x-dev].
- codeigniter4/framework[v4.5.0, ..., v4.5.5] require laminas/laminas-escaper ^2.13 -> satisfiable by laminas/laminas-escaper[2.13.0, 2.13.x-dev, 2.14.x-dev].
- laminas/laminas-escaper[2.10.0, ..., 2.10.x-dev] require php ^7.4 || ~8.0.0 || ~8.1.0 -> your php version (8.4.0-dev) does not satisfy that requirement.
- laminas/laminas-escaper[2.11.0, ..., 2.12.x-dev] require php ^7.4 || ~8.0.0 || ~8.1.0 || ~8.2.0 -> your php version (8.4.0-dev) does not satisfy that requirement.
- laminas/laminas-escaper[2.13.0, ..., 2.14.x-dev] require php ~8.1.0 || ~8.2.0 || ~8.3.0 -> your php version (8.4.0-dev) does not satisfy that requirement.
- laminas/laminas-escaper[2.9.0, ..., 2.9.x-dev] require php ^7.3 || ~8.0.0 || ~8.1.0 -> your php version (8.4.0-dev) does not satisfy that requirement.
CodeIgniter 4 requires the laminas/laminas-escaper package, but this package does not currently support PHP 8.4. Specifically, PHP 8.4 compatibility is not yet available in the current stable release of laminas/laminas-escaper.
However, there is an open pull request on the Laminas repository—PR #56—which addresses this issue by adding PHP 8.4 support. Once this pull request is merged and a new release of the package is made, we will be able to use laminas/laminas-escaper with PHP 8.4.
Hello if you need a small fix. https://github.com/codeigniter4/CodeIgniter4/issues/9290