Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix PHP 8.4 compatibility / drop support for PHP < 7.1 #264

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jrfnl
Copy link
Contributor

@jrfnl jrfnl commented Sep 12, 2024

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.

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.
@jrfnl
Copy link
Contributor Author

jrfnl commented Sep 12, 2024

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.

Copy link

@jtojnar jtojnar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just encountered this in SimplePie test for mf2, fix looks good.

@gRegorLove
Copy link
Member

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.

@jrfnl
Copy link
Contributor Author

jrfnl commented Sep 30, 2024

Historically we've kept PHP5.6 support around longer due to WordPress' extended support for it.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants