Opened 14 years ago
Closed 12 years ago
#13732 closed defect (bug) (fixed)
Why are we _maybe_update'ing on admin-ajax?
Reported by: | mitchoyoshitaka | Owned by: | dd32 |
---|---|---|---|
Milestone: | 3.4 | Priority: | low |
Severity: | normal | Version: | 3.0 |
Component: | Upgrade/Install | Keywords: | has-patch 3.2-early |
Focuses: | Cc: |
Description
I was tracking down a slow-ish admin-ajax call today and noticed that _maybe_update_core, _maybe_update_plugins, and _maybe_update_themes get called during the course of an admin-ajax call.
Best case we're making three SQL calls to get the transients... worst case we'll actually check if we need to update.
Do we really need these in admin-ajax calls? Attached is a proposed patch.
Attachments (2)
Change History (17)
#3
@
13 years ago
We added an if ( ! is_main_site() ) return;
. Can probably just drop DOING_AJAX in there as well.
#4
@
13 years ago
- Keywords 3.2-early added
- Milestone changed from 3.1 to Future Release
Moving these to admin_footer make more sense. Setting for 3.2-early.
#5
@
13 years ago
I'm not sure if this is the right thread for this, but I think it is related.
I'm running 3.1-beta1-16732, but this has been going on for about 2 months of revisions.
For
network/upgrade.php?action=upgrade ("Update Network")
I keep getting a server 504 timeout.
This was not occurring before, or for sites running wp 3.0.2 I'm running on the same server.
I did some bebugging, and found that the function _maybe_update_core is called on every single admin request regardless of location, which in turn calls wp_remote_get.
So essentially in my particular case the admin runs a curl request on every single request? Really?
I'm not sure if this has always been the case, or if it is recent, but it seems like my issue might have to do with running wp_remote_get twice? Once for _maybe_update_core and once for upgrade.php?action=upgrade
This is puzzling and concerning at the same time.
For information, I'm running PHP 5.3.2
through php-cli (FastCGI) from within Cherokee Web Server.
Before anyone automatically disregards this saying something like 'we don't officially support Cherokee Web Server', I would like to reiterate that this issue is recent, and was not occurring on previous revisions predating about October.
Any info would be much appreciated.
#6
@
13 years ago
_maybe_update_core()
only triggers an HTTP call if the transient is expired. So only once every 12 hours.
We have _maybe_update_* in case wp cron won't work -- we still want people to see updates.
"Update Network" is the DB upgrade. Doesn't have to do with updating core files. What we do there though is make a loopback HTTP request to a file in wp-admin that then runs the DB upgrade. Do loopbacks work on your server?
#7
@
13 years ago
Yes, this is a test I ran in terminal.
[root@myserver ~]# curl http://travel.dev.jimisaacs.com/wp-admin/upgrade.php?step=upgrade_db
0
'0' is the same response I get in the browser, so I assume it is correct.
So if this is working maybe there is something wonky in the WP_Http_Curl class for 5.3.2 ?
By the way here info on my curl:
curl 7.21.0 (x86_64-redhat-linux-gnu) libcurl/7.21.0 NSS/3.12.8.0 zlib/1.2.5 libidn/1.18 libssh2/1.2.4
As for _maybe_update_core running every 12 hours. What would this mean about my comment regarding that I see _maybe_update_core running on every wp-admin/ request?
Thanks, Jim
#8
@
13 years ago
The function itself is fired every admin pageload, but it checks a 12-hour transient before running the HTTP request.
#9
@
13 years ago
I did a debug_backtrace then exit(), from within the request method of WP_Http_Curl, just before curl_exec.
and I'm getting output on every wp-admin/ request.
The array traced back to _maybe_update_core every time.
#10
@
13 years ago
Is there a particular transient I can clear?
Maybe something got screwing along the way in updating revisions.
#11
@
13 years ago
This is what I am seeing as the update_cor transient.
stdClass Object ( [updates] => Array ( [0] => stdClass Object ( [response] => development [url] => http://wordpress.org/download/svn/ [package] => http://wordpress.org/nightly-builds/wordpress-latest.zip [current] => 3.0.3 [locale] => en_US [php_version] => 4.3 [mysql_version] => 4.1.2 [dismissed] => ) ) [last_checked] => 1291848416 [version_checked] => 3.1-beta1-16732 )
#12
@
13 years ago
I called delete_site_transient('update_core'); and refreshed a few times to make sure things were reset.
Then I tried the debug_backtrace again, and still a curl request is being made every request.
Here is an example of the backtrace from the wp-admin/users.php file.
Array ( [0] => Array ( [file] => /masked-filepath/wp-includes/class-http.php [line] => 318 [function] => request [class] => WP_Http_Curl [object] => WP_Http_Curl Object ( ) [type] => -> [args] => Array ( [0] => http://api.wordpress.org/core/version-check/1.5/?version=3.1-beta1-16732&php=5.3.3&locale=en_US&mysql=5.1.52&local_package=&blogs=3&users=1&multisite_enabled=1 [1] => Array ( [method] => GET [timeout] => 3 [redirection] => 5 [httpversion] => 1.0 [user-agent] => WordPress/3.1-beta1-16732; http://masked-host/ [blocking] => 1 [headers] => Array ( [wp_install] => http://masked-host/ [wp_blog] => http://masked-host/ [Accept-Encoding] => deflate;q=1.0, compress;q=0.5 ) [cookies] => Array ( ) [body] => [compress] => [decompress] => 1 [sslverify] => 1 [ssl] => [local] => ) ) ) [1] => Array ( [file] => /masked-filepath/wp-includes/class-http.php [line] => 362 [function] => request [class] => WP_Http [object] => WP_Http Object ( ) [type] => -> [args] => Array ( [0] => http://api.wordpress.org/core/version-check/1.5/?version=3.1-beta1-16732&php=5.3.3&locale=en_US&mysql=5.1.52&local_package=&blogs=3&users=1&multisite_enabled=1 [1] => Array ( [method] => GET [timeout] => 3 [user-agent] => WordPress/3.1-beta1-16732; http://masked-host/ [headers] => Array ( [wp_install] => http://masked-host/ [wp_blog] => http://masked-host/ ) ) ) ) [2] => Array ( [file] => /masked-filepath/wp-includes/http.php [line] => 76 [function] => get [class] => WP_Http [object] => WP_Http Object ( ) [type] => -> [args] => Array ( [0] => http://api.wordpress.org/core/version-check/1.5/?version=3.1-beta1-16732&php=5.3.3&locale=en_US&mysql=5.1.52&local_package=&blogs=3&users=1&multisite_enabled=1 [1] => Array ( [timeout] => 3 [user-agent] => WordPress/3.1-beta1-16732; http://masked-host/ [headers] => Array ( [wp_install] => http://masked-host/ [wp_blog] => http://masked-host/ ) ) ) ) [3] => Array ( [file] => /masked-filepath/wp-includes/update.php [line] => 71 [function] => wp_remote_get [args] => Array ( [0] => http://api.wordpress.org/core/version-check/1.5/?version=3.1-beta1-16732&php=5.3.3&locale=en_US&mysql=5.1.52&local_package=&blogs=3&users=1&multisite_enabled=1 [1] => Array ( [timeout] => 3 [user-agent] => WordPress/3.1-beta1-16732; http://masked-host/ [headers] => Array ( [wp_install] => http://masked-host/ [wp_blog] => http://masked-host/ ) ) ) ) [4] => Array ( [file] => /masked-filepath/wp-includes/update.php [line] => 303 [function] => wp_version_check [args] => Array ( ) ) [5] => Array ( [function] => _maybe_update_core [args] => Array ( [0] => ) ) [6] => Array ( [file] => /masked-filepath/wp-includes/plugin.php [line] => 395 [function] => call_user_func_array [args] => Array ( [0] => _maybe_update_core [1] => Array ( [0] => ) ) ) [7] => Array ( [file] => /masked-filepath/wp-admin/admin.php [line] => 111 [function] => do_action [args] => Array ( [0] => admin_init ) ) [8] => Array ( [file] => /masked-filepath/wp-admin/users.php [line] => 10 [args] => Array ( [0] => /masked-filepath/wp-admin/admin.php ) [function] => require_once ) )
#13
@
13 years ago
@jimisaacs curious, are you getting this still with 3.2? I may also investigate further myself.
Would love to get this taken care of.
I'm assuming those calls are only there for when Cron is non-operationable, as cron uses a different hook.
I'm not sure this is needed to be run on admin_init at all, Perhaps something later such as the footer would be better suited.
Setting this to 3.1 for a proper fix instead.