[wp-trac] [WordPress Trac] #31011: WP 4.1 checks for updates with every load of any admin page

[WordPress Trac]

#31011: WP 4.1 checks for updates with every load of any admin page
-------------------------------+------------------------------
 Reporter:  hallcp             |       Owner:
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Administration     |     Version:  4.1
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+------------------------------

Comment (by craig0990):

 Hi folks. I'm new here as well, but I think I'm experiencing the same
 issue, and I think I know why. Bear with me, and if I'm wrong call me out.
 Impatient? Temporary fix provided at the end of this comment.

 For clarity, this is a brand new install of WordPress 4.1 with no custom
 themes or plugins. Everything worked fine to begin with, and then suddenly
 starting showing these symptoms (apparently) out of nowhere.

 Every time I load the WordPress 4.1 admin, I see:

 {{{
 Warning: An unexpected error occurred. Something may be wrong with
 WordPress.org or this server’s configuration. If you continue to have
 problems, please try the support forums. (WordPress could not establish a
 secure connection to WordPress.org. Please contact your server
 administrator.) in /var/www/cgr/admin/httpdocs/wp-includes/update.php on
 line 295
 }}}

 Like ''hallcp'', the API call to check for updates is timing out. I
 suspect this is why it runs on every single page load - if it never
 ''succeeds'', then it never resets the timer.

 I can't remember what made me think of cURL (apart from the assumption
 that PHP uses cURL if possible). I was also fairly sure I had update cURL
 fairly recently...

 Sure enough, '''/var/log/apt/history.log''' shows '''libcurl''' updated to
 v7.35.0.

 '''NOTE''' I'm not saying that '''libcurl''' caused this. I don't know
 enough about this sort of thing to make that kind of claim.

 Putting some debugging code into wp-includes/update.php gave me a more
 useful error message of:

 {{{
 Resolving timed out after 3512 milliseconds
 }}}

 After Googling this, I guessed that IPv6 DNS lookup is failing, which is
 why it's taking such a long time to timeout/fail/whatever.

 The following shell commands pretty much confirmed this:

 {{{
 $ curl --connect-timeout 3 -v http://api.wordpress.org
 $ curl --connect-timeout 3 -v -4 http://api.wordpress.org
 $ curl --connect-timeout 3 -v -6 http://api.wordpress.org
 }}}

 Bingo.

 Now, I'm stuck a little here. I can patch my local copy for now (and have
 done), I can disable IPv6 at the server level, or I can disable cURL at
 the Apache level. None of those are particularly good choices.

 I would like to propose a fix that makes this configurable in some way
 from '''wp-config.php''', but I'm not sure how to go about that. My first
 guess would be adding a constant, say something like
 '''WP_CURL_IPV4_ONLY'''.

 Regardless, add this:

 {{{
 curl_setopt( $handle, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4 );
 }}}

 after '''line 1412''' in '''wp-includes/class-http.php''' to fix this
 issue.


 '''P.S.''' The theory ''"I suspect this is why it runs on every single
 page load - if it never succeeds, then it never resets the timer"'' was
 correct.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/31011#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform