Social Menu Links

I (like most everyone) have number of social profiles spread across the web. Facebook, Twitter, Instagram, GitHub, etc. I tend to think of my website as my “home” on the web- it’s the only place I have complete control over the content, design and functionality. But I like to link to these other sites so folks can find me and engage there. For most brands and companies this is an essential requirement for their website.

icon-examples

There’s a number of ways for users to add social links. The simplest is to use the default WordPress menus and have text links. These can be added in a menu area or a widget. There’s also a few plugins that have purpose built widgets or absolute positioned icons that can work with most any theme.

But in most cases icon links in the menu are the best option for linking. Icons don’t take up much space and they’re immediately identifiable.

If a theme doesn’t support social icons by default, there are a couple plugins that allow you to use icon sets by adding classes to menu. Font Awesome 4 Menus is one. But since this is such an essential feature for most sites, I think it’s great when the theme itself handles it. This ensures that the icons used also match the rest of the theme design. Continue reading

Customizer Library

I’ve been working on a new project called the Customizer Library. It’s a collection of classes and functions that make it a bit easier to develop for the WordPress Customizer. It also includes helper functions for Google fonts and inline styles- though I’m considering moving these off into their own repositories as they might not be needed for all projects.

I’ve created a GitHub repository for the Customizer Library that can be included in a theme/plugin as a submodule. I also created a demo theme with example code so developers can get a quick idea of how it works and what it does. I’ve tried to document as much as possible on GitHub- so view the readmes there for implementation details.

screenshot

I think the reason the Options Framework has been so successful is because it reduced a really complex task (developing an options page) to a really simple task (defining an array). It abstracted the complexity of adding an admin page, generating field markup, sanitizing the data, and saving the options.

The WordPress Customizer is simple in comparison. There’s just one spot to load the controls and WordPress handles the generation of field markup for the most part. But it still doesn’t provide a default data sanitization and the syntax is more complex than it needs to be. Continue reading

Theme Shop Directory (2014)

Last year I published a list of independent WordPress theme shops ordered by Alexa rank. Since then a number of new ones have opened up, a few have closed doors, and a couple have rebranded or changed hands.

I thought it would be interesting to look at these numbers again to see how the independent theme market has changed over the year. I updated the ranking table and posted the new information at the bottom of this post.

Directory

Alexa data isn’t necessarily correct as it is based on traffic estimates. It also doesn’t indicate anything about actual revenue numbers. So the “data” here should definitely be looked at with skepticism. It is, however, one of the few independent measures we have to rank websites.

The biggest takeaway for me is that the Alexa ranking for all the top theme shops improved significantly. Every single shop in the top 25 is doing better than last year. I think this shows a continued interest in commercial themes and that well established shops are likely benefiting the most. Continue reading

Altering Comment Markup

Changing the default markup for comments can be difficult in WordPress. The wp_list_comments function has useful parameters for avatar size and reply text label, but if you want to make more structural changes (like moving the timestamp to below the comment body, or altering class names) you basically need to recreate the function inside a custom callback.

To me it makes more sense to have markup inside of a template file (rather than a function), and when looking at the Hybrid Theme by Justin Tadlock I saw it does exactly this. In Hyrbid, devlopers can use a custom comment.php template to alter comment markup. So, how it this done?

First, let’s specify a custom callback for wp_list_comments.

<?php
	wp_list_comments( array(
		'style' => 'ol',
		'short_ping' => true,
		'avatar_size' => 50,
		'callback' => 'prefix_comment_callback'
	) );
?>

Once we’re inside the custom callback function, we’ll want to call the theme template to use:

/**
 * Use a template for individual comment output
 *
 * @param object $comment Comment to display.
 * @param int    $depth   Depth of comment.
 * @param array  $args    An array of arguments.
 */
function prefix_comment_callback( $comment, $args, $depth ) {
	include( locate_template('comment.php') );
}

Note that we’re using “include” rather than “get_template_part” so that we can use all the variables available to the callback function.

We now need to take the markup that the default callback uses and paste that into comment.php. You can find that in the WordPress core file “/wp-includes/comment-template.php” in the function html5_comment. Here’s the version I used from 3.9.1.

Once that is pasted into the comment.php, you can move items around as you choose. Make sure to add text domains for any translated text if your theme will be used by international users!

Custom Post Type Boilerplate

I was doing a WordPress project this week that required four custom post types along with associated taxonomies and metaboxes. It’s been a while since I’ve done client work, and realized I didn’t have good boilerplate code to build these custom post type plugins from.

In the past, I’ve altered the “Portfolio Post Type” plugin which I’ve written but this has become more specialized for portfolios as Gary Jones and I have worked on it and isn’t as great a starting place as it used to be.

Team post type with metaboxes.
Team post type with metaboxes.

I think it’s really important to have quality code lying around for items like this. Building a custom post type (and especially metaboxes) from scratch each time can be a huge time waste. So, I’m throwing the final product up on GitHub in case others want to fork it and use it as their boilerplate as well. Continue reading

Disable Theme Update Checks

All WordPress themes check for updates on WordPress.org, regardless of whether it was developed custom for a client or built by a commercial theme shop. This can be a problem if a new theme gets added to WordPress.org that has the same name as your custom or commercial theme.

There’s a couple ways to get around this issue. Continue reading

A New Base Theme

The first WordPress theme I ever built was a modified version of Kubrick. I think that’s how most front end developers get started with WordPress- tweaking a core theme or a commercial theme to make it fit. Building one entirely from scratch has never made a lot of sense to me and over the years I’ve used a number of different theme platforms to build on.

History

toolbox-screenshot

I had a love affair with Thematic for a couple years. It was one of the early “frameworks” and a precursor to newer projects like Genesis. It was great if the design fit into the general structure of the theme, but I often found myself writing ten lines of code in order to unhook and rehook different sections of the theme for really minor changes. It was difficult to trace functions across multiple files. Although it made me a much better developer and was excellent for some projects, overall it seemed unnecessarily complex.

Next for me was “Toolbox“. This was a base theme developed by Ian Stewart, the same developer who had started Thematic. It was the complete opposite of a framework: a real simple theme, well structured, and easy to modify. It also followed the HTML5 spec (remember when that was new?!). I built my first publicly released theme (Portfolio Press) off of it as well as several projects for clients.

After Ian took a job with Automattic, Toolbox was forked and became Underscores. More on that over here. It’s an excellent base and many of the themes on WordPress.com are built off of it. There’s a great team of developers maintaining and contributing to Underscores. The code is clean, well commented, and the model of excellent WordPress practices.

Time to Fork

Fork

However, over the last few months I’ve found myself having to do more and more work to get Underscores to where I need it before embarking on a new project. I’ve decided it’s time to fork.

This is not a bad thing of course. Underscores is intended to be base in which to build off of, even if you’re forking it to build your own new base. And a solid base theme is important for any WordPress theme developer- it allows you to move quicker because you don’t need to solve the same problems for every project.

The main reason I’ve decided to fork Underscores is because of build tools. (Though re-using patterns for menus and comments will also be helpful.)

Continue reading

The Importance of Code Review

One of the huge benefits of working as a developer on a team is code review. You’ll commit changes for a project and then another developer will review them before pushing live. This helps avoid obvious mistakes and typos in the code- but it’s also one of the best ways to learn. Invariably your code can be better or more efficient, and having another developer look at your code will expose those gaps. Continue reading

Responsive Video and FitVids

video

If you develop responsive WordPress themes, you’re likely making sure embeds and iframes resize within the container. Something like this does the trick:

/* Make sure embeds and iframes fit their containers */
embed,
iframe,
object {
	max-width: 100%;
}

But the problem with video embeds is that the aspect ratio isn’t maintained at smaller screensizes. A quick for this is the tiny jQuery plugin FitVids. Continue reading

Optimizing Google Fonts in Themes

There are a number of methods to load Google fonts in a WordPress theme, but some are more efficient than others. Google has a post about optimizing the use of the Font API. I thought I’d summarize this as it applies to WordPress themes.

Enqueue or @import?

One of the simplest ways to load Google fonts is to do a an @import from the stylesheet, but Google recommends to link directly from the head of the document instead.

Properly enqueing the font and loading it from the head will also make it easier for people using child themes to change the font without copying the entire parent stylesheet over. Continue reading

Using Grunt with WordPress Themes

Over the last couple weeks I’ve started using Grunt with all my WordPress themes. It’s a development tool that helps automate certain tasks- like generating translation files, building sass files, adding browser prefixes, and minifying scripts.

Do you think we can automate some of this?
Do you think we can automate some of this?

A tool like CodeKit does many of the same tasks (and I highly recommend it if the command line terrifies you), but Grunt gives you more control and a huge library of modules to work with.

If you haven’t heard of Grunt yet, I think the place most people start is with Chris Coyier’s article “Grunt for People Who Think Things Like Grunt are Weird and Hard“. Continue reading

Features for Theme Developers (WordPress 3.9)

WordPress 3.9 will be released this month with some great new features. I think the enhancements for media (drop-in image uploading, audio/video playlists, and better editing options) will get a lot of attention in this release- but there’s also a ton of hidden gems.

I went through 582 tickets and picked some of my favorite enhancements, focusing on the ones I think will be most interesting for theme developers.

Media Features

WordPress now has support for audio and video playlists (and audio/video thumbnail images) thanks to work spearheaded by Scott Taylor:

playlists

Audio, video, and gallery previews are available in the editor and themes can add styling to better display them. Continue reading