Fix PHP 8.4 compatibility / drop support for PHP < 7.1 #264
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
FYI: once this PR has been merged (providing it is accepted), I have a commit ready to turn on testing on PHP 8.2/8.3/8.4 in CI. |
jtojnar
approved these changes
Sep 29, 2024
|
Thanks for this PR! We're still discussing the best route forward. Historically we've kept PHP5.6 support around longer due to WordPress' extended support for it. We might work on some parsing updates, package one final release that supports PHP5.6, then move forward with 7.2+ only. |
@gRegorLove Much appreciated! Just so you know, WP has dropped support for PHP < 7.2 in WP 6.6 (released July 2024), so doesn't have to be a blocker anymore ;-) (at least for this version bump) |
PHP 8.4 deprecates implicitly nullable parameters, i.e. typed parameter with a `null` default value, which are not explicitly declared as nullable. Ref: https://wiki.php.net/rfc/deprecate-implicitly-nullable-types There are multiple ways to fix this, though most involve breaking changes: 1. Remove the type declaration and do in-method type validation. As this is not a `final` class, nor are these `final` or `private` methods, this would be a breaking change for any class extending the `Parser` class as parameter types are contra-variant, so this would cause a signature mismatch. 2. Remove the `null` default value. This, again, would be a breaking change and an even bigger one as it turns an optional parameter into a required one, so this wouldn't just have an impact on overloaded methods, but on all _calls_ to the methods too. 3. Declare the parameters as nullable. This would not cause a signature mismatch. This is the change with the least impact, although it does require PHP 7.1. If this is released as a next _minor_ though, the impact will be minimal as Composer can handle the version negotiations and will just install an older version for PHP 5.6/7.0. Also note that based on the Packagist stats, this version negotiation would rarely be needed as the users of this package hardly use PHP 5.6/7.0 anymore: https://packagist.org/packages/mf2/mf2/php-stats With this in mind, I'm proposing dropping support for PHP < 7.1 and fixing the PHP 8.4 deprecations by making the relevant parameters explicitly nullable. Includes updating CI and the PHPCS config.
|
Rebased without significant changes to get passed the merge conflict. |
jrfnl
force-pushed
the
feature/php-8.4-fix-implictly-nullable
branch
from
2589156 to
628ac31
Compare
Art4
approved these changes
Jun 28, 2025
jtojnar
added a commit
to jtojnar/php-mf2
that referenced
this pull request
Jun 28, 2025
PHP 8.4 deprecates implicitly nullable parameters, i.e. typed parameter with a `null` default value, which are not explicitly declared as nullable. See <https://wiki.php.net/rfc/deprecate-implicitly-nullable-types> This patch is a somewhat hacky alternative to <microformats#264> that fixes those warnings without breaking backwards compatibility or removing PHP < 7.1 support.
|
@gRegorLove If you are still unwilling to break PHP < 7.1, I prepared an alternative that works on full range of PHP versions. Though it is quite ugly and bypasses PHP ≥ 7.4’s contravariance checks. |
jtojnar
added a commit
to jtojnar/php-mf2
that referenced
this pull request
Jun 28, 2025
PHP 8.4 deprecates implicitly nullable parameters, i.e. typed parameter with a `null` default value, which are not explicitly declared as nullable. See <https://wiki.php.net/rfc/deprecate-implicitly-nullable-types> Ideally, we would just change the type hint `?DOMElement` but <https://wiki.php.net/rfc/nullable_types> was only introduced in PHP 7.1, while we still support PHP 5.6. This patch is a somewhat hacky alternative to <microformats#264> that fixes those warnings without breaking backwards compatibility or removing PHP < 7.1 support. We remove the offending formal arguments in favour of obtaining them with `func_get_arg()` and checking their type ourselves. The PHPDoc param annotations were updated to match the actual types of the now virtual arguments. The downside is that it removes PHP 7.4’s parameter contravariance checks (https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters) so future re-introduction of the formal arguments would be a BC break.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PHP 8.4 deprecates implicitly nullable parameters, i.e. typed parameter with a
nulldefault value, which are not explicitly declared as nullable.Ref: https://wiki.php.net/rfc/deprecate-implicitly-nullable-types
There are multiple ways to fix this, though most involve breaking changes:
As this is not a
finalclass, nor are thesefinalorprivatemethods, this would be a breaking change for any class extending theParserclass as parameter types are contra-variant, so this would cause a signature mismatch.nulldefault value.This, again, would be a breaking change and an even bigger one as it turns an optional parameter into a required one, so this wouldn't just have an impact on overloaded methods, but on all calls to the methods too.
This would not cause a signature mismatch.
This is the change with the least impact, although it does require PHP 7.1. If this is released as a next minor though, the impact will be minimal as Composer can handle the version negotiations and will just install an older version for PHP 5.6/7.0.
Also note that based on the Packagist stats, this version negotiation would rarely be needed as the users of this package hardly use PHP 5.6/7.0 anymore: https://packagist.org/packages/mf2/mf2/php-stats
With this in mind, I'm proposing dropping support for PHP < 7.1 and fixing the PHP 8.4 deprecations by making the relevant parameters explicitly nullable.
Includes updating CI and the PHPCS config.