[wp-trac] Re: [WordPress Trac] #10013: poorly documented widget args are confusing

WordPress Trac wp-trac at lists.automattic.com
Wed Jun 3 02:41:27 GMT 2009


#10013: poorly documented widget args are confusing
-------------------------------+--------------------------------------------
 Reporter:  Denis-de-Bernardy  |       Owner:  azaozz      
     Type:  defect (bug)       |      Status:  new         
 Priority:  normal             |   Milestone:  2.8         
Component:  Widgets            |     Version:              
 Severity:  normal             |    Keywords:  dev-feedback
-------------------------------+--------------------------------------------
Changes (by azaozz):

  * priority:  high => normal
  * severity:  blocker => normal


Comment:

 Replying to [comment:2 Denis-de-Bernardy]:
 > The widget_update_callback and widget_form_callback hooks are missing a
 callback.
 >
 > Their main purpose is to override the normal callback ...

 No, overriding any of the widget's callbacks would usually break the
 widget. Their purpose is to allow post-processing of the new settings when
 saving or adding form fields to the existing widget form. Also the sidebar
 ID is usually available in the POST request.

 > this line: if ( 'noform' !== $return ) ... is very questionable. it
 means you cannot add extra fields to a form that has no fields in the
 first place.

 Yes, you cannot add form fields to a widget that doesn't have a form...
 This is only used to show (or hide) the Save button on the widgets screen.

 > widget_update_callback hook has inconsistent args.

 Again this is not meant to allow replacing of the callback, it is there to
 allow extra processing of the widget's settings before saving them.

 I'm actually wondering how to discourage plugins that access widgets
 internal functions directly. Each widget is like a small (or not so small)
 plugin and is meant to be a separate entity that uses the API. Using (or
 changing) internal widget functionality is not a good practice.

 Of course this affects mostly the default widgets. Perhaps can mark them
 as "Private" as they may change from version to version. If a plugin wants
 to use default widget functionality, it's a lot better to copy the code,
 change it and register it as a separate widget. That will also ensure
 future compatibility. It can even unregister the default widget although
 that would mean less options for the users.

 Changing to normal severity only for the `if ( 'noform' !== $return )`
 part. Reworking this might help a few plugins.

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


More information about the wp-trac mailing list