It’s no understatement to say that I became a web developer because of WordPress. I started blogging with Blogger in 2005, only to become frustrated and move myself over to self-hosted WordPress. I used the old K2¹ theme as the basis of my own theme, and tweaked it obsessively. WP provided just the right amount of ease and power for where I was at, and revealed all the more power the further I dug. Tweaking your WP template is a web development gateway drug.

The rest is a blur. I graduated from SSU with a BA (Honours) in the Humanities in 2008, having tinkered along the way with my ever-intriguing WP blog. I even did my first paid work on my school’s website, attempting to wrangle some disastrous table-based Dreamweaver templates into some semblance of tolerable. By the time I graduated with my gloriously useless degree², I realized that I could make better web sites than the majority of what I saw out there. So I took the plunge into freelancing with zero experience, connections, or prospective clients. And, many bumps in the road and umpteen trips to the codex later, it actually worked out.

I’d especially like to thank my friend and collaborators Modern Tribe and David Pensato, with whom I’ve had the opportunity to do a lot of fun and meaningful work over the last few years. I’d also like to thank the Winnipeg-based Automatticians Ian Stewart and Krista Stevens for slowly convincing me that I should apply. And of course, a huge thank you to the countless people who have contributed of their time, skills, and passion to the WordPress project.

I’m looking forward to this next chapter. I get to iterate and improve rather than build and hand off, and work with super smart people every day. And my work will be seen my millions of people. Fun. I start on Monday.

And, here’s the links from the last slide in clickable form:

• http://blog.typekit.com/2010/10/15/type-rendering-operating-systems/
• http://www.typotheque.com/articles/hinting
• http://www.fontslive.com/info/typography/web-font-quality.aspx
• http://www.lucasfonts.com/fonts/thesans/thesans-office/features/
• http://cl.ly/9PBw
• http://www.freetype.org/ttfautohint/
• https://github.com/typekit/webfontloader/
• http://somadesign.ca/projects/fontfriend/

I’ve already criticized the WordPress.org Theme Review process when it first launched. Things seemed to be improving, but either the team is poorly organized, severely under-powered, or both.

The Erudite 3.0 has been in review for 3 months, 3.0.2 since Sept 28. The review ticket was assigned 5 weeks ago, but still no movement.

If you are savvy enough, download 3.0.2 from the project page. There’s a security issue in the current theme that makes updating a priority. You’ll need to install and activate the Options Framework to change any theme settings.

NOTE: you will lose your previous settings when upgrading. Annoying, I know, but the old settings framework was rickety and awful.

Firstly, you can grab the theme on GitHub. I’d probably even submit it to the official WordPress.org themes directory, except that it still doesn’t list child themes (it likely will in the future).

Secondly, you can grab the slides on Speaker Deck (or view below). And, if you’re interested in watching me present, there’s the archived livestream video.

Finally, here’s a few useful links from my presentation, and a few others for folks who want to go deeper:

• More Fields plugin
• Winnipeg WordPress Meetup
• Plugin & Theme Security Video (by Mark Jaquith)
• WP security & escaping functions
• WP Data Validation
• FlexSlider (the JavsScript library powering the portfolio slideshow)

Kill Adminbar Search

WP 3.1 introduced the admin bar, which is generally quite useful. However, because WordPress’s search is generally not useful, having the search field take up so much real estate is somewhat frustrating. So, I made a plugin to remove it. You can download Kill Adminbar Search from the plugins repo.

Use Helvetica Dangit

WP 3.2 (currently in beta 2) has revamped the admin styles. It looks good, but we’ve made the grievous error of placing Arial before Helvetica in the font stack, which I protested. What we should do instead is simply declare font-family: sans-serif; and be done with it: this would render Helvetica Neue on Macs, Arial on Windows, and whatever Helvetica-like default system sans-serif is set on any given Linux distro. But, since my plugin is optional, I’ve declared every Helvetica variant under the sun, because nobody should have to look at Arial if they don’t have to. Download Use Helvetica Dangit from the plugins repo.

So, I made my own little plugin. I didn’t want another plugin settings page, so you have to hardcode your Lessn URL and API key. It integrates with the “Get Shortlink” button on your write/edit post screen, and the relevant shortlink HTTP header and meta elements are auto-inserted. Only the “post” post_type will get Lessn’d by default, but see the bottom of the plugin for how to add additional post_types.

<?php
/*
	Plugin Name: Lessn Shortlinks
	Description: Integrates WP's shortlink functionality with the <a href="http://lessnmore.net/">Lessn More</a> URL shortener. <em>Hasn't been tested with vanilla Lessn, but the API should be compatible.</em> (Edit the file manually to configure)
	Version: 1.0
	Author: Matt Wiebe
	Author URI: http://somadesign.ca/
*/

/**
 * SD_Lessn class: integrates WP's shortlink functionality with the Lessn More
 * URL shortener.
 * 
 * @uses Lessn More @link http://lessnmore.net/
 * @author Matt Wiebe
 * @license GPL 2
 * 
 **/

class SD_Lessn {

	const API_KEY = 'apikey'; // your Lessn API key
	const LESSN_API_BASE = 'http://shorturl.com/-/'; // the API base for your Lessn install
	const META_KEY = '_lessnd_url';

	private $allowed_types = array('post');

	function __construct() {
		add_action('publish_post', array($this, 'get_lessnd_url'), 10, 1 );
		add_filter('get_shortlink', array($this, 'get_shortlink'), 10, 3 );
	}

	public function add_post_type( $post_type = '' ) {
		if ( $post_type )
			$this->allowed_types = array_merge( $this->allowed_types, (array) $post_type );
	}

	public function get_lessnd_url( $post_id ) {
		if ( 'publish' !== get_post_status($post_id) )
			return false;

		if ( ! in_array( get_post_type($post_id), $this->allowed_types ) )
			return false;

		if ( $url = get_post_meta( $post_id, self::META_KEY, true) )
			return $url;

		$params = array(
			'api' => self::API_KEY,
			'url' => get_permalink($post_id)
		);
		$api_url = add_query_arg($params, self::LESSN_API_BASE);

		$get = wp_remote_get($api_url);

		if ( is_wp_error($get) )
			return false;

		$lessnd_url = wp_remote_retrieve_body($get);

		if ( $lessnd_url ) {
			update_post_meta( $post_id, self::META_KEY, $lessnd_url );
			return $lessnd_url;
		}
		return false;
	}

	/**
	 * @param int $id A post or blog id.  Default is 0, which means the current post or blog.
	 * @param string $contex Whether the id is a 'blog' id, 'post' id, or 'media' id.  If 'post', the post_type of the post is consulted.  If 'query', the current query is consulted to determine the id and context. Default is 'post'.
	 */

	public function get_shortlink( $shortlink, $id, $context ) {

		if ( 'query' == $context ) {
			global $wp_query;
			if ( is_singular() ) {
				$context = 'post';
				$id = $wp_query->get_queried_object_id();
			}
		}

		if ( 'post' !== $context )
			return $shortlink;

		// Try Lessn'd url.
		if ( $try_lessn = $this->get_lessnd_url($id) )
			return $try_lessn;
//		do_action('elog', $shortlink);
		return $shortlink;
	}
}

$sd_lessn = new SD_Lessn;

// uncomment line below to add support for the "page" post_type
// $sd_lessn->add_post_type('page');

Now, I just need to figure out how to integrate shortlinks for humans rather than just machines.

My presentation was on Doing Things the WordPress Way, which covered a few things I’ve picked up along the way as a WP developer. A few people asked for the slides, so here they are:

Doing Things the WordPress Way (on Slideshare)

Big thanks to Ian Stewart for organizing the event, and to the Digihedron crew for hosting us. Subscribe to the Winnipeg WordPress meetup blog for updates about future events.

HT Rick from Stylesheeter

If you only upgrade through the WP admin panel, you can check the changelog on the project page to see what’s changed since 2.7.2 (the last release approved on the theme directory).

High standards are a great thing. Overall I think that the theme team has done a good job with that document. But jeez, reading it makes me tired — it keeps going and going. It creates a massive load for theme developers and theme reviewers. It sure would be nice if the a lot of the items on the required list were on the recommended list.

Here’s a specific one: requiring the use of comment_form() is dumb. It was only introduced in 3.0, while my theme should currently be backwards compatible with 2.7 (with some degradation). Sure, comment_form() is a great function, and if I were writing The Erudite again, I’d use it. But requiring it? Dumb. Some numbers to back that up: as of right now, only 39.8% of WP users are on 3.0.

And what about an interesting theme like Quality Control? Something tells me it fails on a number of requirements simply due to it not being a blog, but it was approved after the new requirements were in place. It must have been approved because it’s a cool use of WP despite the requirements.

But my biggest problem here is that the bar to participation in the WP community is being raised too high. If I were starting to write this theme again, I would take one look at the requirements and look for some other way to spend my time. This is not the way for a community to welcome new participants.

What I’m saying is that we need to embrace amateurism in the WordPress community. You don’t get to be a professional without being an amateur first, and the new guidelines just might prevent a whole lot of folks from bothering to start that journey. I understand that the WP community is trying to act like an adult these days, which is great. But let’s not lose that sense of discovery and exploration that allowed us to get started in the first place.

Finally, as a practical consideration, perhaps we could add a “blessed” (i.e. meets recommended requirements) flag to the themes repo. Themes that do so are implicitly more trustworthy, and will be promoted more heavily on the repo. This allows amateurs to get their theme out to a wider audience, while not having a “blessed” status clearly reveals that these amateur themes might not contain all the functionality that a “blessed” theme has.