[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  |     Focuses:
--------------------------+------------------------------
Changes (by welcher):

 * keywords:   => dev-feedback


Comment:

 I think abstracting the code can start with WP_Widget itself. The
 `widget()` method is extremely generic and I would start by having it call
 three new public methods:

 1. `before_widget()`
 2. `widget_markup()`
 3. `after_widget()`

 '''before_widget:'''

 This method would output a standard before widget and title and would be
 modelled after what we are doing in the majority of the default widgets.
 i.e:
 {{{
 public function before_widget( $args, $instance ) {
     $title = apply_filters( 'widget_title', ! isset($instance['title']  )
 || empty( $instance['title'] ) ? '' : $instance['title'], $instance,
 $this->id_base );
     echo $args['before_widget'];
     if ( $title ) {
         echo $args['before_title'] . $title . $args['after_title'];
     }
 }
 }}}

 '''after_widget()'''
 Again this would be modelled after what is being done with current default
 widgets. i.e

 {{{
 public function after_widget( $args, $instance ) {
     echo $args['after_widget'];
 }
 }}}

 '''widget_markup()'''
 This method would handle the custom portion of the widget. We would need
 some kind of default markup. In a sub-class this would/should contain
 calls to other methods.

 '''The 'new' widget() method'''

 The current widget method is required to be overridden. I would rather see
 the widget() method be something like this.

 {{{
 public function widget( $args, $instance ) {
     $this->before_widget( $args, $instance );
     $this->widget_markup();
     $this->after_widget( $args, $instance );
 }
 }}}

 This would be backwards compatible the method can still be overridden but
 any new widgets can take advantage of customizing only the parts they
 want.

 Example using WP_Widget_Search:

 {{{
 /**
  * Search widget class
  *
  * @since 2.8.0
  */
 class WP_Widget_Search extends WP_Widget {

         public function __construct() {
                 $widget_ops = array('classname' => 'widget_search',
 'description' => __( "A search form for your site.") );
                 parent::__construct( 'search', _x( 'Search', 'Search
 widget' ), $widget_ops );
         }

         public function widget_markup() {
                 get_search_form();
         }

         public function form( $instance ) {
                 $instance = wp_parse_args( (array) $instance, array(
 'title' => '') );
                 $title = $instance['title'];
 ?>
                 <p><label for="<?php echo $this->get_field_id('title');
 ?>"><?php _e('Title:'); ?> <input class="widefat" id="<?php echo
 $this->get_field_id('title'); ?>" name="<?php echo
 $this->get_field_name('title'); ?>" type="text" value="<?php echo
 esc_attr($title); ?>" /></label></p>
 <?php
         }

         public function update( $new_instance, $old_instance ) {
                 $instance = $old_instance;
                 $new_instance = wp_parse_args((array) $new_instance,
 array( 'title' => ''));
                 $instance['title'] = strip_tags($new_instance['title']);
                 return $instance;
         }

 }
 }}}

 Clearly, this needs some more thought but it's a place to start at any
 rate.

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