[wp-trac] [WordPress Trac] #54504: Update Requests library to version 2.0.0

WordPress Trac noreply at wordpress.org
Tue Dec 7 00:51:29 UTC 2021

#54504: Update Requests library to version 2.0.0
 Reporter:  jrf                                  |       Owner:
                                                 |  SergeyBiryukov
     Type:  task (blessed)                       |      Status:  reopened
 Priority:  normal                               |   Milestone:  6.0
Component:  External Libraries                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  php80 php81 has-patch has-unit-      |     Focuses:
  tests early early-like-actually-early          |

Comment (by schlessera):

 Replying to [comment:26 azaozz]:
 > If it is under the "WordPress umbrella" it should follow the WordPress
 best practices, i.e. backwards compatibility is a number one priority.
 Frankly it is unthinkable that a library developed as part of WordPress
 would not only break back-compat, but will cause fatal errors when used in
 > If there is such "code style" requirement in that repository it should
 be removed as incompatible with WordPress. Also, generally, namespaces
 should be considered "evil" in open source software and avoided as much as
 possible. The reason it that they promote "lazy" names that go against the
 best practice in writing good code (poor self-documenting, confusing
 names, etc.).
 > Seems a possible/good way forward would be to release Requests 3.0 that
 will be incompatible with 2.0 but fully compatible with 1.0, then consider
 it for adding to the next WordPress release.  The alternative would be to
 move the Requests repository out of WordPress and continue developing it
 as a "true" third-party library that is, unfortunately, incompatible with

 I will not bother to discuss the benefits of namespacing here, but I just
 want to state that I feel the above is painfully disrepectful of the many
 months of hard work that were invested into the Requests library to ensure
 it keeps working as a secure HTTP abstraction layer for the WordPress

 Backwards-compatibility was the number one priority, and I can only guess
 now how @jrf must have felt reading the above, when she literally spent
 nights and weekends to ensure everything stays compatible.

 I'm happy to discuss ways of fixing the upgrader process and will help
 test it and support it with WP-CLI. But as far as I am concerned, there
 will not be a Requests v3 to undo the work we did to make that library
 maintainable again.

Ticket URL: <https://core.trac.wordpress.org/ticket/54504#comment:37>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

More information about the wp-trac mailing list