category: widgets

12
JAN
2010

So I been working on behind the scenes on a new Widget version of my theme. It’s now live and it works great, but I had to make a number of modifications to the Widget system for it to work correctly.

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.

09
DEC
2009

I wished I used widgets. Why havn’t it? Because the coding around them is mostly hardcoded. Lets take a common scenario that I see all the time and from other people:

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.

read more ‘Widget Customization, Theme Controlled