Alyeska, day one

Today, Miles and I skiied Alyeska for the first time. Alyeska is a resort about 40 miles south of Anchorage, Alaska. If you’ve ever seen a Warren Miller or Matchstick Productions Film, you probably are aware of Chugach Mountain Guides which operate out of the same area.

The snow is pretty much the best I’ve skiied in my entire life. The mountain received 34 inches on Monday, 30 inches on Tuesday, and then about 6 inches per day since. That is a lot of snow.

We did 25.5k feet of vertical in 20 runs all over the mountain — and had fresh tracks most of the day. Tomorrow, the goal is to ski from 10:30 am to 9 pm and break 40k feet of vertical.

What makes a good commit message

There’s a useful conversation happening in an internal Automattic P2 I thought I’d take the liberty to share.

From Mike:

Consider the audience when you write a commit message. What is that audience? It’s at least two groups of people:

  • Your coworkers: You’re telling everyone else what you did. Commit messages are one to many, asynchronous and textual. Sounds like email, so write the commit message like an email. The first line should be a descriptive subject. The next line should be blank (as a separator). Then comes the body of the message. Write everything as if you’re describing it to Nikolay.
  • Your future self: Think back on the times you were fixing something and needed to understand why an old commit was made. How often was the commit message useful? How often was it your own useless commit message? The commit message should say what the problem was (repro steps?), how you fixed it (briefly – the code itself gives more details), and why you changed what you did. That way the shiny pants people of the future have the information they need to decide if they can safely change your code.

From Matt:

I think as a company we need better commit messages. Very often in our messages we say what is happening but not the why, and most importantly the context of the change. I’m going to pick on this changeset, but you could really pick almost anything:

[link to changeset]

4 lines changed, with the message:

“Fixing incorrect $blogid variable, should be $blog_id.
Check if $current_blog is === false before trying to reset it.”

First a good thing: it’s a multi-line message, which is nice. Commit messages can use as many lines as you like, and be as verbose as you like.

However if I were to come across this changeset 3 years from now, say if I were debugging a similar area in the code, I’d have no idea why this change happened. The message might as well be blank, since it doesn’t really say anything I couldn’t tell in 2 seconds from looking at the diff. Some useful context would be:

  • What bug did this code cause? (This is most important.) Why change it?
  • Is there a relevant discussion, either on a P2 or in Trac?
  • Who was involved in the fix, IE who else would have context for this change either because they reported the bug or reviewed the fix.

From Lance:

Good commit messages are my gospel. The actual syntax should vary by context, though. For theme commits, for example, we always start with the theme name up front.

But, the goal of giving context and pointing to related items is key.

I personally don’t think long commit messages are better. Instead, point to a Trac ticket or P2 post with all the gory details.

Run up Timberline Road

Ran up Timberline road tonight because I skied down to Mazama lodge and left my car in the climber’s parking lot. Government Camp is at about 4,000 feet. Timberline Lodge is at 6,000. The road is a snaky, sometimes steep 5 or so miles. I did it in just over 50 minutes… had to take one walk break.

It’s 28 degrees out and I’m frozen solid. The wind is most brutal when all you’re wearing is long johns.

Upcoming talks: WordCamp Phoenix, PDXWP, and CMA NYC

Over the next couple of months, I’m looking forward to speaking at a few different events.

At WordCamp Phoenix on February 25th, I’m presenting “Mastering WordPress Development.” The title lends itself to a number of discussion topics, possibly including coding standards, how to perform migrations, writing bin scripts to manipulate lots of data, participating in open source projects, how to review your code, common mistakes we see at WordPress.com VIP, etc. If you have opinions as to what I should cover, I’d love to hear them in the comments.

On February 27th, Mike Bijon and I will be taking the Portland WordPress Users Group through using Git (and SVN) for version control and working within a team.

At CMA NYC March 18th through 20th, I’ll be leading three sessions (one per day):

  • “I Want To Learn WordPress – An Introduction To Key Concepts” – All of the basics you need to get started, including the WordPress interface and key concepts like themes, plugins, PHP and MySQL, and how to choose a good web host and design for your site.
  • “Hacking WordPress In The Newsroom” – How to take your WordPress development to the next level. We’ll review version control, coding standards, performance and optimization, debugging, and other best practices.
  • “Making The Switch To WordPress” – Everything you need to know about switching to WordPress from CMS X. Well, most everything.

Shaun, Erica, and I will also be hosting a mini-Happiness Bar for a few hours on Monday to help attendees with all of their WordPress questions.

Sweet!

Include posts by matching authors in your search results

Out of the box, WordPress’ search isn’t that great. It only returns posts based on a LIKE query against the post title or post content. Often, you’ll want it to match against other data associated with your post, possibly including the author, tags, post meta fields, etc. These queries can get complex to perform on the fly, however.

The following code snippet allows you to include posts by matching authors in your search results. We’re modifying any search queries to also include all posts whose author display name or user login matches the query. You can change this to be the author’s first name, last name, or other fields.

/**
 * Include posts from authors in the search results where
 * either their display name or user login matches the query string
 *
 * @author danielbachhuber
 */
add_filter( 'posts_search', 'db_filter_authors_search' );
function db_filter_authors_search( $posts_search ) {

	// Don't modify the query at all if we're not on the search template
	// or if the LIKE is empty
	if ( !is_search() || empty( $posts_search ) )
		return $posts_search;

	global $wpdb;
	// Get all of the users of the blog and see if the search query matches either
	// the display name or the user login
	$all_users = get_users();
	$matching_users = array();
	foreach( $all_users as $blog_user ) {
		if ( false !== stripos( $blog_user->display_name, get_query_var('s') ) || false !== stripos( $blog_user->user_login, get_query_var('s') ) )
			$matching_users[] = $blog_user->ID;
	}
	// Don't modify the query if there aren't any matching users
	if ( empty( $matching_users ) )
		return $posts_search;
	// Take a slightly different approach than core where we want all of the posts from these authors
	$posts_search = rtrim( $posts_search, ') ' );
	$posts_search .= ")) OR ( {$wpdb->posts}.post_author IN (" . implode( ',', array_map( 'absint', $matching_users ) ) . ")";
	return $posts_search . '))';
}

Status

Reblogged from Andrew Spittle:

Continuing in the style of last week I spent most of today reading my Instapaper backlog and listening to podcasts. Good day. Here are the highlights: Happiness Takes (A Little) Magic All aboard the Cocaine Express The Devastating Costs of the Amazon Gold Rush The New French Hacker-Artist Underground Lockdown: The coming war on general-purpose computing Back to Work episodes #48 and #46 Seminars About Long-Term Thinking: Universal Access to All Knowledge

Instapapering these for upcoming travel.

WordPress.com idea: Guided signups

Problem statement: Some users arrive at WordPress.com with intentions to launch a specific type of website. They know what type of site they want (e.g. photography portfolio) but don’t know how to use WordPress to achieve their goals. Although there’s lots of documentation available on features, we offer very little instructive, illustrated guidance on setting up different types of websites.

Each guide could have:

  • Links to example sites
  • Suggested WordPress.com upgrades
  • Suggested WordPress.com themes
  • Steps you need to take to configure your site
  • Frequently asked questions about setting up this type of site

This idea has been around the block a lot, and I recently rediscovered it in a notes folder. I think guided signups would be super useful for photo blogs, small to medium size business sites, mommy bloggers, etc.

Allowing authors to set co-authors

In the WordPress.org forums, whoaloic asks:

I have a site with multiple authors.
I would like to allow authors who create a post or a page to give rights to other authors.
For now, only administrator and editor can do that.
Is there a solution?

Yep, totally doable. By default, Co-Authors Plus defaults to ‘edit_others_posts’ as the required cap for changing co-authors. With the following code snippet in your theme’s functions.php file, you can make that cap ‘publish_posts’ instead (which authors and above usually have).

/**
 * Filter the Co-Authors Plus current_user_can_set_authors() function
 * so that users with 'publish_posts' can set Co-Authors
 *
 * @author danielbachhuber
 *
 * @see https://github.com/danielbachhuber/Co-Authors-Plus/issues/8
 * @see http://wordpress.org/support/topic/plugin-co-authors-plus-allow-authors-post-to-give-access-to-other-authors
 */
add_filter( 'coauthors_plus_edit_authors', 'db_filter_coauthors_edit_cap' );
function db_filter_coauthors_edit_cap( $cap_result ) {
	global $coauthors_plus;

	$post_type = $coauthors_plus->get_current_post_type();
	if( ! $post_type ) return false;
	
	$post_type_object = get_post_type_object( $post_type );
	return current_user_can( $post_type_object->cap->publish_posts );
}

In preparing this snippet, I also opened a couple of issues in Github:

Show biographies for co-authors at the end of your post

In the WordPress.org forums, doubleedesign says:

I want to add the authors’ biographies to the end of each post.

Awesome… it’s pretty simple to do. Conceptually, what we need to do is load our co-authors, and then loop through printing the relevant information for each one.

You’ll want to put the following code snippet within The Loop in any template you’d like the bios to appear.

/**
 * Show multiple Co-Author biography fields at the bottom of a single post 
 * This snippet should be placed within The Loop
 */
if ( class_exists( 'coauthors_plus' ) ) {
	// Get the Co-Authors for the post
	$co_authors = get_coauthors();
	// For each Co-Author, echo a wrapper div, their name, and their bio if they have one
	foreach ( $co_authors as $key => $co_author ) {
		$co_author_classes = array(
			'co-author-wrap',
			'co-author-number-' . ( $key + 1 ),
		);
		echo '<div class="' . implode( ' ', $co_author_classes ) . '">';
		echo '<h4 class="co-author-display-name">' . $co_author->display_name . '</h4>';
		// Only print the description if the description exists
		if ( $description = get_the_author_meta( 'description', $co_author->ID ) )
			echo '<p class="co-author-bio">' . $description . '</p>';
		echo '</div>';
	}
}

If you’d like other co-author details to appear as well, like their avatar for instance, you can modify the output within the foreach loop.

WordPress Jargon

Reblogged from Nick Hamze:

Today it dawned on me that when working with WordPress I tend to use a lot of jargon (the language, especially the vocabulary, peculiar to a particular trade, profession, or group). Now I didn’t realize this until someone pointed it out to me as since I use it everyday it doesn’t seem that foreign to me. However, I recognize that to others, especially those new to WordPress, I might as well be speaking greek. What I thought would be a fun/useful project would be to start a WordPress dictionary. Not just …

Great idea… Similar to the Hacks/Hackers glossary.