For those daring, go ahead and run the trunk. You’ll notice a speed difference with everything including the jQuery. Backup your site for when something fails or you need to revert!

It doesn’t work that way for WordPress. Stephen Cronin has posted up some ideas on his website and one stands out that could work for WordPress.

The Staged Released version from Stephen’s is a version that I like to see adapted for WordPress. This would allow more people to get in the testing without having the entire WordPress user base feeling any remaining issues.

What would it take to get this implemented? It would have to go in after 3.0.x. The update API would have to be re-written to allow this kind of update. This kind of update might be beneficial for users who also might want ignore plugin updates.

Ignore options would be stored and could be restored in the future if the user would like to come back into the testing and/or see plugin updates.

I think this is a really good idea and should be implemented in WordPress 3.1.x.

Back story: The first post in this series is located here. The way the widget system is built right now is that when a Widget is outputted and you have custom design you want shown, you have to pass your design through the register_widget function inside functions.php, which then wraps around the widget output. I thought this was a very messy way to do it especially since it removes the ability for plugin author and user to make all the formatting look the same when the theme is updated or if the widget has custom formatting needed.

Since then, I published a trac ticket (#11387) that includes the entire patch of this system. (Some of the code has been moved to another trac ticket for version 3.0 feature.)

This new enhancement to the Widget API system allows two things:

1. Allows theme authors to specify a “Widget Walker” that will output of the design/css/code of all widgets that a user will use look the same.
2. Gives widget authors more control over their content not being manipulated as much.

On my site I had to create a new theme file called ‘widget.php’ just to override the Widget System that is officially in 2.9.1, but it’s working fine and I had seen no problems since I did this major update a few days ago. I am going to see if we can implement this in after 3.0.x because this will be a great feature for all those WordPress Muliuser sites that need all types of customization including sites that have different formatting for different pages.

Expect WordPress 3.0 released around the spring time because of the large changes to the core including WPMU integration and more media stuff (yay!).

Have a very safe holidays!

A quick note: If you run a stand-alone version, not hosted on WordPress.com, be sure you have at least MySQL version 4.1.2.  All backwards compatibility was taken out of 2.9.

User A downloads Plugin A. Plugin A has a widget which has hardcoded data output. User A has a custom theme (or a downloaded theme.) and Plugin A does not conform to the theme’s design making User A scramble for help. They check the WordPress.org forums for help in getting Widget of Plugin A changed. User A gets no help. Uninstalls the Plugin A and then is one less user that Author has their plugin installed.

Now my way of what might be coming to a WordPress enabled site soon (3.x.x would be the earliest):

User A downloads Plugin A. Plugin A has a widget. User A has a custom theme (or a downloaded theme) and that theme has a class that extends Walker_Widget called My_Walker_Widget. User A enables that Widget and it looks nice and pretty with their theme. They smile.

When the theme author updates their theme, all User’s A widgets will look like they belong there.

The Walker Widget is based of the original walker which controls the design of the output of either pages and categories. This time it’s for Widget design purposes.

I have started a ticket with a first version of a  patch on the WordPress trac site for people to test out. Currently I have change the formatting of all 12 default WordPress plugins to use the new system with the extended classes doing all the formatting. Things can still change between this patch and another. Also in the ticket is an example of my own ‘Walker_Widget_Rabbit’ design class that I have done for my development version of this theme with the Widget changes, but below is an updated version that I worked on including some custom functions I added to the design class.

class Walker_Widget_Rabbit extends Walker_Widget {

 /*
 *
 */
 function start_widget($args, &$output) {
 global $rabbithole;

 $output .= do_action('sidebar_before_module', $args['classname']);
 $output .= do_action('sidebar_before_module_' . $args['classname']);

 if ($this->scrollable($args) && (bool) $rabbithole->get_option('scrolling'))
 $output .= $this->scrollable($args, 'javascript');

 $output .= sprintf( "<div class='module widget %s'>", $args['classname'] );
 }

 /*
 *
 */
 function title_widget($args, &$output) {
 global $rabbithole;

 $output .= "<div class='head'>";
 $output .= "<h3>" . $args['title'] . "</h3>";

 if ($this->scrollable($args) && (bool) $rabbithole->get_option('scrolling'))
 $output .= "<div class='desc'>" . sprintf( __("navi: <a id=\"prev_%s\">prev</a>&nbsp;/&nbsp;<a id=\"next_%s\">next</a>"), $args['classname'], $args['classname']) . "</div>";

 $output .= "</div>";

 }

 /*
 *
 */
 function content_widget($args, &$output) {
 $output .= "<div class='wrap'>" . $this->scrollable($args, 'style') . "</div>";
 }

 function end_widget($args, &$output) {
 $output .= "</div>";
 $output .= do_action('sidebar_after_module', $args['classname']);
 $output .= do_action('sidebar_after_module_' . $args['classname']);
 }

 /** Customer Functions of the Widget Walker **/

 function scrollable($args, $area = 'enabled') {
 global $rabbithole;

 if ( $area == 'enabled' ) {
 switch ($args['classname']) {
 case 'widget_categories':
 case 'widget_archive': return true;
 default: return false;
 }
 }

 if ( $area == 'style' ) {
 switch ($args['style']) {
 case 'none':
 break;
 default:
 $args['output'] = "<ul class='dash-strip'>" . $args['output'] . "</ul>";
 }

 if ($this->scrollable($args) && (bool) $rabbithole->get_option('scrolling'))
 $args['output'] = $this->scrollable($args, 'style_wrap');

 return $args['output'];
 }

 if ( $area == 'style_wrap' ) {

 switch ($args['classname']) {
 case 'widget_categories': return "<div class='content-scroll'>" . $args['output'] . "</div>";
 case 'widget_archive': return "<div class='content-scroll-large'>" . $args['output'] . "</div>";
 }

 }

 if ( $area == 'javascript' ) {

 $obj = $args['classname'];
 switch ($obj) {
 case 'widget_categories': $size = 5;
 case 'widget_archive': $size = 6;
 }

 return "<script type='text/javascript'>
 /* <![CDATA[ */
 jQuery(document).ready(function() {
 jQuery(\".".$obj."\").scrollable({
 vertical: true,
 size: ".$size.",
 keyboard: false,
 items: '.dash-strip',
 easing: 'linear',
 prevPage: '#prev_".$obj."',
 nextPage: '#next_".$obj."',
 disabledClass: 'disabled_Scroll',
 clickable: false
 });
 });
 /* ]]> */
 </script>";
 }

 }

}

What is a Walker Class?

A walker class allows you to manipulate how data is displaied on your blog without having to modify the core files. What ever methods you do not override use the default method in the Walker class that you Extend.

There are five walkers already built in:

1. Walker_Comment – Used for when listing comments
2. Walker_CategoryDropdown – Category list into an HTML dropdown element
3. Walker_PageDropdown – Page list into an HTML dropdown element
4. Walker_Page – Page listing widget/navigation
5. Walker_Category – Category dropdown tree

In this example, I am going to show you how I worked on extending the Walker_Page class and implementing it correctly in a theme.

header.php

$walker_pages = new Walker_Page_Rabbit;
wp_list_pages(array('walker' => $walker_pages, 'title_li' => '', 'depth' => '1'));

functions.php

class Walker_Page_Rabbit extends Walker_Page {
 //... code here ...
}

Within this class you can have methods/function that override WordPress’s default code including how it works and how the information is displayed.  Instead of relying on WordPress to create it and then you format it with CSS you can make it right from the start and make the code more beautiful or do something totally different.

“O.k. I get it. I can override the walker. Why can’t I just use a callback?”

Callbacks are fine. Use callbacks. But if you were to use a walker you can add additional switches that a callback can’t handle allowing you for more customized looks. Not all walkers that WordPress has callbacks.

I have two uses of wp_list_pages. One is for the upper navigation and the other is for subpages (View the About page). Both look the same, but if I added an extra item to the array.. lets say ‘area’ and defined it as subpages and inside my customer walker method ‘start_el’  I can say..

if (subpages)
//... this is the css you are going to use ...
else
//... use this set of css ...

..and the output xhtml code would all still be the same, but be customized based off a new variable.

Using Walker classes does require some knowledge of Object Orientated Programing (OOP) in PHP, but it’s not a total requirement. There are still areas in which do not use a walker class and only filters so there is room for expansion.

One of the uses of a Walker class is that there could be a Walker_Widget class created that can make all widgets, custom or standard follow the same design standard so that widgets instead of outputting their own design use the design stated by a theme’s Walker.

Walker manipulation can be very powerful if used correctly.

Most of the text is done. All that is left is mock-ups of the design proposal. I should have it submitted to Matt (photomatt) by the next few days after Thanksgiving and then once we talk it over and make any corrections, I will post it here for everyone to review for comments and suggestions on changes.

Once I am done with talking with Matt, hopefully I can start dedicating 100% of my time to re-developing the system for either 3.0.x or 3.1.x release. (3.0.x would be preferable because of the longer cycle) With 2.9.x feature frozen and image editing now added into the system it will be much easier to complete this task.

I like to give props out to Ryan, Jane, Westi, ViperBond, DD32, Azaozz, Mark Jaquith, and last but not least Matt for letting me part of the team in this round. Hopefully when working on 2.8 I can help in a bigger way with my attachment system with multiple gallery support worked on as a team.