[wp-trac] [WordPress Trac] #22378: Add ability to hijack plugin install/upgrade downloads
WordPress Trac
noreply at wordpress.org
Wed Nov 7 13:00:19 UTC 2012
#22378: Add ability to hijack plugin install/upgrade downloads
-----------------------+-----------------------------
Reporter: rmccue | Type: defect (bug)
Status: new | Priority: normal
Milestone: 3.5 | Component: Upgrade/Install
Version: trunk | Severity: normal
Keywords: has-patch |
-----------------------+-----------------------------
'''Problem'''
Many plugins have their own updating system. For paid plugins, this can
involve
sending authentication/authorization headers. At the moment, to implement
this,
certain parts of the plugin upgrader system have to be duplicated to
replace
parts of the system, such as the downloading method. In addition, the
package
download URL has to be a valid URL. Some systems may wish to use alternate
URLs
apart from HTTP/FTP-based URLs.
The code for this is shared between the single plugin upgrader and the
bulk
plugin upgrader. While the upgrader class can be replaced fairly easily
with
existing filters for single plugins, it's not possible to do this for the
bulk
upgrader (especially when multiple systems want to do this), requiring
falling
back to a low-level filter like `http_request_args`, ensuring that one
only
hooks in after the `admin_action_update-selected` action has failed.
'''Solution'''
Add a filter to hijack the download system before it can act at all. This
allows
replacing the entire downloading system, with the only requirement being
to
return a valid package filename. This filter will work across both the
single
and bulk upgraders, ensuring consistency in the approach.
Patch attached. Related: #22377, #22129
--
Ticket URL: <http://core.trac.wordpress.org/ticket/22378>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list