[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):

 +1 to the class you describe. We're on the same wavelength. One of the
 child-specific functions could be the default, too. It seems to me that
 playing around with a few variables would spare ourselves the need to
 rewrite the install()/upgrade() methods.

 It might be desirable to ignore the core updates in all of this, too, and
 merely stick to sharing the code used by extensions such as plugins and
 themes.

 > The major problem is strings, Plugin and Theme strings are different,
 The error messages need to reflect the component.. So that'll be something
 that needs to be worked around.

 The parent class itself should probably contain a $messages variable,
 along the lines of an array ($code => $details) in its constructor.
 Whether it's shared between error and success messages is no big deal in
 practice. But it should definitely be around imo: The messages need to be
 translatable, and one cannot use arrays or functions in a class's variable
 declarations -- only constants. They could be grouped in some kind of
 init_messages() method for tidiness.

 Personally, I'd see it getting called in the UI screens as such:

 {{{
 if ( !is_wp_error($skin_upgrader->install($skin_id)) )
   //...

 if ( !is_wp_error($skin_upgrader->upgrade($skin_id)) )
   //...

 $skin = $skin_upgrader->get($skin_id);
 if ( !is_wp_error($skin) )
   //...

 // $skin could be an object or an array, it's no big deal
 $skin->id; // unique id, i.e. its folder
 $skin->name; // the skin's name
 $skin->url; // the url for more details
 $skin->package; // the zip file's url
 //... etc

 $skins = $skin_upgrader->query($args); // an array of skin objects, $args
 based on the $_GET request
 if ( !is_wp_error($skins) )
   //...

 $tags = $skin_upgrader->get_tags(); // popular tags, probably as objects
 too
 if ( !is_wp_error($tags) )
   //...
 }}}


 If you feel like doing the UI too, it should probably look like this
 instead:

 {{{
 $skin_query = $skin_upgrader->query($args); // $args based on the $_GET
 request

 $skin_query->display(); // this would highlight the HTTP errors as needed
 }}}

 A separate class is needed imo.

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