3194123638_33d9ffe462_b

Why Bootstrap is a bad fit for WordPress Themes

Since its release in 2011, Bootstrap has quickly become the most popular front-end framework on Github. This popularity also has an impact on the world of WordPress themes, with authors using the framework during development or even releasing themes that feature Bootstrap as unique selling point.

This is surprising, because Bootstrap is not a great fit for WordPress theme development.

Bootstrap is the wrong tool for the job

Bootstrap was created at Twitter as a tool for back-end developers to easily create interfaces for their applications. Before Bootstrap, various other libraries were used, which resulted in inconsistent and difficult to maintain interfaces.

So Bootstrap was created with a precise goal in mind, and it continues to develop according to this initial vision for the project. It was created so that developers could focus on back-end code and quickly iterate without having to worry about the front-end.

This is why it’s the wrong tool for a WordPress theme: the front-end, or how the site looks with the theme activated, is all that counts.

Bootstrap does not do things the WordPress Way

WordPress facilitates theme development by providing a set of functions to be used in template files. By leveraging the HTML output of these functions, developers can write efficient and clean code that works with a variety of content.

Bootstrap on the other hand has its own approach to how the HTML is structured, and it does not fit well with what WordPress provides by default.

As such, developers have to take extra steps and write additional code to modify WordPress’ behavior to the fit how the framework works. A good example for this are navigation menus. Instead of using the output of wp_nav_menu(), developers have to write Custom Walker classes that change the HTML output by the function so that the Bootstrap CSS and Javascript can be used.

This approach results in more code and as such is less efficient, results in more maintenance and development time and also does not benefit from the enhancements made to the Core functions.

Bootstrap is bloated

Framework code can never be as efficient as code written for a specific purpose, since frameworks build up from general cases to more specific cases and add bloat in the process. Often multiple CSS classes need to be added to HTML elements to achieve a desired visual result, along with the necessary CSS.

What adds to this problem is that often times, not only the CSS code necessary for the theme’s design is packaged, but the entire framework code.

Bootstrap does not encourage great design

One of the most popular features of Bootstrap is the twelve column, fully responsive grid system. By adding classes into the HTML markup, developers can create websites that react to every screen size.

Unfortunately using a predefined grid is the wrong approach to achieving a great design. The major problem is that you are designing from the outside in, shoving content into predefined boxes. The result is designs that have a rigid and mechanical feel to them, without proper proportions or harmony.

The one-size-fits-all approach also ensures that the theme you’re designing does not adapt to any constraints like image dimensions or line length. Whether you’re using a narrow sans-serif or a didone serif that needs room to breathe, the grid stays the same. The result is often bad legibility and nonharmonic typography.

A better approach

2328591656_311f762a73_o2

Every great theme design starts with a vision. What is the purpose behind the theme you’re designing and who do you envision using it and it what context?

This will inform you about the constraints that you have to work with. Designing an image heavy portfolio theme is a different challenge than creating an optimal experience for a magazine theme featuring long form articles.

Once you have set on a vision, you then start designing from the inside out. Get some sample content for a couple of test posts and then start designing the experience of consuming that content. You’ll see that once you focus on the content first, you can build out the remaining design elements around it and achieve a harmonic result.

On the technical side, use a starter theme that provides you with enough markup to quickly start diving into the presentational markup, without being overly opinionated about the design. Use libraries and code snippets to reduce development time. The default themes that ship with WordPress are usually a good resource for extracting code snippets.

Screen Shot 2014-08-11 at 9.30.46 AM

How to add Google fonts to WordPress themes

When enqueuing Google fonts, there are five things to consider:

  1. Is the font enqueued instead of included directly in the template files or CSS?
  2. Is the font enqueued on the correct hook?
  3. Is the font URL protocol independent?
  4. Can translators deactivate the font if their language’s character set isn’t supported?
  5. Can the font be dequeued by child themes?

In this post, we’ll go over the best practices for enqueuing Google fonts in your WordPress theme. Continue reading

Sass in underscores

Sass comes to _s

I’m pleased to announce that you can now get Sass rolled into _s by simply checking the box on Underscores.me. The community has driven this change through pull requests and forks.

It’s taken a little while, but we wanted to do it right. As with the rest of Underscores, we wanted to keep it as simple as possible, offering any extra scripting with a checkbox option rather than imposing it on all developers. Not everyone compiles or uses Sass the same, so _s shouldn’t force anyone to follow one path or another. In this sense, the Sass provided takes a pure approach, not requiring Compass or any other scripts.

Worth noting along with this addition is that the Github version of _s is now purely for development. We strongly recommend only using Underscores.me to download _s, going forward.

Just like with _s itself, the Sass it uses will probably change and evolve with time. What is in place now is a structure, a starting point. Any issues, or requests can be posted on Github, and you can even roll your own using a fork. Just like _s is your theme’s starting point, you can take the Sass in any direction you want.

I hope you are excited as I am to see Sass in _s! I’d like to thank the following people – without them this would not have been possible. As this was a Github project, here are their Github usernames: @gregrickaby @bradp @hugobaeta @obenland @sabreuse @MichaelArestad @jacklenox and myself. I look forward to seeing what things people build and where they take Sass in _s.

Swag

HTML5 Galleries in WordPress 3.9

With the new release of WordPress will come the ability to declare support for HTML5 markup in galleries. Once a theme declared support, the definition list elements will be replaced by <figure> and <figcaption> for better semantics.

If you decide to not only adopt this new feature but also maintain backwards compatibility, then there are two ways to achieve that:

  1. Style not only the new HTML5 elements, but also add CSS selectors for the traditional definition list elements. This is the route we chose for _s to keep it as simple as possible.
  2. Filter the shortcode attributes and override the tag parameters. Since the shortcode_atts_gallery filter was introduced in 3.6, you’ll be backwards compatible with the latest two versions.

Continue reading

cain

Using Custom Headers for Avatars

Some themes like to use the admin account’s avatar, if available, in the header of the theme to highlight the author. However, it’s nice to be able to change that image if the admin email’s avatar is not appropriate nor changeable.

The free Automattic theme Writr, by our very own Thomas Guillot, takes the approach of using Custom Headers for customizing the avatar image. In short, we’ll be using Custom Headers to output our image, and its default image argument will allow us to insert the avatar when no custom header image has been uploaded. Let’s get started!

In header.php, we output our Custom Header image as usual.

<!--?php 	$header_image = get_header_image(); 	if ( ! empty( $header_image ) ) : ?-->
	<a class="site-logo" title="<?php echo esc_attr( get_bloginfo( 'name', 'display' ) ); ?>" href="<?php echo esc_url( home_url( '/' ) ); ?>" rel="home">
		<img class="no-grav header-image" alt="" src="<?php header_image(); ?>" width="<?php echo get_custom_header()->width; ?>" height="<?php echo get_custom_header()->height; ?>" />
	</a>
<!--?php endif; ?-->

While declaring support for Custom Headers, we set the default-image argument to be a function (which we’ll use for our avatar logic).

function writr_custom_header_setup() {
	add_theme_support( 'custom-header', apply_filters( 'writr_custom_header_args', array(
		'default-image'          => writr_get_default_header_image(),
		...
	) ) );
}
add_action( 'after_setup_theme', 'writr_custom_header_setup' );

Finally, our writr_get_default_header_image function fetches an image from the Gravatar service. If there’s no account matching the admin email sent, we can request another image to be returned from Gravatar; we’ll try to match it to the “Default Avatar” value in Settings → Discussion (that’s all that $default business). More detail on the arguments being sent can be found in the Gravatar Image Requests documentation.

function writr_get_default_header_image() {

	// Get default from Discussion Settings.
	$default = get_option( 'avatar_default', 'mystery' ); // Mystery man default
	if ( 'mystery' == $default )
		$default = 'mm';
	elseif ( 'gravatar_default' == $default )
		$default = '';

	$protocol = ( is_ssl() ) ? 'https://secure.' : 'http://';
	$url = sprintf( '%1$sgravatar.com/avatar/%2$s/', $protocol, md5( get_option( 'admin_email' ) ) );
	$url = add_query_arg( array(
		's' => 120,
		'd' => urlencode( $default ),
	), $url );

	return esc_url_raw( $url );
} // writr_get_default_header_image

That’s it; we automatically get the avatar of the admin email (or an appropriate substitute) from Gravatar, or we can simply upload a new custom header image to override it. Have fun!

Cheetah in Namibia, by user tpsdave on Pixabay, CC0

Theme Performance

Website performance is a daunting, complicated subject; everything from servers, networks and the code itself affects the length of time it takes for our carefully-crafted pixels to arrive on the screen of our viewer. However, when it comes to WordPress themes, there are a few simple guidelines we can follow to make sure our themes help, rather than hinder, that process.

There is a single, unifying concept behind all of the following practices: less is more. Performance can be improved every time we:

  • reduce the amount of data we fetch,
  • reduce the time required to fetch that data, and
  • reduce the number of times we have to fetch data at all.

Image Handling

Images require special treatment to not get in the way of performance. These tips will make sure any images you require are as lean as possible.

  • Many images can be further compressed before suffering any visible loss in quality. Make sure any included images in your theme are compressed, either with your favourite image editor, or a tool like PNGCRUSH. Use the image format (JPG, PNG, or GIF) that best suits your situation and results in the smallest file size.
  • The best way to reduce image size? Don’t use them at all. If all you need are icons, use an icon font (like Genericons) instead, or the vector format SVG. Use CSS whenever possible for graphic elements, such as spinners or loaders.
  • If you must use multiple small images, combine them into a single file as CSS sprites, to reduce their download to just one HTTP request.

Scripts and Stylesheets

Scripts and stylesheets add up quickly. Simply adding third-party scripts and libraries that cover all edge cases can result in a lot of un-necessary code, while comprehensive CSS frameworks can also amount to needless data. Keeping in mind our mantra of less is more, two further action points can bring significant improvements to our page loads.

  • Minify, combine and compress your scripts and stylesheets to reduce their size and the number of requests to load them.
  • Enqueue scripts and stylesheets only on the pages that require them. See the Twenty Fourteen default theme for an example of how CSS and JS for the slider are conditionally loaded for just the home page.

Transients

Web servers have a very repetitive job. If ten users request our website in one minute, and nothing has changed on that page in that minute (a new post, categories removed, menus changed), it’s a bit of a waste for the web server to keep querying the database for the same information every time. This is where caching comes in. Caching is the general idea of doing the time-consuming data fetching one time, storing the results, and then delivering those stored results the next time someone asks for that same page. While the details of caching are far beyond this article, suffice it to say that the more our theme code can take advantage of caching, the speedier our sites will be – and the Transients API is a simple tool for theme developers to do just that.

Theme developers can store long-running queries in a transient, meaning each time that information is requested by the theme, it will be delivered quickly from cache rather than from a full query of the database. Secondary loops can be stored in transients, as well as the results of uncached core functions. The Twenty Fourteen default theme uses a transient for handling Featured Content.

For more information on transients and caching in general, Zack Tollman of The Theme Foundry has written an easy-to-understand overview of how WordPress uses caching in core.

Testing

Google’s PageSpeed Insights tool is extremely helpful when measuring performance of your sites in general. While some of it will not apply directly to theme code, it can point out issues with large images, unminified assets and more. There are two versions: a web version and a Chrome extension. The web version is usually more up-to-date (and now includes mobile-specific tests), while the extension can be used for offline, local testing.

Pingdom offers a suite of tools for web developers, one of which is the Website Speed Test. While PageSpeed is an overall review of best practices, Pingdom’s page test is focussed on load time, with the number of requests and load size for context.

Wrap-up

Getting content in front of our users as fast as possible is more important than ever these days, particularly considering the growing use of mobile phones and tablets. If we want content in front of our user within one second, we need to squeeze every millisecond we can get out of our themes and WordPress installs. Performance is an ongoing, incremental process which, with these guidelines and regular education, will keep your themes in top shape for all of your visitors, mobile and up. Remember: less is more!