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

 Replying to [comment:31 jdgrimes]:

 I agree 100% that this ticket has fallen off the rails a bit.

 I have done some thinking on a roadmap/approach and in order to affect any
 change to the Widgets API we need make small iterative changes while
 moving towards the goal of a better Widget API/experience.

 In my opinion, the first step is to look at what we have and make any
 changes or fixes there.

 `default-widgets.php`

 1. Continue/finish the code audit in #23012 to bring the default widgets
 in-line with WP standards/best practices
 2. Review and if needed, update the inline docs for the default widget. I
 know there are some areas of improvement for example WP_Widget_RSS has
 very little in the way of inline docs. This is going to provide a lot of
 insight into what might need to be changed.
 3. Identifying functionality in the default widgets that can be
 encapsulated into methods. This will allow for much easier extension into
 child class. Currently, extending a default widget to override even a
 small change in the functionality usually requires a copy/pasta of the
 majority of the code.

 `WP_Widget`/General API class:

 This is where the rabbit hole begins, as there are many things we can do
 here. As a starting point, we should look at small improvements most of
 which have been discussed in this ticket already.

 1. Further abstraction for `widget()` to contain calls to other methods
 such as `before_widget()`, `after_widget()` and `widget_markup()`. This
 will allow for less code in child classes as they will only need to
 override what needs to be changed.
 2. Find a better/alternative to the current usage of `__construct` in
 child classes. IMHO, this is needlessly complicated
 3. Address the PHP4 constructor issue - #32480.

 The items above would get Widgets into a much better place and gives us a
 roadmap with actual items to check off as we move ahead.

 As usual, I'd love any feedback or suggestions!

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