composer - Debugging deprecatedrenamed PSR-0 classes being requested

admin管理员组

文章数量:1125062

After upgrading to 6.2 via WP-CLI I get an error regarding deprecated/renamed PSR-0 classes being requested.

The source comment from WP core says:

          /*
           * Integrators who cannot yet upgrade to the PSR-4 class names can silence deprecations
           * by defining a `REQUESTS_SILENCE_PSR0_DEPRECATIONS` constant and setting it to `true`.
           * The constant needs to be defined before the first deprecated class is requested
           * via this autoloader.
           */

.php#L161

How to upgrade to the PSR-4 class names?

Asked differently, could it be a script autoloaded before WordPress via PSR-0?

After upgrading to 6.2 via WP-CLI I get an error regarding deprecated/renamed PSR-0 classes being requested.

The source comment from WP core says:

          /*
           * Integrators who cannot yet upgrade to the PSR-4 class names can silence deprecations
           * by defining a `REQUESTS_SILENCE_PSR0_DEPRECATIONS` constant and setting it to `true`.
           * The constant needs to be defined before the first deprecated class is requested
           * via this autoloader.
           */

https://github.com/WordPress/WordPress/blob/7714010f60a55633bd0ee5c5a0843ef7a4a7f756/wp-includes/Requests/src/Autoload.php#L161

How to upgrade to the PSR-4 class names?

Asked differently, could it be a script autoloaded before WordPress via PSR-0?

• composer
• autoloading

Share Improve this question edited Mar 31, 2023 at 8:46 RafaSashi asked Mar 31, 2023 at 8:40 RafaSashiRafaSashi 50711 gold badge77 silver badges1717 bronze badges 0

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 2

This is covered in the WP 6.2 Field guide post, and in the post about the upgrade of the requests library that you found the deprecation warning in.

If your plugin or theme uses Requests directly and supports a wider range of WordPress versions, you may need to conditionally declare the REQUESTS_SILENCE_PSR0_DEPRECATIONS constant as true to silence deprecation notices about the old PSR-0 class names. You should upgrade your code as soon as WordPress 6.2 becomes the minimum WordPress version for your plugin or theme.

If your code uses the WP_HTTP APIs then no changes are needed, this only affects code that directly uses the raw Requests API.

For fixing it:

If your plugin or theme uses Requests directly, and only supports the latest version of WordPress, you should update your code to use the namespaced names. For example, to perform a request with a try-catch using the namespaced names:

// Old: Perform a request with a try-catch in Requests 1.x.
try {
    $response = Requests::request( $url, $headers, $data, $type, $options );
} catch ( Requests_Exception $e ) {
    return new WP_Error( 'http_request_failed', $e->getMessage() );
}
 
// New: Perform a request with a try-catch in Requests 2.x.
try {
    $response = WpOrg\Requests\Requests::request( $url, $headers, $data, $type, $options );
} catch ( WpOrg\Requests\Exception $e ) {
    return new WP_Error( 'http_request_failed', $e->getMessage() );
}

The most compatible way to fix this, and prevent it ever happening again, is to use the WP_HTTP API and WP functions such as wp_remote_post etc

本文标签： composerDebugging deprecatedrenamed PSR0 classes being requested