Skip to content

Conversation

@arshidkv12
Copy link
Contributor

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

@LordSimal
Copy link
Contributor

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 setAccessible seems weird to me since this was needed in the past to access property states from an object even though they those props are not public (and no getter is present).
Guess we could also fix this by using anonymous classes and adding a getter.

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.

@arshidkv12
Copy link
Contributor Author

@arshidkv12
Copy link
Contributor Author

php5

@dereuromark
Copy link
Member

I also dont understand how setAccessable can be safely removed, when we also support older PHP versions (8.1+).
But it seems to not fail for those..
Apparently, rector also does it now for us, included in #18832
Fair enough.

@arshidkv12
Copy link
Contributor Author

The laminas/laminas-diactoros package requires PHP 8.1 or higher, so versions below 8.1 are not supported.

@dereuromark
Copy link
Member

Read my comment again :) it was always about 8.1+ but <8.5

@ADmad
Copy link
Member

ADmad commented Aug 18, 2025

I also dont understand how setAccessable can be safely removed, when we also support older PHP versions (8.1+).

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

@markstory
Copy link
Member

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.

@dereuromark
Copy link
Member

dereuromark commented Aug 18, 2025

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.

@ADmad
Copy link
Member

ADmad commented Aug 19, 2025

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.

@arshidkv12
Copy link
Contributor Author

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.

@LordSimal LordSimal mentioned this pull request Aug 19, 2025
->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()))
Copy link
Member

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You’re right.

Copy link
Contributor

@LordSimal LordSimal Aug 19, 2025

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.

Copy link
Member

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.

php/doc-en#4006

Copy link
Member

Choose a reason for hiding this comment

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

That makes more sense

Copy link
Member

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.

Copy link
Member

@dereuromark dereuromark Aug 19, 2025

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?

Copy link
Contributor Author

@arshidkv12 arshidkv12 Aug 19, 2025

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.

Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@arshidkv12
Copy link
Contributor Author

Fix XML-related warnings #18834

@dereuromark dereuromark added this to the 5.2.7 milestone Aug 19, 2025
Copy link
Member

@ADmad ADmad left a 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.

@dereuromark dereuromark added the needs squashing The pull request should be squashed before merging label Aug 19, 2025
@dereuromark
Copy link
Member

dereuromark commented Aug 19, 2025

Careful
PHPStan has this annoying behavior that it doesnt properly work across PHP versions.

$uri = $metadata['uri'];

This might fail for you locally, but for our CI we need the "old way" - you basically ignore the issue locally.

@arshidkv12
Copy link
Contributor Author

Careful PHPStan has this annoying behavior that it doesnt properly work across PHP versions.

$uri = $metadata['uri'];

This might fail for you locally, but for our CI we need the "old way" - you basically ignore the issue locally.

Ok

@ADmad
Copy link
Member

ADmad commented Aug 19, 2025

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

@ADmad ADmad merged commit 76efc9f into cakephp:5.x Aug 23, 2025
12 of 14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

deprecations needs squashing The pull request should be squashed before merging

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants