[wp-trac] [WordPress Trac] #25652: Enforce some of our strictest update checks only for background updates

WordPress Trac noreply at wordpress.org
Mon Oct 21 19:00:54 UTC 2013


#25652: Enforce some of our strictest update checks only for background updates
-----------------------------+-----------------
 Reporter:  nacin            |      Owner:
     Type:  defect (bug)     |     Status:  new
 Priority:  normal           |  Milestone:  3.7
Component:  Upgrade/Install  |    Version:
 Severity:  normal           |   Keywords:
-----------------------------+-----------------
 We need to make sure we don't accidentally prevent someone from ever being
 able to update, even when they click "Update Now."

 It is really important to only update automatically in the background when
 we are absolutely positive we can be successful. But, some checks could be
 a little overeager. There are two I'm thinking of, in particular:

  * disk_free_space() is enforced in unzip_file(). If there is a bug in any
 code prior to wp-admin/includes/update-core.php being included that
 prevents an update, we are completely screwed — they'll be stuck on that
 release forever.

  * The files_not_writable protection does happen inside wp-admin/includes
 /update-core.php, so if we're overzealous, a new release can fix it. That
 said, if there's a single file we can't copy (some random TinyMCE image or
 something), the site isn't actually affected, but we'd block the entire
 update from continuing. For background updates, this is very good. For
 manual updates, it's possible that we actually would *prefer* for the
 update to occur, and fail, than for the user to not actually be able to
 update at all. We also do a disk_free_space() check later on, prior to
 performing a last-resort copy.

 What I'd like to do is two-fold:

  * Only enforce disk_free_space() (and other pre-`update-core.php` checks)
 if we are DOING_CRON.

  * Do a pretty basic 3.7.1 update with some bug fixes as a "test" for how
 successful our updates are.

 There hasn't actually been any files_not_writable failures since 3.7-RC1,
 so I think we can leave that as-is for now. However, we should vastly
 improve our error messages (yes, for 3.7).

--
Ticket URL: <http://core.trac.wordpress.org/ticket/25652>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list