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!
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.
Right now there is no plans to have jQuery updated to 1.4.0 in WordPress 3.0. It is not impossible, but very unlikely due to fact that it does not cover the WordPress 3.0 Scope of Work.
Use jQuery at your own risk and if you do use it, unload jQuery 1.3 first before registering jQuery 1.4.
wp_deregister_script( 'jquery' );
wp_register_script( 'jquery', '<Location of jQuery 1.4>', false, '' );
I will bring this up at the next dev meeting, but as of right now there is no jQuery 1.4 in WordPress 3.0.x.
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:
- 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.
- 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.
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 WordPress.com, be sure you have at least MySQL version 4.1.2. All backwards compatibility was taken out of 2.9.
WordPress 2.9 RC1 is out and ready for use and abuse! Please update all live sites using WordPress to this version so we can now get a huge sampling on any other errors before we mark it ‘GOLD’!. Be sure to submit tickets to the trac site so we know about them.
The faster we can get reports back, the faster we can give you an early present for the holidays and for the New Year!
Translators: You have two weeks to get your translations into the system before Gold. Thanks!
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.
