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 Core vs Canonical Plugins
• The WordPress has-patch marathon
• The Xavisys WordPress Plugin Framework
• WordPress Developer Meeting – July 01, 2009
• WordPress 2.8 Release Date

The advantages to the “WordPress should stay small” philosophy are not limited to the WordPress download staying small (although that is one advantage). A smaller code base will make it easier to keep WordPress fast, reliable, and easy to test as well. The people that support this side of the argument would argue that WordPress could be extended to still accomplish any of the “missing” features through plugins and custom themes, and having built-in functionality that you don’t use is a waste.

The disadvantages are that many users (remember there are millions of WordPress blogs out there, many ran by people that are not tech savvy) are not comfortable with or even capable of installing plugins to solve their problems. For those people, having the functionality in the core WordPress install is probably the only way they’ll get to use it. Not to mention if 99% of people that install WordPress install a specific plugin, isn’t it obvious that the functionality provided by that plugin should be included in WordPress itself? Unfortunately, what if it’s 95%? 90%? 75? It’s hard to figure out where to draw the line. Additionally, if something is popular but doesn’t make it into core, should the programmers test against it before releasing new versions of WordPress or does that responsibility fall to the plugin author?

Obviously the advantages and disadvantages for the “WordPress should be feature rich” philosophy are the exact opposite. The problem is, both sides have valid arguments, so the real question becomes “is there something better?” I think canonical plugins may very well be the answer to that. The idea of canonical plugins is that WordPress would back a specific plugin as being the “solution” to a specific problem. For example, maybe you want to display related posts and WordPress has decided that “Efficient Related Posts” is the solution for that. They may have a list of commonly asked for features and their solutions on a page somewhere, or they may take it one step further and package the plugins with the official WordPress download.

I think that if they package some plugins with the official WordPress download, they may be very close to a great solution to this tiring debate. The advantages are that the core would stay lean, fast, and reliable. The functionality would be available to all users because it’s just a matter of activating the plugins rather than finding, downloading, and installing them. Also, the plugins that are shipped with WordPress would need to be tested with each new version, which means they’ll be stable as well. The only real disadvantage is that the download size would grow, but we live in the era of broadband. It seems a small price to pay to solve so many other problems.

Related Posts:

• How To Make Your Own WordPress Widget
• The WordPress has-patch marathon
• The Xavisys WordPress Plugin Framework
• WordPress Developer Meeting – July 01, 2009
• WordCamp San Francisco 2009

When I first showed up on Saturday, they weren’t even ready to check people in yet. I tend to be quite prompt, so I was there a few minutes before eight, and they were still alphabetizing name tags. Luckily there was a nice little place to sit, with power for my laptop and free wi-fi (unsecured to be exact…). The plan was to tweet about the experience as @wpinformer, which is the Twitter account for WordPress Informer where you’ll be able to read more detailed posts about each speaker I listened to. once they were ready I checked in, and just a few minutes later I was passing the check in tables and overheard them turning away walk-ins because they were already overbooked. I don’t know what the actual totals were, but I’m guessing there were about 800 people in attendance.

I ended up attending the welcome by Matt Mullenweg, “Cooking With BuddyPress” by Andy Peatling, “Straight from Google: What You Need to Know” by Matt Cutts, State of the Word by Matt Mullenweg, “Your Business Web” by Dave Gray of XPlane, “Customizing Themes and Plugins” by Ann Oyama, “Even Faster WordPress Themes” by Steve Souders, “FAILs, LOLs and User-Generated Content” by Scott Porad, “Lessons from Mozilla” by John Lilly, and the Goodbye by Matt Mullenweg. The fact that there were two tracks means that I missed a lot, but I was able to see pretty much everything I wanted to.

The tracks were upstairs and downstairs, with the main room being upstairs. The welcome by Matt Mullenweg was extremely quick and generic. It served as a kind of kickoff, but I honestly could have skipped it and just started downstairs at the first speaker.

The first real presentation I saw was “Cooking With BuddyPress” by Andy Peatling. You can read Why BuddyPress to get more detail about what I thought, but overall it was a really great session. Andy obviously knows what he’s talking about (he is the lead developer of BuddyPress), but he’s also good as conveying that knowledge to his audience. It was nice to hear a little of the history of the project (421 days to version 1.0) and some of the plans for the future (such as better BBPress installation), but the best thing was getting a quick overview of how BuddyPress worked, what it did, and how it could be extended and customized.

Next I went back upstairs to listen to “Straight from Google: What You Need to Know” by Matt Cutts. Matt is the head of Google’s Anti-webspam department. His job is to find those spam sites that plague the internet, and make sure that Google doesn’t offer you links to those kinds of sites in your search results. Since he spends so much time dealing with Google’s algorithms, he’s extremely current on best practices in Search Engine Optimization. The biggest thing to take away from this talk was that Matt said that WordPress is a “great choice” for SEO because it solves “80-90% of Search Engine Optimization (SEO).” That’s really saying something coming from one of the true experts out there.

After that, everyone came upstairs for “State of the Word” by Matt Mullenweg, whoch actually continued with a question and answer session after lunch. We got a lot of the normal history, WordPress was a fork of B2 and was later officially recognized by the B2 creator as the “official” continuation of B2, etc. There were a couple interesting WordPress facts such as that plugins were introduced in WordPress 1.2 and themes were introduced in WordPress 1.5. He also gave his summary of GPL Freedom to use software for any purpose, freedom to modify software, and freedom to redistribute. Then he talked about the fact that WordPress.org would be featuring themes that had paid support available, which he sees as perfectly in line with the essence of the GPL (and I agree). Alex King was brought up to talk a little about Crowd Favorite which now has eight full time staff in Denver and WordPress development and support is their primary revenue stream.

After the Q & A with Matt, I went downstairs to listen to “Growing Your Business Web” by Dave Gray of XPlane. Dave started by saying his slides sucked and wouldn’t be available for download, but I disagree. As a matter of fact, I loved “the internet according to Dave Gray” which spread pretty quickly across Twitter (so I’m not the only one). The whole talk was great, but was unfortunately cut short because he was going over his allotted time. It would have been nice to let him go a few more minutes, but I understand that they needed to keep things going.

Next up was “Customizing Themes and Plugins” by Ann Oyama, again downstairs. Ann was extremely nervous, and it showed. I was fine with that, I get nervous too. It seems like she knew most of the material, and I credited her nervousness with the bits that she seemed to leave out, skip over, or jumble up. Unfortunately, some of the information she gave was simply wrong. For example, functions.php and plugins are not really “the same thing.” They are loaded at different times, so they can do different things. For example, plugins are loaded before pluggable.php and can therefore override about 43 functions (depending on the version of WordPress) that functions.php cannot. Plugins can also modify settings before the global $wp_query is set up, which can be extremely handy. There are more differences as well, but that’s not really the point. Nervousness aside, there was some misinformation and while many of the people in the room will never need to know the differences (and some of the people there already knew), it’s still pretty unfortunate.

After Ann, things really picked up. Next was “Even Faster WordPress Themes” by Steve Souders, who wrote “High Performance Web Sites” and “Even Faster Web Sites” (both must reads in my opinion). Steve has spent time optimizing web performance for companies like Yahoo and Google, and he really knows his stuff. A lot of it was repeat info from his books, but it was definitely extremely useful information.

Following Steve was “FAILs, LOLs and User-Generated Content” by Scott Porad. He went over some of the highs and lows of having users generate your content for you. Steve Porad is the CTO at Pet Holdings, Inc. (aka lolcats) and I think everyone will agree that they’ve definitely succeeded at user generated content. They also run completely on WordPress.com, which really says something for WordPress.com.

For the last full session of the day I listened to “Lessons from Mozilla” by John Lilly. I loved his style of talking. He was a little ADD, running a lot of tangents…which reminded me of…well…me. He offered no “magic” key to succeeding as an open source project, which I respect because I don’t think one exists. However, he did give a good picture of what it’s like at the top of the food chain, with no one to copy or follow. It had been a long day, and I was tired, so I slacked off on tweeting as well as notes. I wish I hadn’t.

The day ended with the Goodbye by Matt Mullenweg. It was nearly as quick as the welcome, but by the end of the day it didn’t seem so bad. The big announcement? Don’t forget about the sixth anniversary party at the Automattic lounge. The party was nice, but let’s face it…we geeks aren’t all that outgoing. It seemed pretty dead by about 10pm when I left. So what was the best part of the conference? Definitely the developer day on Sunday, which I promise to write about soon.

Related Posts:

• Why BuddyPress
• Google's Matt Cutts on WordPress
• State of the Word from WordCamp – Part 2
• State of the Word from WordCamp – Part 1
• WordCamp San Francisco 2009

There are a lot of options out there. So many that it’s quite time consuming to try them all until you find one that suits you. Two of my favorites are WordPress Related Posts and Yet Another Related Posts Plugin (YARPP). Yarpp gives you more control over how matches are made, but for that very reason it’s also less efficient. Joost de Valk referred to it as a “heavy plugin” in his article on Optimizing WordPress database performance, and it definitely is. WordPress Related Posts is far more efficient, but offers you a little less control over how matches are made. Unfortunately they share the same problem.

So what is this problem? They all find matches to a post in the front end rather than the back end. They do it when a user views a specific post, rather than when a post is created or modified. On a brand new site I launched, which has only 7 posts, we’ve received roughly 2000 pageviews. That’s pretty low, but lets take a look at it. About 700 of those visits were to the home page and about 1300 were to single post pages. If you only show related posts on single post pages (which is how we currently do it) then the related posts plugin has been run over 1300 times for only 7 posts, which is roughly 185 times per post! If I were to show related posts for each post on the front page then it would have run another 4000 times (which is a conservative estimate), bringing it to 757 times per post. If you think this seems excessive, lets take a look at the stats for Web Developer News. It has had over 13,500 page views in the last 30 days. About 750 were to the home page, about 140 were to other static pages, roughly 550 were to tag pages, and another 250 were to miscellaneous pages such as search pages. That leaves 11,810 visits to single post pages and 21 posts during that same time. That’s about 562 times per post! If I added related posts to the home page, tag pages, and search pages it would need to be run roughly another 15,000 or 1,276 times per post.

In addition to the simple waste of memory and cpu cycles, putting the calculation of related posts on the front end means that when they start to slow down your users are left with a bad experience and slow loading pages. And they will slow down eventually, if your site gets big enough. I just recently worked on a site with more than 6,000 posts and over 1,800 tags (they offer investing advice, and have a lot of tags that correspond to ticker symbols). At that point, some of the related posts queries were taking 10 seconds to run. That’s really show. We can do better than that right? Well it’s not easy but I think we can.

I would always prefer that I (or my content creators) have to wait, rather than make my users wait. So, the logical solution would be to match related posts when a post is saved, and store them in the post’s meta data. Simple and solved right? Wrong. If that’s all you did, then posts would only ever be related to posts older than themselves. This would mean that part two of a series would likely relate to part one, but part one would never relate to part two. We solved the speed issue, but we took a huge hit in functionality. However, a plugin that I’ve developed and am testing takes it farther than that. When a post is saved, it’s related posts are saved, but all possible related posts are spidered and checked to see if they need to have new matches calculated for them.

For extremely large sites, the plugin still causes delays when you save a post. However, better you than your user. If you’re interested in using this plugin, I’ll be releasing it soon and I’ll add a link to it here when I do¹. However, for now I need a name for it! I originally called it Related Posts – High Volume because it was meant to fix issues on high-volume sites. However, since it can apply to almost any site, I’m looking for an inspired name that really lets people know what it can do. You can leave any ideas you have in the comment here or send them via twitter to @aaroncampbell or @wpinformer.

UPDATE:
The WordPress plugin has been released. You can download Efficient Related Posts from wordpress.org and you can read more about it at Efficient Related Posts at Xavisys.com

Related Posts:

• The Xavisys WordPress Plugin Framework
• 10 Great WordPress Plugins
• How To Make Your Own WordPress Widget
• Manual Related Links
• Efficient Related Posts

1. Efficient Related Posts

#8014 has been fixed as part of the marathon.

Now you can use dbDelta() with SQL containing backticks!

#9507 has been fixed

You can now localize the “tag” word in the new plugin page

#9408 has been committed

WAI-ARIA landmark roles have been added to the default theme to increase accessibility

#5710 – wp_tag_cloud should echo get_tag_cloud

For this one, my patch was replaced with a better solution offered by DD32 which added an echo option to the args array for wp_tag_cloud

#9472 – Fixed

Now wp_list_pages() applies the “current_page_item/parent/ancestor” classes when browsing image/attachment pages!

Some new filters were added

I always like to see new filters. It means that plugins can be more powerful. They added wp_trim_excerpt and admin_footer_text so far.

#9442 – Login UI

They added a password recovery link to the login error messages

Related Posts:

• How To Make Your Own WordPress Widget
• WordPress Core vs Canonical Plugins
• The Xavisys WordPress Plugin Framework
• WordPress Developer Meeting – July 01, 2009
• WordCamp San Francisco 2009

While I agree that 2.8 will have fewer noticeable new features than 2.7 did, it definitely has plenty packed into it. First, more than 270 tickets have been closed for 2.8, over 240 of those were set to “fixed”. Many of the changes in WordPress 2.8 are cleaning up what was added in 2.7, as well as strengthening the foundations of the core code.

The widgets code has been completely reworked and all the core widgets have been updated to use the new WP_Widget class. Personally, I think it’s pretty exciting! Previously, writing widgets that followed the multi-widget pattern (the ones that can be used more than once, like the text widget) was a real pain. Using the old widgets methodology, the text widget was 104 lines of code, and rather confusing. The new WP_Widget class has reduced that to 39 lines of considerably simpler code. I’m looking forward to updating my WordPress Twitter Widget, Gallery Widget Pro, and Get Free Web Designs Widget. I also plan to release a few new widgets using the new framework.

Another new feature in 2.8 that I find important, is support in the Admin UI for taxonomy descriptions. Currently in the WordPress admin interface, you can add descriptions to categories, but not for tags or any custom taxonomy. Since categories, tags, and other terms are all the same now, there’s really no reason you shouldn’t be able to control the description of all of them. The patch that was committed (which I submitted), adds a description box to the tag/taxonomy forms in the admin section, adds a description column to the tag and custom taxonomy tables in the admin, and adds two new helper functions for use in your theme called tag_description and term_description.

Here are some other things I find interesting that are new in 2.8:

• comments_popup_link() now works on pages and single posts – This is something that I ran into six months ago on a project I was working on. I found the ticket already submitted by JeremyVisser and submitted a patch.
• I’m a huge proponent of the fairly new WordPress Shortcodes. A couple advancements have been made there. Shortcode Escaping – If order to actually show a [shortcode] in your post you had to use [ to encode the [. Now you can use [[shortcode]] to do the same thing. Also, the caption shortcode can now have shortcodes inside it.
• Support arbitrary tag taxonomies with edit-tags.php – Basically, the tag interface in the admin section now works with custom taxonomies. This is huge for people setting up large complex sites. Recently I had to re-create a lot of this to set up a stock tickers taxonomy. This will make future development much simpler.
• Autosave post/page when pressing Control/Command+S in TinyMCE – this is really nice for those that are not experienced at blogging (or web-based computing in general). Almost everyone knows what Ctrl+S does, so implementing that simple functionality into WordPress is extremely handy.

In the end, the changes may not be as flashy as they were in 2.5 or 2.7, but 2.8 is a solid step forward for WordPress.

Related Posts:

• Acquia Puts Drupal in the News
• How To Make Your Own WordPress Widget
• WordPress Core vs Canonical Plugins
• WordCamp San Francisco 2009
• The Problem with Related Post Plugins

In my experience, most web developers and designers (especially those trying to begin a career) enjoy what they do. They usually start building small sites or themes as a hobby, often getting together with other like-minded people at sites such as Open Designs. They do what they do because they like it, but who can fault them for wanting to get paid for doing something they love? It’s the ultimate goal.

So what do you do? First off, you need to understand that it’s a highly saturated market, and you’re going to have to put in serious time and effort to turn this into a career. You’re going to be putting in 40 hours at work to pay the bills, and another 20-30 hours laying the foundation for your future career. If you aren’t ready to put in the time and effort, you can stop reading right now. This is not a get rich quick scheme, it’s a plan that you can follow if you’re really serious about it.

Now that you’ve agreed to put in the necessary effort, here are some steps to follow:

Step 1:
Register a domain name, and get some inexpensive hosting. You can get hosting through GoDaddy for less than $5/mo, and if you do, you can get a domain name from them for $2 for the first year. Install something like WordPress or Drupal on the site, and put up some general info. As you go, you will build this out into a portfolio, but you need to start somewhere.

Step 2:
If you haven’t already, you should join a community like Open Designs. If you are a designer, create and submit designs. You’re not looking for quantity, you’re looking for quality. Your designs need to stand out as better than all the rest. Be unique. Find out what you’re good at, and perfect it. While you are aiming for quality, quantity DOES matter. However, that won’t be a problem since you’re spending 20-30 hours per week doing this right? I’m sure you can turn out a design every week or two, so you worry about quality, and quantity will handle itself. Release your designs as public domain, but keep your absolute best design for yourself. Creative Commons is more hassle than it’s worth, and you want your designs to be used.

If you are not a designer, try to network with designers. Offer to code their designs into themes for common CMSs, etc. You probably won’t make it very far as a freelance programmer if you don’t have some designers you can use. Build relationships with the quality designers, and remember that quantity will handle itself as you put in those extra hours. Also try to post helpful tidbits in the forums and answer people’s questions when you can. Networking is important.

Step 3:
Continue to build the site you started in step one. Take your best design and add it to your site. If you are a developer, ask a quality designer if you can barter work for a custom design. Document your work on there. Not just a gallery, post some content. Walk a visitor through your design process or make a tutorial on converting a design to a theme. Make sure to set up a contact page with your info so clients can reach you.

Step 4:
Do some inexpensive work for hire. Consider finding a charity or a socially proactive business and do some work for almost nothing. Get used to working with clients and doing things up to their standards. An alternative to the charities is to try out a freelance website. The competition is massive, because the market is global, but if you’re persistent you can get work.

Step 5:
Go for clients with a vengeance. Make a form-style E-Mail that has information about you, links to your portfolio (which should look pretty good at this point), etc. Leave room at the beginning (NOT the end, this is important) for a personal note that will let the potential client know that you personally read and replied to their request. Find places where jobs are posted for work that you are especially good at. Consider finding niche places like a WordPress or Drupal job list where there may be less competition.

Don’t limit yourself to job lists. More than 80% of jobs are never posted anywhere. Find local businesses that have poor sites or no site at all, and take them a proposal (in person) with specific ways they will benefit from it. If they have a bad site, make sure to be careful what you say, it’s VERY common to hear an owner say “my {insert relative here} made that site for us” and you don’t want to be insulting. Base your argument on facts and statistics, possibly taking mockups or printouts of sites that are similar to what you are recommending.

Step 6:
Make the leap. At some point, you have to let go of your regular job and switch to this full time. I haven’t really found a rule of thumb for when this is. It’s different for every person. If you’re having a hard time deciding if you’re ready to drop the 9-5, consider getting a part-time job elsewhere and doing this full-time. Maybe the extra income will help ease the transition. Mostly remember that freelancing is still a job, it’s just one you like. And it’s not against the rules to like your job.

Related Posts:

• What's the best CMS?
• Acquia Puts Drupal in the News
• New Web Development Resource Launched
• How to Profit with the Open Source Community
• A Marketing Strategy You Can Believe In

1. Drupal
2. WordPress
3. Joomla
4. Media Wiki
5. Liferay
6. TYPO3
7. Moodle
8. Dolphin
9. Pligg
10. Movable Type

His conclusion was that Drupal edged out the top spot because of its ease of use, great support, and vast number of modules. He concedes that WordPress is a really a close second. I’m not sure I agree with his exact order, but I’m biased because I’ve been developing on WordPress for years and I’m very familiar with it. I’d probably put the top three like this:

1. WordPress
2. Drupal
3. Movable Type

Of course, with the introduction of Acquia to the scene, that may change in the near future. Either way, the article is a great read.

Related Posts:

• Acquia Puts Drupal in the News
• Becoming a Freelance Web Developer/Designer
• Reorder Gallery now in WordPress Core
• Adobe's take on WordPress vs MovableType
• The Heart of Open Source

He talks about Acquia, a new company that was launched by Dries Buytaert, founder of Drupal. It will offer commercial support for Drupal. It seems that Acquia plans on supporting Drupal much the same way that Automattic supports WordPress and SixApart supports Movable Type. With this kind of support available to our clients, Xavisys will now be offering Drupal solutions in addition to the WordPress and custom solutions already offered.

Related Posts:

• What's the best CMS?
• Exciting new things in WordPress 2.8?
• Becoming a Freelance Web Developer/Designer
• Adobe's take on WordPress vs MovableType
• The Heart of Open Source

So, what’s the bid deal? Well, in the process the jQuery library that WordPress uses was upgraded to 1.2.5, and the jQuery UI was added! This will be good news for any developers that make plugins for use in the admin section of WordPress, or who prefer to use jQuery over Prototype in their plugins.

Related Posts:

• What's the best CMS?
• The Heart of Open Source
• How to Profit with the Open Source Community
• WordPress 2.5 Shortcodes
• How To Make Your Own WordPress Widget