Deprecated errors on PHP 8.1

[okvee]

Many errors on PHP 8.1 with WordPress 5.9-beta3-52394

On wp-login.php page

Deprecated: preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in wp-includes\formatting.php on line 5368

Deprecated: trim(): Passing null to parameter #1 ($string) of type string is deprecated in wp-includes\pluggable.php on line 592

On admin dashboard page

Deprecated: Return type of Requests_Cookie_Jar::offsetExists($key) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in wp-includes\Requests\Cookie\Jar.php on line 63

Deprecated: Return type of Requests_Cookie_Jar::offsetGet($key) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in wp-includes\Requests\Cookie\Jar.php on line 73

Deprecated: Return type of Requests_Cookie_Jar::offsetSet($key, $value) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in wp-includes\Requests\Cookie\Jar.php on line 89

Deprecated: Return type of Requests_Cookie_Jar::offsetUnset($key) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in wp-includes\Requests\Cookie\Jar.php on line 102

Deprecated: Return type of Requests_Cookie_Jar::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in wp-includes\Requests\Cookie\Jar.php on line 111

Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetExists($key) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in wp-includes\Requests\Utility\CaseInsensitiveDictionary.php on line 40

Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetGet($key) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in wp-includes\Requests\Utility\CaseInsensitiveDictionary.php on line 51

Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetSet($key, $value) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in wp-includes\Requests\Utility\CaseInsensitiveDictionary.php on line 68

Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetUnset($key) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in wp-includes\Requests\Utility\CaseInsensitiveDictionary.php on line 82

Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in wp-includes\Requests\Utility\CaseInsensitiveDictionary.php on line 91

Deprecated: rtrim(): Passing null to parameter #1 ($string) of type string is deprecated in wp-includes\formatting.php on line 2756

[TobiasBg]

This brings up https://core.trac.wordpress.org/ticket/54504#comment:29 again.
@jrf and @schlessera, as you are heavily involved with Requests, I believe, what do you think?

[jrf]

There are a couple of points I'd like to make here:

1. These notices you are seeing are NOT errors. They are deprecations, i.e advanced warning that something will change in a future version of PHP. As things are, everything is still working as expected and, while you may see these notices during development when running with WP_DEBUG turned on, the functionality of PHP has not changed (yet) and everything will still work as expected, especially in a production environment where WP_DEBUG should always be turned off.
2. Regarding the comment @TobiasBg is referring to: porting all PHP 8.1 fixes from Requests 2.0 to WP 5.9 with Requests 1.8.1 is not an option. While the fixes for the "missing return types" notices could be backported, most other fixes cannot be backported as they require the use of new classes which were only introduced in Requests 2.0.0.

The short of it is, none of these issues are things we aren't aware of yet, or things which would impact production sites, so let's not create a panic over nothing.

For now, I'm closing this ticket as a duplicate of #53635.

[TobiasBg]

Thanks for the clarification, @jrf!

I wasn't meaning to create panic or anything, just wasn't sure how many changes in Requests 2.0.0 actually were PHP 8.0/8.1 related (it could have been a few to-be-cherry-picked commits only). If it's more work than gain (I agree that deprecation notices don't need immediate fixing), let's indeed leave this for when Requests 2.0.0 can be merged.

[hyperpolymath]

Thanks - I see the point about them not being plugin specific, and I agree it is php8.1 but does the error not suggest in this that these are just instantly fixed in the plugin (if only temporarily) by a compatibility fix with the formatting of the call the plugin is making to get the data from WP in the wp-includes directory. Each line seems to be just asking for it to be appropriately made, so far as I can see, with a qualifier of void, mixed or bool as appropriate to the call, rather than what I am assuming is an unspecified call from the plugin. Although, I will admit, php is not my programming language and I am new to wp, so I might be misreading what is showing here.

If it is not as simple, that's fine, but do I need to do anything to mitigate a known or obvious threat, or is using the plugin in the interim fine?

thank you,

Jonathan

[jrf]

Replying to hyperpolymath:

Thanks - I see the point about them not being plugin specific, and I agree it is php8.1 but does the error not suggest in this that these are just instantly fixed in the plugin (if only temporarily) by a compatibility fix with the formatting of the call the plugin is making to get the data from WP in the wp-includes directory. Each line seems to be just asking for it to be appropriately made, so far as I can see, with a qualifier of void, mixed or bool as appropriate to the call, rather than what I am assuming is an unspecified call from the plugin. Although, I will admit, php is not my programming language and I am new to wp, so I might be misreading what is showing here.

If it is not as simple, that's fine, but do I need to do anything to mitigate a known or obvious threat, or is using the plugin in the interim fine?

@hyperpolymath You seem to be talking about something different than the above as you refer multiple times to "the plugin". Trac is not for plugin support or plugin bug fixes. Trac is for WordPress Core, so I suggest you ask your questions about whatever plugin you're talking about in the support forum of the plugin.

And just so you know: no, these shouldn't be fixed by type casting at the point of deprecation. In most cases, the function call passing the incorrectly typed data should be fixed, not the function receiving the data. This involves backtraces and figuring out where exactly the incorrect function call (or calls) is being made.

[hyperpolymath]

thanks that clarifies the situation, and is really useful as I was a bit confused about why I was sent here, but makes more sense now. And yes, of course that makes sense re the calls, although what is called and is sent are inherently linked and both sides have a role and decision as to what happens there. If the issue is that data is stored badly, but you are careful about the query it should be possible to extract it. That, of course, does not fix the way it is stored, but that is out of your control, and I agree. And, of course, much better that it is fixed where it originates rather than passing that off outwards.

I presumed that in any case, these decisions are made in some kind of negotiation in a developers community for plugin developers anyway, but I am not experienced with or familiar with how this works her. If plugins report errors as if they are with your plug in, then it does them no favours in themselves, but also if people put out that is where a problem seems to have occurred, and some breach or problem happens, the reputational hit can end up unfairly shared.

Anyway, I hope it was useful highlighting it, and if not, my apologies.