Opened 12 years ago
Last modified 6 years ago
#22377 assigned enhancement
Add filter to wp_update_plugins()
Reported by: | rmccue | Owned by: | rmccue |
---|---|---|---|
Milestone: | Priority: | low | |
Severity: | minor | Version: | 3.4 |
Component: | Upgrade/Install | Keywords: | has-patch |
Focuses: | Cc: |
Description (last modified by )
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,
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.
Attachments (3)
Change History (22)
#2
@
12 years ago
You can also hook into 'http_request_args' + 'http_response', but that's even more unintuitive. Similar: #22129
#4
in reply to:
↑ 3
@
12 years ago
Replying to scribu:
You can also hook into 'http_request_args' + 'http_response', but that's even more unintuitive. Similar: #22129
Yeah, and bulk upgrading is actively hard. I'll open a ticket for that soonish once I get a patch for that too.
Replying to scribu:
Also, shouldn't there be a 'wp_update_themes' filter as well?
Probably, yeah, I didn't consider that. I'll update the patch.
#12
@
11 years ago
Whoops, didn't even notice I'd filed this before. attachment:25611.diff contains the patch from there.
#16
@
11 years ago
While correct on paper, 22377.2.diff and 25611.diff are incomplete patches. The current API invalidates the transient if the found plugins don't correspond to what plugins WP expects to find. If a mu-plugin hooks into the update API, this would make WP invalidate the request on each admin page load.
#17
@
9 years ago
- Owner set to rmccue
- Status changed from new to assigned
@rmccue give this a look, if you care
Add filter to wp_update_plugins