[PHP 8.4] Fixes for implicit nullability deprecation

[Ayesh]

Fixes all issues that emit deprecation notices on PHP 8.4 for implicit nullable parameter type declarations.

See:

• RFC
• PHP 8.4: Implicitly nullable parameter declarations deprecated

Q	A
Is bugfix?	✔️
New feature?	❌
Breaks BC?	❌
Fixed issues	N/A

[what-the-diff]

PR Summary

• More adaptable trigger method in components
  The trigger method in the component base framework can now accept either a specific defined event or a null event as its second parameter. This adds flexibility in case the event isn't defined yet.

• Flexible table interaction in ActiveQuery
  The method viaTable in our database active query now accepts either a specific callable function or a null callable as its third parameter. This makes it more adaptable to different code scenarios.

• Enhanced 'via' method functionality
  The via method in our active query interface and active relation trait can now handle either specific callable functions or null callable as its second parameter. This enhances functionality and improves versatility in relation to database queries.

• Improved email sending capabilities
  The send method in our base message and message interface can now utilize either a defined MailerInterface or a null MailerInterface as its first parameter. This provides better flexibility in case the mailer interface is not defined.

• Adaptable action injection in test environment
  The actionInjection method for both our test controllers (FakePhp71Controller and FakePhp71Controller) can now receive either a defined Post or a null Post as its fifth parameter. This contributes to a more adaptable testing environment.

• Optional Dependencies testing adjustments
  Our testOptionalDependencies method now accepts either a QuxInterface or a null QuxInterface as its first parameter. This provides improved capabilities for testing optional dependencies within the software.

• Increased flexibility in constructors and methods in testing stubs
  Several constructors and methods (actionAksi1 and actionStringy) within our testing environment can now receive either a specific type or a null type. These changes mean our tests can simulate a more diverse range of scenarios, contributing to robust software development.

[samdark]

Thanks for contributing. Is that a backwards compatibility break for the case of inheritance?

[Ayesh]

Hi @samdark , thanks for the response.

Both string $v = null and ?string $v = null are considered "nullable" for inheritance, so yes, this is not a BC break.

However I just realized Yii also has to support PHP 5.4 through 7.0 as well, which have no nullable type support, so this change is breaking on those versions.

[Ayesh]

I will close this PR because we can not merge this as-is unless we either bump the minimum version to 7.1 (or drop these type declaration).

[samdark]

You can target the pull request for 2.2 branch which is PHP8+

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 65.62%. Comparing base (9578380) to head (b732b53).

Additional details and impacted files

@@            Coverage Diff            @@
##                2.2   #20128   +/-   ##
=========================================
  Coverage     65.62%   65.62%           
  Complexity    11213    11213           
=========================================
  Files           424      424           
  Lines         36681    36681           
=========================================
  Hits          24073    24073           
  Misses        12608    12608           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Ayesh]

Thank you! I rebased for 2.2.

[rob006]

@samdark AFAIK we had plans to increase min PHP version in v2.0.50 to 7.3. Something changed in that matter? If not, we could still merge this PR to master.

[samdark]

Won't this be a BC break anyway because of signature mismatch?

[Ayesh]

Quite fortunately it's not a BC break. If there any sub classes extending our classes, they will need the nullability fix to avoid the deprecation, but they will still be compatible.

[rob006]

https://3v4l.org/i7dQn#v7.3.33

[samdark]

Could go into master then. @Ayesh sorry to ask but could you rebase it back? :)

[Ayesh]

No problemo, I opened #20133 separately targeting master branch. It will fail because it still builds on PHP <= 7.0, but contains all places I found to trigger the deprecation notice.

[samdark]

Closing since it will be merged from master into 2.2.