Dev: PHP 8.4 support

[kenjis]

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
• Dev: PHP 8.3 support #7850

TODO:

• update docs
  • [4.6] docs: add note about PHP versions supported by CI4 versions #9138
• add PHP 8.4 to GitHub Action PHPUnit testing
  • [4.6] chore: add PHP 8.4 to test-phpunit.yml #9137
  • chore: add PHP 8.4 to test-phpunit.yml #9133
• session.sid_length INI setting is deprecated
  • https://wiki.php.net/rfc/deprecations_php_8_4#sessionsid_length_and_sessionsid_bits_per_character
  • [4.6] feat: force PHP default 32 chars length at 4 bits to Session ID #9139
  • feat: add deprecation error handling for session.sid_length and session.sid_bits_per_character for PHP 8.4 #9135
• Implicitly nullable parameter declarations deprecated
  • https://php.watch/versions/8.4/implicitly-marking-parameter-type-nullable-deprecated
  • [4.6] feat: workaround for implicit nullable deprecations in PHP 8.4 #9140
• DateTime(Immutable)::createFromTimestamp() comaptibility
  • https://php.watch/versions/8.4/datetime-createFromTimestamp
  • [4.6] fix: Time::createFromTimestamp() change for PHP 8.4 #9105
  • fix: TimeTrait::createFromTimestamp() method signature for PHP 8.4 #9134
• CURL_HTTP_VERSION_3
  • https://php.watch/articles/php-curl-http3
  • feat: support CURL HTTP3 #9145
• Dependent packages (feat: full support on PHP8.4 #9255)
  • Psalm (Add support for PHP 8.4 vimeo/psalm#10928)
  • PHP-CS-Fixer (feat: Initial support for PHP 8.4 PHP-CS-Fixer/PHP-CS-Fixer#8300)
  • Faker (PHP 8.4 Support FakerPHP/Faker#904)
  • vfsStream (Fix PHP 8.4 deprecate-implicitly-nullable-types bovigo/vfsStream#290)
  • Kint (chore: update Kint to v6.0 #9289)
  • Predis (explicitly mark nullable parameters as nullable predis/predis#1448)
• Update highest versions to 8.4 in GitHub Action flows
• Update Issue Template
  • See chore: add PHP 8.4 to issue template #9353
• remove --ignore-platform-req=php in composer.json "post-autoload-dump"
  • See [4.6] chore: add PHP 8.4 to test-phpunit.yml #9137

[kenjis]

@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.

CodeIgniter4/system/Session/Handlers/FileHandler.php

Lines 315 to 316 in f2e560f

	$bitsPerCharacter = (int) ini_get('session.sid_bits_per_character');
	$SIDLength = (int) ini_get('session.sid_length');

[neznaika0]

current defaults of a 32 character hexadecimal session ID.

Should I keep the regular expression for '[0-9a-f]' for compatibility?

[kenjis]

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.

So I sent #9135 feat: add deprecation error handling for session.sid_length and session.sid_bits_per_character for PHP 8.4.

[paulbalandan]

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.

[kenjis]

@paulbalandan That is also a possibility.
If we do so, do we introduce the breaking change to v4.5.x ?

[paulbalandan]

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?

[michalsn]

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.

[kenjis]

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.

[michalsn]

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.

[kenjis]

This seems like a pretty good opportunity to "force" an upgrade to the latest version of the framework.

It might be a good idea.

[paulbalandan]

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+.