[wp-trac] [WordPress Trac] #22377: Add filter to wp_update_plugins()

[WordPress Trac]

#22377: Add filter to wp_update_plugins()
-----------------------------+--------------------
 Reporter:  rmccue           |       Owner:
     Type:  enhancement      |      Status:  new
 Priority:  low              |   Milestone:  3.5
Component:  Upgrade/Install  |     Version:  trunk
 Severity:  minor            |  Resolution:
 Keywords:  has-patch        |
-----------------------------+--------------------
Description changed by rmccue:

Old description:

> '''Background'''
>
> Certain plugins (paid plugins, etc) may not wish to use WordPress' built-
> in
> upgrading functionality. As such, they may implement their own update
> checking
> code. WordPress' code runs every 12 hours via wp-cron, so hooking into
> the
> native system for checking would be the best way to avoid duplicating
> tonnes of
> code.
>

> '''Problem'''
>
> Currently, filtering this result is somewhat unintuitive. There are no
> filters
> in `wp_update_plugins()` to filter the result of the API call, so you
> have to
> fall back to `pre_set_site_transient_update_plugins`. WordPress, however,
> sets
> this transient twice,
> [https://core.trac.wordpress.org/browser/trunk/wp-
> includes/update.php?rev=21996#L193
> once before updating] "to prevent multiple blocking requests if request
> hangs"
> and then once afterwards with the actual result.
>
> This is only a minor inconvience, but it appears to be somewhat fragile.
> Ensuring that a plugin's custom code doesn't run on the first
> `set_transient()`
> requires setting a flag, and this is prone to breaking if
> `wp_update_plugins()`
> changes internally.
>

> '''Solution'''
>
> Introduce a new filter to change the API result before saving. This
> filter
> should only run once, with the actual result of the API call.
>
> Patch attached.

New description:

 '''Background'''

 Certain plugins (paid plugins, etc) may not wish to use WordPress' built-
 in
 upgrading functionality. As such, they may implement their own update
 checking
 code. WordPress' code runs every 12 hours via wp-cron, so hooking into the
 native system for checking would be the best way to avoid duplicating
 tonnes of
 code.


 '''Problem'''

 Currently, filtering this result is somewhat unintuitive. There are no
 filters
 in `wp_update_plugins()` to filter the result of the API call, so you have
 to
 fall back to `pre_set_site_transient_update_plugins`. WordPress, however,
 sets
 this transient twice,
 [https://core.trac.wordpress.org/browser/trunk/wp-
 includes/update.php?rev=21996#L193 once before updating] "to prevent
 multiple blocking requests if request hangs"
 and then once afterwards with the actual result.

 This is only a minor inconvenience, but it appears to be somewhat fragile.
 Ensuring that a plugin's custom code doesn't run on the first
 `set_transient()`
 requires setting a flag, and this is prone to breaking if
 `wp_update_plugins()`
 changes internally.


 '''Solution'''

 Introduce a new filter to change the API result before saving. This filter
 should only run once, with the actual result of the API call.

 Patch attached.

--

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/22377#comment:1>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software