[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