-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Fix PHP 8.5 deprecations: replace SplObjectStorage::contains() and remove ReflectionProperty::setAccessible() #18831
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
Conversation
arshidkv12
commented
Aug 16, 2025
- Replaced all occurrences of SplObjectStorage::contains() with offsetExists() to fix deprecation warnings.
- Removed ReflectionProperty::setAccessible() calls in Debugger.php as they have no effect in PHP 8.5.
…move ReflectionProperty::setAccessible()
|
Thanks for the PR. As you can see certain dependencies of cakephp are not PPH 8.5 ready yet, therefore the CI won't get green until those dependencies release a new version, which support PHP 8.5. A PR for that lib is already present, but it will take time till it gets through and released. Especially the removal of I have not checked the PHP Doc related to those deprecations yet, but could you link to those deprecations? 😁 Makes it easier for us to validate what is being done here. |
|
I also dont understand how setAccessable can be safely removed, when we also support older PHP versions (8.1+). |
|
The |
|
Read my comment again :) it was always about 8.1+ but <8.5 |
It can be removed because the method is a no-op. Non public methods and properties can be accessed through reflection objects without having to explicitly make them accessible since PHP 8.1 |
|
Thanks for putting this together. I think we'll need to wait to merge it until some of our upstream dependencies are ready as I don't want to leave CI broken for that long. |
|
That said: We could already merge in the code changes (without CI changes) in a separate PR though, to have it released as "PHP 8.5" compatible code in the next 5.x release. |
|
I have updated the workflow config so that the testsuite runs on PHP 8.5. @arshidkv12 There are few more deprecations and other warnings which need to be addressed. |
Let me check and get back to you. |
| ->withHeader('Date', gmdate(DATE_RFC7231, time())) | ||
| ->withHeader('Last-Modified', gmdate(DATE_RFC7231, $modified)) | ||
| ->withHeader('Expires', gmdate(DATE_RFC7231, $expire)); | ||
| ->withHeader('Date', gmdate('D, d M Y H:i:s \G\M\T', time())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like replacing a constant with a hand-crafted format everywhere. If this truly no longer exists in PHP, should we consider adding it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You’re right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe something that can be added to chronos?
It seems PHP will remove all DATE_* constants so the best idea would be to define them ourselves.
@dereuromark this reminds me of the removed time related constants we had in core.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only SUNFUNCS_* constants are deprecated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes more sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, so the scope is a bit smaller:
The DATE_RFC7231 and DateTimeInterface::RFC7231 constants have been deprecated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For these headers
->withHeader('Last-Modified', ...)
etc, wouldnt it make more sense to use another future proof PHP constant and maybe also one that is more "ISO", those are headers after all, not some local datetime output.
$response = $response->withHeader('Date', (new DateTime('now', new DateTimeZone('UTC')))
->format(DateTimeInterface::ATOM));or is that not valid? and it has to be a non machine readable one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the suggestion!
For HTTP headers like Date and Last-Modified, the officially recommended format is RFC 7231 / RFC 1123, which is always in GMT (D, d M Y H:i:s GMT). While DateTimeInterface::ATOM is ISO 8601 and machine-readable, strict HTTP compliance expects the RFC format. We could define a constant or helper to make it future-proof and easier to reuse, while keeping it compliant with HTTP standards.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then I am confused why PHP would drop RFC constants..^^ Sometimes you gotto wonder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
Fix XML-related warnings #18834 |
ADmad
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The split packages phpstan failure will be fixed after next release.
|
Careful
This might fail for you locally, but for our CI we need the "old way" - you basically ignore the issue locally. |
Ok |
|
Please undo all the changes after the phpcs empty line fix, as I already stated earlier the split package phpstan fails will be automatically resolved after the next release (as the split packages repos are only updated when a release is made). |
