So, if you want to know how to best use WordPress’s built in http class to integrate with an existing API, how to add your own taxonomies to your site, how to make your theme more extensible, or almost anything else WordPress related, please just ask!

Related Posts:

• How To Make Your Own WordPress Widget
• Speaking at WordCamp San Francisco 2011
• Google Summer of Code 2010
• WordPress Core vs Canonical Plugins
• WordCamp San Francisco 2009

Following the WordCamp event, my wife and I went to one of the best food and wine events we’ve ever attended. It was at a place called One Market, and was put on by The American Institute of Wine & Food. We had lamb starting with the tongue and cheek, working our way back to the leg. Each course was paired with one or two wines from the Zacherle or Fisher labels, and the wine makers were there to talk about each wine and answer our many questions (who knows what a “brick” is in wine making, and why some wines need fewer bricks than others?). It was a beautiful, fancy, entertaining dinner.

When we finished that, we caught a cab over to the Automattic Lounge at Pier 38 to catch part of the WordCamp after party. Talk about a shock to the system. We left a place where lamb was being served to people in suits and fancy dresses who were seated at tables with linens and full silverware sets, and within minutes we were at a party with blaring music and full of geeks, many of who had consumed considerably more alcohol than recommended. We spent a little time saying hi to everyone, having a few laughs at the expense of the imbibed (you know who you are), and I got my picture taken with several people (I’m not sure any of them knew who I was, they just seemed to like posing with someone and getting their picture taken). We left relatively early, around midnight, and headed back to the hotel. I knew from the year before that the developer day was going to be my personal favorite part of the event, and I didn’t want to be falling asleep at the laptop all day.

The following morning I arrived back at the Pier 38 lounge to find that I was the first to arrive for the developer day (I was a few minutes early). Ryan Boren was the next to show, but we ended up having to wait a little longer until someone with keys arrived. I’m not sure people really got the “unconference” thing, as everyone kept wanting to know what was scheduled for when, and where things would be happening. The basic idea is simply “find people that want to discuss what you want to discuss, form a group, and discuss it.” Eventually a group of us formed at one of the tables and began working on WordPress 3.0. I’m sure I can’t name everyone, but I know Dion Hulse, Ryan Boren, Andrew Nacin, Matt Martz, Pete Mall, John Jacoby, and Ptah Dunbar were all there. Dion and I spent several hours on an elusive bug with a rather simple fix, and it was really great to finally get to put faces with the names and handles that I see regularly on IRC, mailing lists, Trac, etc.

After the dev day coding, several of us walked down to Gordon Biersch, had dinner together and tried not to talk about WordPress too much (although Andrew Nacin’s like a machine…you just can’t stop the man!). So, what do you think we would do after a long day of coding? Well, we’re geeks, so we walked to one of the hotels were a few of the guys were staying, went up to their lounge, and started doing some more coding. As a guy who works from home and tends to work only with remote programmers, it was really nice to spend some time with people that understood what I was saying! I’m looking forward to seeing everyone again next year.

Related Posts:

• Speaking at WordCamp San Francisco 2011
• WordCamp Phoenix 2011 – A Developers Take
• Google Summer of Code 2010
• The Xavisys WordPress Plugin Framework
• How To Make Your Own WordPress Widget

This year there are a lot of great students and projects. I’m definitely excited to see what happens with all of them. However, I’m most excited about the student that I’m going to be mentoring. Jon Stacey is going to be implementing stream wrappers into the WordPress file API. He did a similar project for Drupal as part of GSoC last year, and this year we were able to woo him over to WordPress.

Not only does the project have great potential, but since stream wrappers were introduced in PHP 5, it will help push WordPress toward PHP 5 as a minimum requirement (which I’m all for). So good luck to Jon and all the 2010 GSoC students.

Related Posts:

• How To Make Your Own WordPress Widget
• WordPress Core vs Canonical Plugins
• The WordPress has-patch marathon
• Speaking at WordCamp San Francisco 2011
• WordPress Q & A

The widget we’ll be creating will display upcoming posts (scheduled posts). A lot of sites schedule posts to automatically publish at a specific time, helping them keep a steady flow of articles. I know that I use this trick on Web Developer News and Attackr, and I’ll use it on this site as soon as I get some more articles written. Since the articles are already there and ready to be posted, why not tease them and give your readers something to look forward to? That’s exactly what this widget will do.

To start, you need to create a class for your widget that that extends WP_Widget. We’ll be using WP_Widget_Upcoming_Posts. Then you should hook into the widgets_init action and use register_widget() to register your new widget. The bare bones skeleton looks like this (and does nothing but throw a warning):

/**
 * Upcoming_Posts widget class
 */
class WP_Widget_Upcoming_Posts extends WP_Widget {
	// Our Widget methods will go here
}
function registerUpcomingPostsWidget() {
	register_widget('WP_Widget_Upcoming_Posts');
}
add_action('widgets_init', 'registerUpcomingPostsWidget');

Now, there are a few methods that you need to create. The first needs to be named the same as the class (WP_Widget_Upcoming_Posts in this case), which will be used to instantiate the widget. Do not use the PHP5 __construct, as the WP_Widget class uses that and you end up with an infinite loop if you do. Second, you must create a widget method, which is used to actually manage and display your widget. In our case we’ll also be overloading the update method to handle updates to widget settings and the form method which is used to display the setting form on the widget admin page. I’m going to go through each method, explain the code, and then put it all together.

First, the WP_Widget_Upcoming_Posts method:

function WP_Widget_Upcoming_Posts() {
	$widget_ops = array('classname' => 'widget_upcoming_entries', 'description' => __( "List scheduled/upcoming posts", 'upcoming_posts_widget') );
	$this->WP_Widget('upcoming-posts', __('Upcoming Posts', 'upcoming_posts_widget'), $widget_ops);
}

First, we set up the options for the widget. We set the classname to widget_upcoming_posts. This will be added to the li tag of the widget when it’s displayed. We also set the description, which is displayed when the widget box is expanded in the available widgets section of the new widgets admin page. These options are passed to WP_Widget along with the id base (upcoming-posts) and the widget name (Upcoming Posts).

function widget($args, $instance) {
	extract($args);

	$title = empty($instance['title']) ? __('Upcoming Posts', 'upcoming_posts_widget') : apply_filters('widget_title', $instance['title']);
	if ( !$number = (int) $instance['number'] )
		$number = 10;
	else if ( $number < 1 )
		$number = 1;
	else if ( $number > 15 )
		$number = 15;

	$queryArgs = array(
		'showposts'			=> $number,
		'what_to_show'		=> 'posts',
		'nopaging'			=> 0,
		'post_status'		=> 'future',
		'caller_get_posts'	=> 1,
		'order'				=> 'ASC'
	);

	$r = new WP_Query($queryArgs);
	if ($r->have_posts()) :
?>
	<?php echo $before_widget; ?>
	<?php echo $before_title . $title . $after_title; ?>
	<ul>
	<?php  while ($r->have_posts()) : $r->the_post(); ?>
	<li><?php if ( get_the_title() ) the_title(); else the_ID(); ?><?php edit_post_link('e',' (',')'); ?></li>
	<?php endwhile; ?>
	</ul>
	<?php echo $after_widget; ?>
<?php
	endif;
	wp_reset_query();  // Restore global post data stomped by the_post().
}

The first thing we do is extract $args, which gives you $name, $id, $before_widget, $after_widget, $before_title, $after_title, $widget_id, and $widget_name. We’ll use those throughout the rest of the function. Next we set $title. If it was specified in the settings for the widget, then use use it and apply the widget_title filter to it. If a title wasn’t specified, we use “Upcoming Posts”.

Next, we deal with the number of posts to display. If nothing was specified in the widget settings, we set $number to 10. If the user did specify the number of posts to display, we do some sanity checks to make sure that the number is at least 0 and no more than 15. This isn’t absolutely necessary, but it’s nice to set some limits to things don’t get out of hand.

Now we need to prepare to actually query the database and retrieve the posts. In order to get the posts we want, we set the following:

showposts

This sets the number of posts to display.

what_to_show

This specifies what items to retrieve from the database. We want posts, not pages, attachments, revisions, etc.

nopaging

If the blog is set up to show fewer posts per page than we’re trying to get, paging would interfere. We turn it off just to be safe.

post_status

Since this plugin displays scheduled posts, we need to make sure that the post status is future, not published, draft, etc.

caller_get_posts

This is to make sure that sticky posts aren’t re-ordered to the top.

order

The order defaults to descending, which means it displays post with the highest (most futuristic) date first. We want to display the next post (oldest scheduled post) first, so we set this to ASC for ascending.

Now that all the options are set, we run the query. We want to make sure that all output is inside the have_posts loop, so that if no posts are returned the widget doesn’t display (rather than showing the title with no posts). In order to fit within all themes, you want to make sure to always echo your output in this order: $before_widget, $before_title, $title, $after_title, your widget content, $after_widget. A theme can customize each of those before and after items to create the proper markup for their design, so it’s important to use them. Our widget content is simply an unordered list of posts. The only little extra I added is the edit_post_link(), which will display a link to edit the post if you are logged in with sufficient permissions. The last thing we do is reset the query, so that our widget query doesn’t mess up other queries.

The next method we need to set up is the update method. Technically this isn’t actually required, but it gives us a chance to sanitize input.

function update( $new_instance, $old_instance ) {
	$instance = $old_instance;
	$instance['title'] = strip_tags($new_instance['title']);
	$instance['number'] = (int) $new_instance['number'];

	return $instance;
}

As you can see, we strip tags from the title and make sure that number is and integer. You’ll notice that we take the old instance and update it with info from the new instance. This makes sure that no one tries to sneak in extra data by modifying the form on the widget admin page. It’s not necessary, but it’s a little more secure.

The last thing we need to do is set up the form method, which actually displays the settings on the widget admin page.

function form( $instance ) {
	$title = attribute_escape($instance['title']);
	if ( !$number = (int) $instance['number'] )
		$number = 5;
?>
	<p><label for="<?php echo $this->get_field_id('title'); ?>">
	<?php _e('Title:'); ?>
	<input class="widefat" id="<?php echo $this->get_field_id('title'); ?>" name="<?php echo $this->get_field_name('title'); ?>" type="text" value="<?php echo $title; ?>" /></label></p>

	<p><label for="<?php echo $this->get_field_id('number'); ?>">
	<?php _e('Number of posts to show:'); ?>
	<input id="<?php echo $this->get_field_id('number'); ?>" name="<?php echo $this->get_field_name('number'); ?>" type="text" value="<?php echo $number; ?>" /></label>
	<br /><small><?php _e('(at most 15)'); ?></small></p>
<?php
}

Since we will be putting the title into the value attribute of an input element, we want to make sure it’s safe to do so by using attribute_escape() first. Then we make sure that number is an integer and set it to 5 if it does not exist (this doesn’t actually set the widget settings to 5, it just displays a 5 in the form field rather than leaving it blank, giving the user and idea of what’s expected). Then we break out of PHP and actually display the form. The format I use is the default and will make your widget blend with the ones included with WordPress. It goes like this (with and without “hint text”):

<p>
	<label>
		Label Text
		<input>
	</label>
</p>

<p>
	<label>
		Label Text
		<input>
	</label>
	<br />
	<small>
		Hint Text
	</small>
</p>

That’s it! Your widget is done, it matches the existing widgets, and can be dropped into any widget-ready section of a WordPress 2.8+ blog! Download a slightly more advanced version of the Upcoming Posts Widget that includes caching, and try it out! you can also see the widget completed below:

/**
 * Upcoming_Posts widget class
 */
class WP_Widget_Upcoming_Posts extends WP_Widget {
	function WP_Widget_Upcoming_Posts() {
		$widget_ops = array('classname' => 'widget_upcoming_entries', 'description' => __( "List scheduled/upcoming posts", 'upcoming_posts_widget') );
		$this->WP_Widget('upcoming-posts', __('Upcoming Posts', 'upcoming_posts_widget'), $widget_ops);
	}

	function widget($args, $instance) {
		extract($args);

		$title = empty($instance['title']) ? __('Upcoming Posts', 'upcoming_posts_widget') : apply_filters('widget_title', $instance['title']);
		if ( !$number = (int) $instance['number'] )
			$number = 10;
		else if ( $number < 1 )
			$number = 1;
		else if ( $number > 15 )
			$number = 15;

		$queryArgs = array(
			'showposts'			=> $number,
			'what_to_show'		=> 'posts',
			'nopaging'			=> 0,
			'post_status'		=> 'future',
			'caller_get_posts'	=> 1,
			'order'				=> 'ASC'
		);

		$r = new WP_Query($queryArgs);
		if ($r->have_posts()) :
	?>
		<?php echo $before_widget; ?>
		<?php echo $before_title . $title . $after_title; ?>
		<ul>
		<?php  while ($r->have_posts()) : $r->the_post(); ?>
		<li><?php if ( get_the_title() ) the_title(); else the_ID(); ?><?php edit_post_link('e',' (',')'); ?></li>
		<?php endwhile; ?>
		</ul>
		<?php echo $after_widget; ?>
	<?php
		endif;
		wp_reset_query();  // Restore global post data stomped by the_post().
	}

	function update( $new_instance, $old_instance ) {
		$instance = $old_instance;
		$instance['title'] = strip_tags($new_instance['title']);
		$instance['number'] = (int) $new_instance['number'];

		return $instance;
	}

	function form( $instance ) {
		$title = attribute_escape($instance['title']);
		if ( !$number = (int) $instance['number'] )
			$number = 5;
	?>
		<p><label for="<?php echo $this->get_field_id('title'); ?>">
		<?php _e('Title:'); ?>
		<input class="widefat" id="<?php echo $this->get_field_id('title'); ?>" name="<?php echo $this->get_field_name('title'); ?>" type="text" value="<?php echo $title; ?>" /></label></p>

		<p><label for="<?php echo $this->get_field_id('number'); ?>">
		<?php _e('Number of posts to show:'); ?>
		<input id="<?php echo $this->get_field_id('number'); ?>" name="<?php echo $this->get_field_name('number'); ?>" type="text" value="<?php echo $number; ?>" /></label>
		<br /><small><?php _e('(at most 15)'); ?></small></p>
	<?php
	}
}
function registerUpcomingPostsWidget() {
	register_widget('WP_Widget_Upcoming_Posts');
}
add_action('widgets_init', 'registerUpcomingPostsWidget');

Related Posts:

• WordPress Q & A
• Google Summer of Code 2010
• WordPress Core vs Canonical Plugins
• The WordPress has-patch marathon
• Speaking at WordCamp San Francisco 2011

For WordPress 2.9, they’ve decided to raise the version of MySQL supported from 4.0 to 4.1.2! That may not seem like much to those of us out there using the latest versions of everything, since version 5.1 is out, 5.4 is in beta, and even 6.0 is under development (and because 4.1.2 was released in May of 2004). However, the big thing that sticks out to me is that 4.1 support subqueries and unicode. Unicode should help for people that are using WordPress in non-English languages, and subqueries should help to greatly simplify queries. Also in 4.1 MySQL added support for the ‘INSERT … ON DUPLICATE KEY UPDATE’ syntax which will insert a new row unless that would cause a duplicate primary or unique key, in which case it updates the existing row.

I’m looking forward to the next few versions of WordPress, which I predict will get considerably faster (and the codebase will probably lean out a little too) simply because of the additional MySQL functionality. Just remember that there’s a lot to do and not every query will be updated in 2.9 to take advantage of the new versions. Also, for those that are worried, they plan to add a check to the automatic upgrader to keep people from upgrading to 2.9 if they don’t have a new enough version of MySQL.

Which brings me to the next big decision. While WordPress is not going to require PHP 5, they are going to suggest it. If someone is still running PHP 4, the WordPress upgrader will suggest that they switch to PHP 5, and will even link to a Codex page describing how to do it for various hosts! As someone who’s been a huge proponent of moving the PHP requirements up to PHP 5, this is a big step in the right direction. According to Matt Mullenweg at WordCamp San Francisco 2009, over 80% of WordPress.org users are already on PHP 5+. If a notice like this could raise that percentage enough to make it reasonable to require PHP 5+, the codebase will see some huge improvements.

Overall, the meeting (which I unfortunately missed) took some great steps toward serious improvements of WordPress both in 2.9 and the versions to follow.

Related Posts:

• Looking forward to WordPress 2.9
• WordPress 2.8 Release Date
• WordPress Weekly Podcast
• Improve Performance of Your WordPress Theme in 5 Minutes
• WordPress 2.8 Brings Back Drag and Drop Widget Management

Related Posts:

• WordPress 2.8 Brings Back Drag and Drop Widget Management
• How To Make Your Own WordPress Widget
• Looking forward to WordPress 2.9
• News About WordPress 2.9

The process goes something like this. On May 23rd the students begin coding, and receive their first payment of $500. On July 13th they have “Mid Term Evaluations” where the mentor evaluates the student, and the student evaluates both the mentor and the project. At this point, if the student isn’t performing, they will be dismissed, but the vast majority of students will continue and receive their second payment of $2000. On August 17th the students stop coding. On August 26th there is a final evaluation which works just like the mid term evaluations worked. The student now receives their final $2000. On September 3rd, the code must be submitted to Google.

WordPress has participated for the last three years, and recently the Summer of Code students were announced, along with their projects and mentors:

Justin Shreve, Extended WordPress Search Engine. Justin will be mentored by Andy Skelton. One of the complaints I hear over and over again is about the search engine, so this could have great benefit to WordPress core.

Rudolf Cheuk Sang Lai, Adding Photo Grouping by Album Functionality. This project will wind up being a piece of a larger media redux project for 2.9/3.0. Mark Jaquith is mentoring, and Noel Jackson will be a backup mentor.

Daryl Koopersmith, WYSIWYG theme editor/generator. This will allow users to create and edit themes without touching any code. Beau Lebens is the mentor on this project.

Michael Benedict Arul will be working on a similar project. Michael will be mentored by Andrew Ozz, since this project will be using jQuery. It’s our hope that having two students working on this idea separately will foster competition and allow us to compare approaches.

Daniel Larkin, Modified Preorder Tree Traversal (MPTT). Lead Developer Ryan Boren will be his mentor. This is Daniel’s second GSoC working on WordPress.

Diego Caro, a student from Chile, will also work on an MPTT project. Diego will be mentored by Thorsten Ott.

César Rodas, social and text processing algorithms for BuddyPress and MU as related to recommendation engines. Alex Shiels and Andy Peatling will co-mentor this project.

Anthony Cole, Event management with WordPress. Co-organizer of WordCamp Australia and New Zealand, Anthony will be working on a suite of plugins (or maybe just one or two out of a planned set, scope TBD) for event management/attendee networking that will be built on BuddyPress/MU/bbPress. We’ll use wordcamp.org as a test case, and release the final product to the community. Jake Spurlock will be mentoring, with Andy Peatling as backup.

That’s eight students, which means Google is investing $36,000 into WordPress this summer! This year we should see some great benefits from this process, including improved search functionality, implementation of the modified preorder tree traversal algorithm (which should help simplify some of the queries WordPress makes), and even some improvements to BuddyPress.

Related Posts:

• Google Summer of Code 2010
• The Xavisys WordPress Plugin Framework
• How To Make Your Own WordPress Widget
• WordPress Core vs Canonical Plugins
• WordPress Developer Meeting – July 01, 2009