The trunk of WordPress Core may stops CI of plugin developer by trigger_error: E_USER_DEPRECATED "The PSR-0 `Requests_...` class names in the Request library are deprecated."

[yshinoda]

When I run PHPUnit with current trunk version of WordPress Core, our PHPUnit failed due to Error with following error message:

Deprecated: The PSR-0 Requests_... class names in the Request library are deprecated.
Switch to the PSR-4 WpOrg\Requests\... class names at your earliest convenience.
in /usr/src/wordpress/wp-includes/Requests/src/Autoload.php on line 171.

This is caused when instantiate \Requests_Response class to mock WP_HTTP_Requests_Response in test case.

cf.

• Job #55.2 - yukihiko-shinoda/staticpress2019 - Travis CI ​https://app.travis-ci.com/github/yukihiko-shinoda/staticpress2019/jobs/591451062

I confirmed it by updatting arround line 171 of Autoload.php:

<?php
                                        trigger_error(
                                                'The PSR-0 `Requests_...` class names in the Request library are deprecated.'
                                                . ' Switch to the PSR-4 `WpOrg\Requests\...` class names at your earliest convenience.',
                                                E_USER_DEPRECATED
                                        );

🔽

<?php
                                        trigger_error(
                                                'The PSR-0 `Requests_...` class names in the Request library are deprecated.'
                                                . ' Switch to the PSR-4 `WpOrg\Requests\...` class names at your earliest convenience. ' . $class_name,
                                                E_USER_DEPRECATED
                                        );

This doesn't happen with WordPress 6.1.1 and lesser and I already ignored by using set_error_handler() with empty callback function, so, it's not so hurry for me.

I think that the class: Requests_Response is published to developer and instantiating it in PHPUnit is no ploblem:

• Requests_Response | Class | WordPress Developer Resources ​https://developer.wordpress.org/reference/classes/requests_response/

Therefore, I think that it should fix on the side of WordPress Core since this error occurs even if the case when plugin developers are testing, and their CI stops.

Plugin developers are using also trunk version in CI now:

• scaffold-command/plugin-travis.mustache at v2.0.18 · wp-cli/scaffold-command ​https://github.com/wp-cli/scaffold-command/blob/v2.0.18/templates/plugin-travis.mustache#L33
• scaffold-command/Scaffold_Command.php at v2.0.18 · wp-cli/scaffold-command ​https://github.com/wp-cli/scaffold-command/blob/v2.0.18/src/Scaffold_Command.php#L881

[BackuPs]

Same problem here after installing latest development version (6.2-alpha-55010)

[peterwilsoncc]

Trunk updated Requests to version 2.0 recently, see #54504.

As the code you link to is initilizing Requests directly using the Requests 1.x class names then these deprecation warnings are expected.

To avoid the deprecation warnings you'll need to switch to the new class structure of Requests 2.x or use the the wp_remote_* functions or the WP_Http class to interact with Requests. I suggest using the WordPress functions and classes.

[BackuPs]

Replying to peterwilsoncc:

Trunk updated Requests to version 2.0 recently, see #54504.

As the code you link to is initilizing Requests directly using the Requests 1.x class names then these deprecation warnings are expected.

To avoid the deprecation warnings you'll need to switch to the new class structure of Requests 2.x or use the the wp_remote_* functions or the WP_Http class to interact with Requests. I suggest using the WordPress functions and classes.

It would be nice to know which code (function) is calling it. Now it is a needle in a haystack. In my case it was the elementor plugin.

[BackuPs]

Woocommerce triggers the error also

Correction.. The error is thrown by latest woocommerce beta 7.30

<?php
-:array(4) { ["type"]=> int(16384) ["message"]=> string(158) "The PSR-0 `Requests_...` class names in the Request library are deprecated. Switch to the PSR-4 `WpOrg\Requests\...` class names at your earliest convenience." ["file"]=> string(65) "/var/docs/server.tst/public/wp-includes/Requests/src/Autoload.php" ["line"]=> int(171) }

[hellofromTonya]

Hello @yshinoda,

Welcome back to WordPress Core's Trac!

As @peterwilsoncc noted, the Requests library was updated to v2.0 in the 6.2 cycle. When testing against trunk and when 6.2 releases, plugin code needs to change to upgrade to the new version of Requests. How?

See this Dev Note ​https://make.wordpress.org/core/2023/03/08/requests-library-upgraded-to-2-0-5-in-wordpress-6-2/ for guidance.

I'll close this ticket as it's not a Core issue.

[afragen]

I just had a user of my Git Updater plugin report this.

​https://github.com/afragen/git-updater/issues/1036

I only use the wp_remote_*() functions and never directly use the Requests library.

[afragen]

This is very much an edge case where I save the result of wp_remote_head() to a transient and then get the transient. Since the return is a Requests object getting the object runs unserialize() which also tries to instantiate the object.

Moral of the story. Don't store class objects other that stdClass. Parse the response and store that.