category: wordpress development


I took the dive today and moved this site into WordPress 3.0 Development trunk way ahead of the feature freeze date. I been monitoring the commits, and while I haven’t done much except for the few patches I have submitted the code is very stable.

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!


WordPress Testing Solution

Posted by Shane

One of the problems the core developers have of WordPress is the amount of testing that goes on. Since this is free/open source software, users usually do not try software that they can get free. When its paid software they fell like it’s an obligation to make sure that they are getting their’s money worth before having it officially released as the ‘offical’ version.

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.
read more ‘WordPress Testing Solution


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.


WordPress 2.9, Official

Posted by Shane

Wow. That was fast. Not less than 72 hours ago we released RC1 of 2.9 and we got such a good response from testing that we decided to skip the two week testing period for a release of WordPress 2.9 “Carmen”. Early Holiday Present. So get it today using the automatic upgrade feature.

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, be sure you have at least MySQL version 4.1.2.  All backwards compatibility was taken out of 2.9.


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 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


This subject is not very well documented anywhere in the WordPress Codex or online. I only found one site that talked about a custom walker class.

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.

read more ‘WordPress Custom Walker Tutorial


Just want to let all you fellow WordPress users know that while I was at WordCamp NYC 2009, I did talk for a few minutes with Matt about a potential new media system. A while back I posted up a wireframes document. That version is now way outdated and been working on a new version since the end of WordCamp.

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.