[wp-trac] [WordPress Trac] #46292: Bump `set_time_limit()` at the start of the update process, instead of mid-way.

[WordPress Trac]

#46292: Bump `set_time_limit()` at the start of the update process, instead of mid-
way.
-----------------------------+-----------------------------
 Reporter:  dd32             |      Owner:  (none)
     Type:  defect (bug)     |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Upgrade/Install  |    Version:
 Severity:  normal           |   Keywords:  needs-patch
  Focuses:                   |
-----------------------------+-----------------------------
 Currently WordPress calls `set_time_limit( 300 )` before it installs an
 update, however it calls this at the point between unzipping the files,
 and copying them into place.
 For plugins/themes/translations/etc it's
 [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes
 /class-wp-upgrader.php?marks=466#L447 this call] for core it's
 [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes
 /update-core.php?marks=882#L869 this one].

 This, combined with the much higher core package sizes (More than doubled
 since 3.7) results in some people hitting the default php execution cap of
 30 seconds during the download phase when testing locally (For example,
 11MB @ 2.5mbit/s = 35 seconds).

 To make it more 'annoying', The `core_upgrader` Lock is put in place
 before the package is downloaded, so if they run into the timeout during
 downloading, the lock will still be in place in `wp_options` for 15
 minutes.

 `set_time_limit` should be set at the start of the process, likely at the
 point of the locks being created, before downloads have begun.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/46292>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform