MickeyKay
commented
10 years ago Another update. I'm hesitant to post this, as I don't want to turn this into you troubleshooting a specific problem I've encountered, but I'm wondering if it might not have some wider bearing on people's understanding of wp_remote_get() as a whole.
Here is the server info where at least one user was experiencing issues. It looks like cURL is enabled, so it seems like the culprit must lie elsewhere:
// Generated by the Send System Info Plugin //
Multisite: No
WordPress Version: 3.9.1 Permalink Structure: /%postname%/ Active Theme: DW Timeline 1.0.9
Registered Post Stati: publish, future, draft, pending, private, trash, auto-draft, inherit
Platform: Windows
Browser Name: Chrome
Browser Version: 34.0.1847.137
User Agent String: Mozilla/5.0 (Windows NT 6.1; WOW
64) AppleWebKit/537.36 (KHTML, l
ike Gecko) Chrome/34.0.1847.137
Safari/537.36
PHP Version: 5.4.6 MySQL Version: 5.1.73-1.1+squeeze+build0+1-log Web Server Info: Apache
WordPress Memory Limit: 40MB PHP Safe Mode: No PHP Memory Limit: 256M PHP Upload Max Size: 64M PHP Post Max Size: 64M PHP Upload Max Filesize: 64M PHP Time Limit: 120 PHP Max Input Vars: 2000 PHP Arg Separator: & PHP Allow URL File Open: Yes WP_DEBUG: Disabled
WP Table Prefix: Length: 3 Status: Acceptable
Show On Front: posts Page On Front: (#0) Page For Posts: (#0)
WP Remote Post: wp_remote_post() works
Session: Disabled Session Name: PHPSESSID Cookie Path: / Save Path: /tmp Use Cookies: On Use Only Cookies: Off
DISPLAY ERRORS: On (1) FSOCKOPEN: Your server supports fsockopen. cURL: Your server supports cURL. SOAP Client: Your server has the SOAP Client enabled. SUHOSIN: Your server does not have SUHOSIN installed.
ACTIVE PLUGINS:
Better Font Awesome: 0.9.6 Contact Form 7: 3.8.1 CSS & JavaScript Toolbox: 7.1 Essential Grid: 1.0.5 iframe: 2.8 Page scroll to id: 1.5.6 Really Simple CAPTCHA: 1.8 Send System Info: 1.2 WordPress SEO: 1.5.3.2
All in regards to
wp_remote_get(). . .Inconsistency/Failure, and Fallback Options It seems that at on certain hosts/sites/situations, wp_remote_get() fails, even for totally valid URLs. I realize that this can happen if there are any server/connectivity issues with the remote URL, however I'm wondering if there are other reasons why the function might fail, and if there are any more reliable workarounds. I've read some threads that suggest that wp_remote_get() often fails on lower quality hosting - what are the factors that cause wp_remote_get() to fail in these situations vs others? Are there particular function parameters you recommend modifying from their defaults to improve the success rate?
Update: It appears that wp_remote_get is working sporadically for some users. Would this indicate that the timeout setting might be the issue and should be upped? Some other setting? I'm very curious why it works sometimes and not others (and the remote URL is a CDN with very good uptime, so I doubt that's the issue).
Fallback Options Is there a surefire set of fallbacks you recommend (e.g. wp_remote_get, file_get_contents, local hard copy)? Any other ideas on how to achieve as close to a 100% success rate as possible?
Caching/Transients I really appreciated your earlier discussion on transients and performance, and I wanted to know if wp_remote_get() employs any caching mechanism, or if it qualifies as a "frontend-triggered HTTP request" that warrants additional treatment to save on load time. If so, then is TLC Transients how you recommend handling it?
Thanks Mark!