[wp-trac] [WordPress Trac] #32470: Abstracting the Widget Classes

[WordPress Trac]

#32470: Abstracting the Widget Classes
------------------------------------+------------------------------
 Reporter:  welcher                 |       Owner:
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Widgets                 |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  dev-feedback has-patch  |     Focuses:
------------------------------------+------------------------------

Comment (by jdgrimes):

 Replying to [comment:14 welcher]:
 > New patch in place that better demonstrates the changes proposed to
 `WP_Widget`
 >
 > I have done a first pass on the default widgets and this new approach
 removes a fair amount of duplication.
 >
 > Some of the widgets will need slight refactoring to accommodate using
 the new methods and I have left them as is for now.
 >
 > A few takeaways:
 > 1. We need a way of stopping the widget from rendering if there is no
 content without having to override the whole `widget()` method

 I think we need to look at the reasons that no content will be displayed
 and see if there is a common pattern. In several of the cases it is
 because the settings aren't actually valid. In my plugin I use a
 `verify_settings()` method to check that the settings are valid before the
 widget is displayed. If they aren't, it shows a helpful error message
 instead (but only if the user has the caps necessary to edit the widget).

 > 2.  I think we should abstract out the processing for the `title`
 parameter. Currently it is in the `before_widget()` method and it would be
 better to have access to it where ever needed - which will help the
 refactoring I mentioned earlier.

 This sounds like a good idea. I notice that the
 [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/default-
 widgets.php#L1397 tag cloud widget provides a default title] if it is
 empty, for example.

 > 3. We have not accounted for caching - but that might be better suited
 as a full override of `widget()` as it won't be needed on every Widget

 I think caching is something that can be abstracted out into the main
 class. For widgets that use caching, they can set a class property as a
 flag to enable it, like `protected $use_caching = true`.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32470#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform