[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:
--------------------------------+------------------------------
Changes (by bjorsch):

 * keywords:  needs-testing-info has-patch has-unit-tests => needs-testing-
     info


Comment:

 Replying to [comment:3 jrf]:
 > 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).

 Unfortunately we can't easily do that while continuing to support
 WordPress 6.1. It was my understanding that this is what the BC layer is
 for. Sure, we could reinvent the BC layer in our own plugin, but why
 should we when core already has one?

 (For our plugins, we generally support the current WP release and one
 previous, so we'd drop 6.1 when 6.3 is released. I can't say what any
 other plugins might do, of course.)

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

 That matches what I found. 👍

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

 I thought of a third, a little after I originally filed this bug.

 3. Add a file at `wp-includes/Requests/library/Requests.php` where the
 existing Autoload code looks for it, which does the `require ABSPATH .
 WPINC . '/class-requests.php'` bit to load the file from where WordPress
 has it.

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

 I think it should. The deprecation notices are expected when using the BC
 layer, but a fatal is not.

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