#27722 closed defect (bug) (maybelater)
Don't fire a warning when the WP API timeouts — or do so properly.
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.7.1 |
Component: | Upgrade/Install | Keywords: | needs-patch |
Focuses: | Cc: |
Description
At the time of writing, I'm systematically getting the following error from within the WP admin area's update core section:
An unexpected error occurred. Something may be wrong with WordPress.org or this server's configuration.
Two things bother me:
- It only fires when SSL is used.
- The raw_response content suggests a connection timeout.
I think the warning itself is of dubious merit. If we decide to keep it, it should be more explicit as to what is going on. And it should always fire, regardless of whether SSL is getting used or not…
A possible exception I'd make is when it's a request timeout — in that case WP should silently try again a few minutes later — without a warning or notice.
Change History (13)
#3
@
11 years ago
Another nice to have feature would be to make these checks run on a cron job, rather than during a page load. When you've a bad internet connection, it prevents from loading.
#4
in reply to:
↑ 2
@
11 years ago
Replying to SergeyBiryukov:
I get this warning in the admin without SSL too. Sounds like a duplicate of #25788 and #27091.
Yeah, thanks for the hint. I identified that my code for excluding wp.com themes from updates was broken. Works now fine.
#7
@
10 years ago
I'm receiving this error all the time in WordPress 4.3-RC. Can we look into a fix?
#8
@
9 years ago
- Keywords needs-patch added; dev-feedback removed
- Milestone changed from Awaiting Review to 4.4
- Owner set to johnbillion
- Status changed from new to accepted
This drives me nuts.
#9
@
9 years ago
This could also be triggered as a result of plugins making use of the "plugins_api" filter to modify where their plugins' are updated from. i.e. doing a wp_remote_post to their own server instead of WordPress.org and the result being a timed out connection or an unknown response, thereby resulting in the error being thrown.
I suppose we need to understand why the error is being shown in the first place and if it is in fact helpful.
I believe our options are as follows:
- Simply do not show the error
- Show the error, but give more detail so they user can make an informed decision
- Show the error with more detail but perhaps show it in the normal <div class='error'> notice instead of the traditional WP_Error output.
Can we get a consensus on what we all feel is the best option? I can then try come up with a patch.
I have noticed this as well some time ago. Only SSL connections are failing sometimes with
Operation timed out after 3000 milliseconds with 0 bytes received
.The notice is triggered as E_USER_WARNING or E_USER_NOTICE and are for regular users not visible. When the SSL request fails it will fallback to a non SSL request, see #25716.