I just did a clean install of WordPress. But I have a problem when I install or use the WordPress API. So send me a sign
An Unexpected HTTP Error occurred during the API request.
The strange thing is that I have looked everywhere. And the solutions do not work for me porponen WordPress 3.2.1 and do not know how to solve the problem
Use the following function to debug the HTTP API request, you will get to know the actual reason why the HTTP API request is failing.
Paste the following code in your theme’s function.php.
This script gives you a rough overview what kind of filesystem mehods are allowed/installed on your server. The first three methods are the methods WordPress prefered and WordPress can be forced to use one of them by defining
FS_METHOD
in thewp-config.php
.Copy the code into a file, upload the file to your server, checkout which filesystem methods are allowed/installed and delete the file asap.
You can try to force WordPress to use a filesystem method by defining it in your
wp-config.php
, e.g. to use the php ftp extension instead offopen
:This could be helpfull if you got trouble using a filesystem method and want to use another one.
The “WordPress API” is a pretty vague (WP got multiple APIs). But from your error it seems that it’s a HTTP API problem. There’re multiple possible obstacles:
SSL Certificate issues
If you got a problem with your SSL certificate (necessary when the server is a subdomain of the site listed in the SSL certificate; using a wildcard certificate obviates the need for this).
As pointed out in the comments, the problem could also be that your server has out-of-date or missing SSL CA root certificates.
Request problems (WP HTTP API not responding
200/OK
)You think you ain’t got
cURL
available and thefsocketopen
fallback didn’t work out?First you want to check if the response works out. For this task, you can use two services (where both tell you slightly different details):
Then, as @HameedullahKhan pointed out in his answer, there’s a debug filter for the WP HTTP API. This filter runs at the absolute last point of any request, right before giving it back to the developer.
If the above doesn’t give you any insights, you can still try to debug the cURL object right after it got built and right before it got fired. This way is pretty unknown, but it has enormous powers when you combine it with above plugin: It tells you if the request has a problem with the cURL args or if it fails later, narrowing down the range of possible problems pretty fast.