[wp-trac] [WordPress Trac] #25660: If an administrator triggers cron, a background update could temporarily lock them out
WordPress Trac
noreply at wordpress.org
Mon Oct 21 19:53:19 UTC 2013
#25660: If an administrator triggers cron, a background update could temporarily
lock them out
-----------------------------+-----------------
Reporter: nacin | Owner:
Type: defect (bug) | Status: new
Priority: high | Milestone: 3.7
Component: Upgrade/Install | Version:
Severity: major | Keywords:
-----------------------------+-----------------
Thank goodness for local autosaves in 3.6.
If an administrator triggers a cron event, a background update could
temporarily lock them out. The first page they open will trigger the cron,
and then the very next thing they do will hit the maintenance wall. We
could block or delay updates whenever it's a logged-in user that triggers
a cron event, but that's kind of lame — especially if the site is only
accessible to logged-in users.
I think we should do a few things to mitigate this. In order of priority
and ease:
* High priority, pretty simple. We need to test how heartbeat — auth
checks, post locks, and interrupted connection notices — handles this.
It's possible we need to account for a 503 and say "Hang tight, your site
is updating" or something, in lieu of the intermittent connection issue.
* Medium priority, takes a little more work. We should show a notice.
"This site is scheduled to update WordPress in less than %s minutes.
Update now, it's easy and takes a few moments: (link)". Show it to users
capable of updating WordPress core (it's just something we'd add to the
existing nag). Say, if we are within 30 minutes of the next scheduled
event? Jaquith mocked up a little timer countdown in the toolbar, which
could be cool for 3.8.
* Low priority, decent amount of work. If a user with the ability to
update_core triggers a cron event that would normally cause a background
update, *delay* the update by 30 minutes, and show them said notice. (Do
not allow it to be delayed a second time, which we can solve by just
passing some random argument to the cron event.) It's not ideal, as
they're then told to click something that should be automatic, but it'd be
really nice to not interrupt what they are doing (potentially the saving
of a post, etc.). It's possible an update could come at a *really*
inopportune time, obviously, and we should try to prevent surprises. It's
kind of similar to "Install and Relaunch" that a bunch of Mac apps nag me
about all the time. Note, this would likely require us to put some one-off
code pretty deep into the cron API.
It's possible that this is not a big deal. I don't think I've seen it
reported more than once or twice, though both dd32 and I have triggered it
on our own. (It should be noted that when dealing with local installs, it
will *always* be your visit that triggers the cron, so it's more likely to
be noticed.)
Why? It's possible/probable that the download and unzipping takes most of
the time (we're seeing averages of about 24 seconds for nightly builds)
and that we only have maintenance mode set for a few seconds.
We currently have data on how long an update takes, but we should
specifically try to collect a better data point: exactly how long
maintenance mode was set for. (We should be able to do this by including
the file before we leave maintenance mode and retrieve the time that was
set.) Such a short timeframe might actually render this ticket moot, as
the person's page will be loading by the time the cron HTTP request is
fired, and maintenance mode will be off again by the time the person tries
to advance to the next page.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/25660>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list