[wp-trac] Re: [WordPress Trac] #7875: consolidate plugin/theme/core upgrade/install functions

[WordPress Trac]

#7875: consolidate plugin/theme/core upgrade/install functions
-----------------------------+----------------------------------------------
 Reporter:  DD32             |       Owner:  anonymous  
     Type:  enhancement      |      Status:  new        
 Priority:  highest omg bbq  |   Milestone:  2.8        
Component:  Administration   |     Version:  2.7        
 Severity:  major            |    Keywords:  needs-patch
-----------------------------+----------------------------------------------

Comment(by Denis-de-Bernardy):

 Replying to [comment:4 DD32]:
 > This is *very* much more difficult than it sounds.

 I'm aware, but I'm also monitoring the ticket, and can readily offer
 suggestions. (I'd do it myself if my own todo list weren't so long.)


 > Each step of the upgrade/install process for each is very similar to
 eachother, but given theres about a dozen of these steps..

 K, allow me to steer you towards what I'd need as a developer then. :-)

 My interest in this one has to do with my theme, whose zip is over 5M.
 This is due to the presence of two dozen different skins in it (each with
 their own set of image files and a screenshot). My intent is to add a skin
 installer/upgrader.

 I could do this in one of two ways. The first is to copy/paste a huge
 chunk of WP code and mimic its upgrades as they occur. Obviously not a
 panacea.

 The other would be to have some kind of generic object that I can simply
 inherit. Ideally, it would go something like this, in the themes'
 functions.php:

 {{{
 class skin_upgrader extends WP_Upgrader {
   // the remote requests to check for new versions
   var $service;

   // the option where we store what $service replies, also used for plugin
 hooks
   var $option;

   // how frequently do with hit the update service
   var $cron_interval;

   // the physical path where we copy the installed/upgraded skins to
   var $path;

   // whether to keep the downloaded files' folder (core upgrader would use
 false here)
   var $keep_folder = true;
 }
 }}}

 When I initially looked into this, the stuff for core, themes and plugins
 seemed close enough that it could have been done already. The WP_Upgrader
 class could take care of:

  - setting up a cron automatically
  - periodically calling home to check for updates in a standardized manner
  - installing or upgrading when asked to (permission issues to consider
 here)
  - handling the calls to get more information on the install or upgrade by
 returning the url that should get opened using thickbox.

 The class doesn't need to care of the actual UI screens. Those are
 probably too unique to be shared. But it should expose an API that can be
 used in these screens, so as to spare oneself the hassle of needing to
 rewrite the workflow-related functions for each of plugin, theme, core...
 and in my case, skins.

 Ideally, we also toss a few plugin hooks in the class at strategic
 locations. If $options contains update_core for instance, it makes sense
 to fire things such as:

 {{{
 // anyone want to add to the response, allowing for shared screens?
 $response = apply_filters($this->options . '_response', $response);

 // it's quite difficult at the moment to change the more info link for
 plugins
 // to something that is not from WP
 $info = apply_filters($this->options . '_info', $info);

 // anything we should do before upgrading?
 do_action($this->options);

 // anything we should do after upgrading?
 do_action($this->options . '_done');
 }}}

 Makes more sense now?

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