After trying several times to set the proper charset, I wasn’t successful. Then I searched for an workaround and found one that worked with my problem. In addition to set the charset like I mentioned above, what I did is to convert all strings on my POST body with this php snippet: $message = @iconv(“UTF-8″,”Windows-1252//IGNORE”,$message); … Read more
I see that the question is 2 years old, but I worked hard two days to find solution of the very same problem and here is my code (for me works 100%). $json_string = wp_remote_request(‘https://clients6.google.com/rpc’, array( ‘method’ => ‘POST’, ‘body’ => ‘[{“method”:”pos.plusones.get”,”id”:”p”,”params”:{“nolog”:true,”id”:”‘.rawurldecode(get_permalink()).'”,”source”:”widget”,”userId”:”@viewer”,”groupId”:”@self”},”jsonrpc”:”2.0″,”key”:”p”,”apiVersion”:”v1″}]’, ‘headers’ => array(‘Content-Type’ => ‘application/json’) )); $json = json_decode($json_string[‘body’], true); if(isset($json[0][‘result’][‘metadata’][‘globalCounts’][‘count’])){ echo intval($json[0][‘result’][‘metadata’][‘globalCounts’][‘count’]); … Read more
I recommend only setting the arguments you absolutely need to change from defaults, to eliminate potential issues while testing. It’s best to only add additional arguments as they are needed. All arguments can be found here: https://developer.wordpress.org/reference/classes/WP_Http/request/ If possible also remove the required authentication at first to just test the POST before adding in security/authentication. … Read more
So, you set the headers of a request using wp_remote_post() and you expect that headers be used in the response. That is what I understand from you: When I print the response content-type is still “text/html” I think that you are missunderstanding the HTTP headers. Using wp_remote_post() you make a request and you can set … Read more
If you happen to be using the CURL transport, then it sometimes has minor problems sending POST requests greater than 1024 characters. More info here: https://stackoverflow.com/questions/463144/php-http-post-fails-when-curl-data-1024 The fix suggested there is to send an empty Expect: header. You can do this by modifying your code thusly: $response = wp_remote_post( $url, array( ‘timeout’ => 60, ‘redirection’ … Read more
Use the Authorization header. Example: $auth = base64_encode( $username . ‘:’ . $password ); $args = [ ‘headers’ => [ ‘Authorization’ => “Basic $auth” ], ‘body’ => $body, ]; $response = wp_remote_post( $url, $args ); $response_body = wp_remote_retrieve_body( $response );
To make wp_remote_get() work you need to check your php.ini file. In your php.ini file you need to set allow_url_include = On, which by default is set as allow_url_include = Off. Otherwise wp_remote_get() will not work. Reference: allow_url_include
You can not set cookies form site A that will be applicable on site B, therefor your “login by proxy” scheme will not work, and can not be made to work. In addition storing passwords in plain text is just a big no-no.
[*][**] So is there ever any other situation in which I would want to use wp_remote_post or should I always stick with wp_safe_remote_post? The two functions are exactly the same, except wp_safe_remote_post() sets the reject_unsafe_urls argument to true. That argument causes the URL to be passed through wp_http_validate_url() in WP_Http::request(). From that function, we see … Read more
You’re passing request params incorrectly. Take a look at Codex page. You can find such example in there: $response = wp_remote_post( $url, array( ‘method’ => ‘POST’, ‘timeout’ => 45, ‘redirection’ => 5, ‘httpversion’ => ‘1.0’, ‘blocking’ => true, ‘headers’ => array(), ‘body’ => array( ‘username’ => ‘bob’, ‘password’ => ‘1234xyz’ ), ‘cookies’ => array() ) … Read more