Jazz up your WordPress generator tag

A couple of years ago when I was in the throws of the Filters of the Day series, I wrote an example for the get_the_generator_{$type} hook that supplemented WordPress’ default generator tag with the jazz artist that release was named after.

The concept is simple: say you’re running WordPress 4.5.2 on your site. The default generator meta tag would output “WordPress 4.5.2” in your site’s source. This plugin supplements that to instead say “WordPress 4.5.2 to the sounds of Coleman Hawkins”. It matches the jazz artist whether you’re running a major or minor release. If you’re running trunk (like on this site), you’ll get a generic “WordPress X.X to the sounds of jazz” string.

In the years since Filters of the Day, I’ve referenced this particular example several different times in WordCamp and meetup talks, and yesterday, I decided to turn it into a plugin and submit it to WordPress.org: Jazzy Generator Tag.

To see Jazzy Generator Tag in action, it’s active on this site right now, just view the source code. If you’re interested in my other plugins, check out my plugins page, or my profile page on WordPress.org.

Shout out to Dominik Schilling (ocean90) for helping me make this plugin translatable for jazz artists of different genders!

Plugin repo bookmarklet

Sometimes when I’m checking out plugins in the WordPress.org repository, I like to view the source before I download. So partly out of boredom and partly out of laziness, I decided to create a bookmarklet that jumps you from a WordPress.org-hosted plugin page to its subversion repository.

The bookmarklet: Plugin Repo

To use the bookmarklet:

  1. Drag the above ‘Plugin Repo’ link to your bookmarks bar
  2. Visit any plugin page (or plugin’s sub-page) in the WordPress.org plugin repository
  3. Click the bookmarklet and you will be sent to that plugin’s SVN repo trunk url
  4. Boom.

Force sub-categories to use the parent category template

A couple of times in the last several years, I’ve needed sub-categories to inherit their parent’s archive template, but it’s just not something the Template Hierarchy supports. I’ve seen several plugins that tried and failed to do it, so finally I wrote a little filter that in my testing, works any number of levels deep, from sub-sub-categories to sub-sub-sub-categories. Enjoy!

function new_subcategory_hierarchy() {	
	$category = get_queried_object();

	$parent_id = $category->category_parent;

	$templates = array();
	if ( $parent_id == 0 ) {
		// Use default values from get_category_template()
		$templates[] = "category-{$category->slug}.php";
		$templates[] = "category-{$category->term_id}.php";
		$templates[] = 'category.php';		
	} else {
		// Create replacement $templates array
		$parent = get_category( $parent_id );

		// Current first
		$templates[] = "category-{$category->slug}.php";
		$templates[] = "category-{$category->term_id}.php";

		// Parent second
		$templates[] = "category-{$parent->slug}.php";
		$templates[] = "category-{$parent->term_id}.php";
		$templates[] = 'category.php';	
	return locate_template( $templates );

add_filter( 'category_template', 'new_subcategory_hierarchy' );

Easy way to check if jQuery is already enqueued

Had a plugin wreaking some havoc today because it was overloading jquery.js with a minified, older version. Plugin authors: There’s a really simple way to check if jQuery or a jQuery library is already registered and enqueued. This covers really obscure edge cases where a plugin may have de-registered WordPress’s default scripts.

The offending code:

wp_register_script('myjquery', 'https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js', true, '1.6.4', false);

The fix:

// If jQuery isn't already enqueued, register and enqueue it
if ( ! jQuery ) {
	wp_register_script('myjquery', 'https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js', true, '1.7.2', false);

Don’t Let Support Get Lost in Translation

I was lurking in the #wordpress support channel on IRC last night and noticed somebody getting the shrug off for a support issue because he wasn’t a native English speaker.

Now, the advice I initially gave him was ridiculed by others in the channel as stupid, but without really knowing the guy’s issue I was doing the best I could with what I could decipher from his broken English. And its not like anybody else was giving it a go, so I invited him into a private chat to get a better feeling for his problem.

We went round and round, him explaining in broken English and me trying to be as clear and concise as possible. Finally, I offered to use Google Translate so he could explain in Portuguese. He was floored that I would do this, but we tried it anyway. Turns out, it made all the difference in the world.

We went back and forth like that, me doing hyperspeed copy pasta with Translate, him doling out the Portuguese and after a few minutes we managed to get his issue resolved.

The problem as I see it is this: WordPress is all about contribution, whether it’s code, knowledge or time. Turning new WordPress users off by turning them away doesn’t really garner much support for the community, especially with the non-English-speaking crowd (who by the way make up about 2/3 of the worldwide community!).

Many users who seek support in IRC support are novice-level and they’re just trying to figure things out. It really doesn’t take all that much extra effort to meet them half way.