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

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

Validation and Sanitization in the Customizer

At Automattic, we exclusively use the Customizer for theme options instead of theme option pages. We believe that themes should only alter the display of content and should not add any additional functionality that would be better suited for a plugin. Since all options are presentation centered, they should all be controllable by the Customizer.

Continue reading

The WordPress.com Public Theme Guide

wpcom-theme-guidelines

They say Valentine’s Day is all about love. Well, the thing I love the most about working on the Theme Team at Automattic is the attention to detail that goes into each theme launch. There is an inital build process followed by a series of peer reviews. More times than not a theme will be put under the microscope of 2, 3, or sometimes 4 different team members before launch. The sheer number of things that can potentially go awry in a theme can be overwhelming at times. This review process allows us to catch as many bugs as possible before people start using our themes.

Our peer reviews focus on a mixture of three areas: code quality, usability, and discovery of theme-specific anomalies. Over the years, our review process has grown organically. When we discover a new issue we will generally post about it to an internal P2-powered website for team discussion. While this process works really well, it can be a bit time-consuming to navigate through three years’ worth of posts to find an isolated conversation about a particular issue.

Recently, we thought it was a good idea to collect all of our theme guidelines and create an easy-to-follow resource. Instead of posting this internally, we decided that we would like to share our guidelines with theme developers everywhere. I would like to present to you the first installment of The WordPress.com Public Theme Guide. We hope that you get as much use out of this as we do!

theme-code-matters

Theme Code Matters, Too

Hey there, WordPress theme developers. When you’re crafting themes, are you checking the quality of your theme code? The design is important, yes, but so is the code. Within the past year, the WordPress theme review team has been hard at work encouraging best coding practices among WordPress theme developers, with the goal of raising the overall standard of the themes that appear in the WordPress.org theme repository. Even if you don’t intend to submit your theme to the WordPress.org theme repository, it’s wise to develop your themes as though that was your intention. I hope that by the end of this post, you’ll have a better understanding of the benefits of doing so.

The WordPress Theme Review Team and its guidelines

Just in case this is the first time you’ve heard of the theme review team, I’ll describe it briefly. They’re a group of volunteers from the WordPress community that reviews each theme that is submitted to the WordPress.org theme repository to check for compliance with the guidelines and standards that they have set forth. I’m not going to list all of the guidelines here because you can read them at the theme review team’s website, but I do wish to highlight a few here because they’re especially relevant to coding practices:

Briefly, a description of each of the above:

The Theme Check plugin

This is a plugin that tests your theme to see if it meets the latest theme review guidelines. If your theme is missing a required or recommended feature, or if it contains deprecated functions, the plugin will let you know and suggest possible fixes.

Code quality

These are a general set of guidelines that specify how you should format the HTML, CSS, and PHP in your theme. All HTML and CSS mark-up must validate to W3C Standards, and your PHP must neither generate any notices, warnings, or errors when WP_DEBUG is turned on (turn it on by placing  define('WP_DEBUG', true) in wp-config.php).

Does your theme contain hidden PHP warnings like THIS?

The Theme Unit Test

How well does your theme handle posts without titles? Do images resize properly? Do floated elements inside posts clear properly? Are all possible HTML tags that users can use in the visual editor styled? Are all widgets styled? The theme unit test is a set of sample data that you can use to test your theme in scenarios such as these.

Example of a Unit Test post on the Twenty Eleven Theme

Example of a Unit Test post on the Twenty Eleven Theme

Of course, as I stated earlier, these are just three of the areas in the theme review guidelines. A theme passes its review and is accepted in the WordPress.org theme repository when it satisfies the criteria for all of the areas.

So, why should you care?

The theme review team’s guidelines are important for all WordPress theme developers for three basic reasons:

  1. They establish general consistency among WordPress themes for users and developers.
  2. They ensure protocols for theme security.
  3. They raise the bar for overall theme quality.

Let’s discuss these three areas in more detail.

Consistency

WordPress themes are a eclectic bunch, but they do have at least one thing in common — they are all WordPress themes. It’s important to always keep this in mind.

When your theme deviates too far from the core WordPress functionality, you run the risk of users becoming frustrated as to why certain features that they’ve come to expect from WordPress don’t seem to work with their site. Listed below are sections of the theme review guidelines that help establish a base consistency among themes in the WordPress.org theme repository:

Before you add a custom feature to your theme, check to see if WordPress already has a core function that can take care of it. The table below highlights core features your theme should utilize as much as possible.

Theme Feature WordPress Feature to Use
Custom Logo/Banner Custom Headers
Background Color/Image Custom Background
Menu Management WordPress Navigation Menus
Theme file editing WordPress Theme Editor and Plugin Editor
Theme Options Page Settings API
Theme Options Page Design Stick with the WordPress UI instead of making your own design. (Ryan Imel from WPCandy wrote a blog post on this subject)
Design options (color pickers, font size tools, border size, etc) Keep to a minimum. Encouraging users to make design changes with CSS is more scalable in the long run.
Direct Database Queries WordPress Template Tags and Functions
Thumbnails Post Thumbnails (Featured Images)

Security

Constant Vigilance: Keeping themes secure requires active, continuous effort

Themes play a large role in WordPress sites, so it pays to ensure that your theme’s code is as secure as possible. Don’t let your theme be the one that leaves your users’ sites vulnerable to hackers. No one wants (or deserves) to have their site hacked. If you follow the theme review team’s security-related guidelines, you will be one step closer to building a theme that is as safe as it is gorgeous. The following are the theme review team’s guidelines related specifically to security. I highly recommend that you read them as you develop your theme:

  • Theme Settings and Data Security – Properly escaping all data throughout your theme and using the Settings API for theme options pages are essential characteristics of a secure theme.
  • Theme Obsolescence – Outdated code and deprecated functions are a security threat because they may contain known vulnerabilities that hackers can exploit. Themes in the WordPress.org repository will be removed if they are not updated on a regular basis to comply with the latest version of WordPress. In a similar vein, third-party scripts can also pose security risks, as we saw with the recent TimThumb vulnerability. If you use third-party scripts in your theme, please, please, please check those scripts regularly to make sure they are up to date. If the original author of a script does not put out regular updates, think twice about using it. Security is never a “set it and forget it” deal — you must approach it Mad-Eye Moody-style: CONSTANT VIGILANCE.

Quality

The final reason that it’s important to pay attention to your theme’s code is for the sake of quality. A theme that uses well-formed, modern code is easier for you and other developers to maintain in the future. The larger the number of well-coded themes we have, the more positively this reflects on the WordPress community as a whole. The following area from the theme review team’s guidelines relates specifically to code quality (I linked it earlier, but I’m linking it again because it’s that important):

In addition, WordPress has adopted standards for writing PHP, HTML, and CSS. We use these standards when converting themes for use on WordPress.com:

Conclusion and … how to get started

I hope I’ve convinced you why it’s so important to pay attention to your theme’s code, whether you are creating free themes or commercial themes. If you’re interested in applying some of these principles to your theme development, here is a nice list of procedures to keep in mind during the development process:

  • Make sure you’re aware of the current theme review guidelines.
  • Look at the code of the current default theme, such as Twenty Eleven, as a starting point and as an example of best coding practices and implementing core WordPress functionality.
  • Get in the habit of testing your theme with the unit test data.
  • Turn on WP_DEBUG in wp-config.php to check for hidden errors, warnings, and notices.
  • Install the Theme Check, Log Deprecated Functions, and Debug Bar  plugins. Run their tests often to catch (and fix) potential problem areas before they pile up.
  • Before you add a custom function, check to see if there is a WordPress core function that can take care of it. If you feel that the WordPress core functionality is lacking somehow, try supplementing the core feature instead of replacing it completely. Make sure that any custom feature you add does not leave “debris” behind (such as broken shortcodes) or otherwise cause a site to break badly if users decide to switch their theme. What are your “fallback” features?
  • Consider joining the WordPress theme review team, which forces you to learn by checking others’ code. For more information, please read Justin Tadlock’s excellent post on this subject: Join the WordPress theme review team.

Resources for further reading

Using TextMate for WordPress Code Cleanup

I spend a lot of time cleaning up WordPress themes. During the code cleanup I often perform certain cleanup tasks over and over, which makes them perfect for TextMate commands.

In this post I’ll show you how to add two useful commands to TextMate, then move through the steps I take for theme code cleanup and put the commands into practice.

First, let’s add the commands to a TextMate bundle. If you don’t know how to add commands to a TextMate bundle, or don’t have your own bundle set up yet, start here and add a new bundle. I usually add my own commands to a bundle called @lance so it sticks to the top of my bundle list.

Continue reading