Make WordPress Core

Opened 2 years ago

Closed 19 months ago

Last modified 16 months ago

#54562 closed defect (bug) (duplicate)

5.9-beta1 Fatal Error: Class 'WpOrg\Requests\Proxy\HTTP' not found

Reported by: alexeydemidov's profile alexeydemidov Owned by: hellofromtonya's profile hellofromTonya
Milestone: Priority: normal
Severity: blocker Version: 5.9
Component: HTTP API Keywords: has-patch
Focuses: Cc:

Description

Our /wp-admin/ broke after installing 5.9-beta1

Fatal error: Uncaught Error: Class 'WpOrg\Requests\Proxy\HTTP' not found in /var/www/develop/public/wp-includes/class-wp-http.php:381 
Stack trace: 
#0 /var/www/develop/public/wp-includes/class-wp-http.php(632): WP_Http->request() 
#1 /var/www/develop/public/wp-includes/http.php(162): WP_Http->get() 
#2 /var/www/develop/public/wp-content/plugins/<...redacted...> wp_remote_get()

We have WP_PROXY_HOST and WP_PROXY_PORT defined in wp-config.php

Replacing WpOrg\Requests\Proxy\HTTP with WpOrg\Requests\Proxy\Http at wp-includes/class-wp-http.php:381 fixed the issue.

Change History (22)

#1 @costdev
2 years ago

Hi @alexeydemidov, thanks for reporting this issue and welcome to Trac!

Can you please confirm the method you used to upgrade to 5.9-beta1?

#2 @alexeydemidov
2 years ago

@costdev We update it manually by importing unpacked .zip content into our git repo which is automatically deployed to our dev server. All filesystems involved are case-sensitive.

#3 @costdev
2 years ago

  • Milestone changed from Awaiting Review to 5.9
  • Summary changed from 5.9-beta1 fails with Uncaught Error: Class 'WpOrg\Requests\Proxy\HTTP' not found in class-wp-http.php:381 to 5.9-beta1 Fatal Error: Class 'WpOrg\Requests\Proxy\HTTP' not found

@alexeydemidov Thank you for confirming. Milestoning this ticket for 5.9.

This ticket was mentioned in PR #2001 on WordPress/wordpress-develop by costdev.


2 years ago
#4

  • Keywords has-patch added

This PR changes WpOrg\Requests\Proxy\HTTP to WpOrg\Requests\Proxy\Http.

Trac ticket: https://core.trac.wordpress.org/ticket/54562

#5 follow-up: @costdev
2 years ago

A search for WpOrg\\Requests\\([A-Z]{2,}) throughout Core returns 3 instances.
All of these occur in docblocks within the Requests library and are not changed by the PR.

The PR has passed CI and is ready for final review and commit.

#6 @mukesh27
2 years ago

Hi there!

@costdev thanks for the PR. It looks good to me and ready to marge.

Let's wait for other dev feedback then we mark it commit

#7 in reply to: ↑ 5 @mukesh27
2 years ago

Can you please update docblocks in this Patch otherwise we will get a new ticket for docblocks changes?

Replying to costdev:

All of these occur in docblocks within the Requests library and are not changed by the PR.

#8 @costdev
2 years ago

@mukesh27 Done! CI is running on the PR now.

#9 @mukesh27
2 years ago

@costdev Please update docblocks in wp-includes/Requests/Proxy/Http.php file

#10 @costdev
2 years ago

PR has been updated with the docblock changes too.

#11 @hellofromTonya
2 years ago

  • Keywords commit added
  • Owner set to hellofromTonya
  • Status changed from new to reviewing

The Requests files are not maintained by Core, but rather are a dependency that is managed in the Requests library itself. The docblock changes should be reported upstream by opening an issue here https://github.com/WordPress/Requests/issues.

The fix in the PR is approved. I'll revert the Requests docblock changes before committing.

#12 @hellofromTonya
2 years ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

In 52315:

HTTP API: Fix classname WpOrg\Requests\Proxy\Http in WP_Http::request().

Renaming the classname was missed in [52244] when updating changes in WP_Http::request() for the Requests 2.0.0 external library upgrade. HTTP class no longer exists and caused a fatal error Fatal error: Uncaught Error: Class 'WpOrg\Requests\Proxy\HTTP' not found.

This commit renames the class to Http and resolves the fatal error.

Follow-up to [52244].

Props alexeydemidov, costdev, mukesh27.
Fixes #54562.

hellofromtonya commented on PR #2001:


2 years ago
#13

Committed fix only (without docblock changes) in changeset https://core.trac.wordpress.org/changeset/52315.

#14 @hellofromTonya
2 years ago

In 52327:

HTTP API: Revert changeset [52315].

Reverting Requests 2.0.0 changes and moving to WordPress 6.0 cycle. Why? The namespace and file case renaming revealed 2 issues in Core's upgrader process.

See https://core.trac.wordpress.org/ticket/54504#comment:22 for more information.

See #54562, #54504.

#15 @hellofromTonya
2 years ago

  • Keywords commit removed
  • Milestone changed from 5.9 to 6.0
  • Resolution fixed deleted
  • Status changed from closed to reopened

Re-opening and moving to 6.0 along with #54504.

#16 @SergeyBiryukov
2 years ago

In 52328:

HTTP API: Revert changeset [52244].

Reverting Requests 2.0.0 changes and moving to WordPress 6.0 cycle. Why? The namespace and file case renaming revealed 2 issues in Core's upgrader process.

See https://core.trac.wordpress.org/ticket/54504#comment:22 for more information.

Follow-up to [52327].

See #54562, #54504.

This ticket was mentioned in Slack in #core by mike. View the logs.


2 years ago

#18 @kirasong
2 years ago

  • Milestone changed from 6.0 to Future Release

If I understand correctly, it looks like this change / bug is linked to the Requests 2.0 update (#54504), which was moved to Future Release.

Going to go ahead and move this one from 6.0 to Future Release as well.

If I misunderstand, or something changes, please feel free to move it back.

#19 @SergeyBiryukov
23 months ago

  • Milestone changed from Future Release to 6.1

#20 @desrosj
19 months ago

@SergeyBiryukov can you clarify if this is still something that needs to land in 6.1? It looks like the Requests update is still in Future Release.

#21 @hellofromTonya
19 months ago

  • Milestone 6.1 deleted
  • Resolution set to duplicate
  • Status changed from reopened to closed

Been thinking more about this fatal error report and the status of this ticket. IMO this ticket can be closed. Why?

The fatal error was introduced in 5.9 alpha cycle and did not ship with 5.9.0. The root cause of the fatal error was due to an issue in the filesystem and upgrader revealed with Requests library update. When Requests v2.0.0 library was reverted [52328], the fatal error was also resolved.

What about the original root cause? Work continues in #54504.

#54504 also mentions the fatal errors and the root cause issues. Thus, IMO this ticket can be closed as a duplicate of #54504.

#22 @hellofromTonya
16 months ago

In 54997:

External Libraries: Update Requests library to version 2.0.0.

This is a major release and contains breaking changes.

Most important changes to be aware of for this release:

  • All code is now namespaced. Though there is a full backward compatibility layer available and the old class names are still supported, using them will generate a deprecation notice (which can be silenced by plugins if they'd need to support multiple WP versions). See the upgrade guide for more details.
  • A lot of classes have been marked final. This should generally not affect userland code as care has been taken to not apply the final keyword to classes which are known to be extended in userland code.
  • Extensive input validation has been added to Requests. When Requests is used as documented though, this will be unnoticable.
  • A new WpOrg\Requests\Requests::has_capabilities() method has been introduced which can be used to address #37708.
  • A new WpOrg\Requests\Response::decode_body() method has been introduced which may be usable to simplify some of the WP native wrapper code.
  • Remaining PHP 8.0 compatibility fixed (support for named parameters).
  • PHP 8.1 compatibility.

Release notes: https://github.com/WordPress/Requests/releases/tag/v2.0.0

For a full list of changes in this update, see the Requests GitHub:
https://github.com/WordPress/Requests/compare/v1.8.1...v2.0.0

This commit also resolves 2 blocking issues which previously caused the revert of [52244]:

  • New Requests files are loaded into wp-includes/Requests/src/, matching the location of the library. In doing so, filesystems that are case-insensitive are not impacted (see #54582).
  • Preload: During a Core update, the old Requests files are preloaded into memory before the update deletes the files. Preloading avoids fatal errors noted in #54562.

Follow-up to [50842], [51078], [52244], [52315], [52327], [52328].

Props jrf, schlessera, datagutten, wojsmol, dustinrue, soulseekah, szepeviktor. costdev, sergeybiryukov, peterwilsoncc, ironprogrammer, antonvlasenko, hellofromTonya, swissspidy, dd32, azaozz, TobiasBg, audrasjb.
Fixes #54504.
See #54582, #54562.

Note: See TracTickets for help on using tickets.