category: wordpress development


WordPress & HTML5

Posted by Shane

I am hoping a lot of you out there that read my blog are design and wordpress users because changing your site to conform to HTML5 will not be that hard. I have changed 3 lines.

Index: E:/My Site/Code/trunk/header.php
--- E:/My Site/Code/trunk/header.php    (revision 252)
+++ E:/My Site/Code/trunk/header.php    (working copy)
@@ -1,6 +1,6 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
-<html xmlns="" <?php language_attributes(); ?>>
-<head profile="">
+<!DOCTYPE html>
+<html <?php language_attributes(); ?>>
 <title><?php wp_title(' | ', true, 'right'); ?><?php bloginfo('name'); ?></title>

 <meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />
@@ -59,7 +59,7 @@
 <div id="content">
 <div id="logo">
-        <a id="site-link" href="/" title="<?php bloginfo('name'); ?> | <?php bloginfo('description'); ?>" />
+        <a id="site-link" href="/" title="<?php bloginfo('name'); ?> | <?php bloginfo('description'); ?>"></a>
 <div id="header-navigation">
 <ul id="main-navigation">

After that it was pretty much valid for HTML5 through out the entire site. Pretty sweet huh? Oh.. site validates now with HTML5. :) You should still run your site through the vaildator to make sure that nothing else is messed up, but all my pages complied the first time and that was from XHTML 1.0 to HTML5.


When you are writing a plugin that uses Ajax in the front end, you must use:

add_action( 'wp_ajax_nopriv_<ACTION NAME>', <YOUR FUNCTION> );

…as doing…

add_action( 'wp_ajax_<ACTION NAME>', <YOUR FUNCTION> );

… is only for logged in users. So if you have a plugin that operates no matter which way users interface with the plugin, you must provide both action calls to make sure it all gets processed. Helpful tip. :)

Will be back shortly…


So I thought I give you all an update. I am still traveling back and forth between NY to MN for work, working on web design and other related Best Buy/Geek Squad issues. It has been frustrating to say the least to fly back every two weeks. I am meeting tons of new people while in Minnesota. Starting tomorrow I will be staying for an entire month, but I was allowed to have the entire week off from April 30 through May 10th. It just so happens that it falls during my birthday. I also have a wedding to attend to in Boston that week, so it works out perfectly.

read more ‘So it’s been a while since I posted something


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


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:

  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.