[wp-trac] [WordPress Trac] #57341: `Error: Class "Requests" not found` in trunk

[WordPress Trac]

#57341: `Error: Class "Requests" not found` in trunk
--------------------------------+------------------------------
 Reporter:  bjorsch             |       Owner:  (none)
     Type:  defect (bug)        |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  HTTP API            |     Version:  trunk
 Severity:  normal              |  Resolution:
 Keywords:  needs-testing-info  |     Focuses:
--------------------------------+------------------------------

Comment (by jrf):

 Thanks for reporting this @bjorsch.

 As far as I can see, there are two parts to this issue, none of which are
 for Requests to solve.

 Primarily, this is an issue with your code, which needs to be updated for
 Requests 2.0.0 (and yes, this still needs a dev-note).

 To upgrade the code to Requests 2.0.0, it should be changed to:
 {{{#!php
 <?php

 function test_57341() {
         ?>
 <div style="border:10px solid red"><?php echo
 WpOrg\Requests\Requests::GET; ?></div>
         <?php
 }
 add_action( 'wp_head', 'test_57341' );
 }}}


 However, generally speaking, code referring to the "old" Requests classes
 should still continue to work. The BC-layer allows for that.

 Which brings us to the second part:

 In WP Core, the "old" `Requests` class is in `wp-includes/class-
 requests.php`, while in Requests itself, the class is in
 `library/Requests.php`.

 No surprise then that the Requests Autoloader cannot locate the class...

 To solve this, I'll leave two suggestions:
 1. Edit line 143  in the `wp-includes/Requests/src/Autoload.php` file to
 point to the `wp-includes/class-requests.php` file instead. Doing this
 will make future upgrades of Requests more difficult.
 2. Add a `require ABSPATH . WPINC . '/class-requests.php` to the bit at
 the top of the `wp-includes/class-wp-http.php` file which also requires
 and registers the Requests autoloader. Note: this **will** trigger a
 deprecation notice for loading a deprecated class, but that is intentional
 and correct.

 To be honest, I'm not even sure this _should_ be solved in Core. Plugins
 which want to continue to use the old class names can do so (and can
 manually include the `wp-includes/class-requests.php` file), but should
 expect deprecation notices (which can be silenced).

 Alternatively, they should update their code to embrace Requests 2.0.0.

 This is the same as what previously had to happen for plugins which
 referred ''directly'' to the external PHPMailer dependency, they have had
 to update their code as well as that class became namespaced a while back.
 This is no different.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57341#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform