Do it yourself theme review

I wanted to compare theme review processes and let’s start what is your role in theme review. In my opinion you play the most important role in theme review. It’s your responsibility to build secure, well coded and beautiful themes. But where to start if you don’t even know how to build solid themes?

Do it yourself theme review plan

Is this your review plan?

Role model themes

There are lot’s of great themes out there. But how do we know which are good role model themes? Themes that follow best practices, uses latest WordPress functions and are up to date. I have had three main sources for learning how to code themes.

I started learning from Themehybrid themes by Justin Tadlock. At first I just tried to understand the code, then build some child themes, and finally have enough skills to build my own parent themes. I highly recommend Themehybrid for everybody. You can ask any questions in the Forums or Slack channel. And you will be answered!

WordPress default themes are also great source for latest possibilities in WordPress. Twenty Sixteen is good example and it only works with WP 4.4+. There are several new tips and trick like these ones:

  • In header.php file there is example how to enable responsive images in header image.
  • In comments.php there is new the_comments_navigation() function.

Third learning source is Underscores theme. It’s a starter theme by Automattic. It has over 100 contributors and usually picks up the latest best practices pretty quickly.

Follow the theme review guidelines

Even if you are building a theme for clients I would follow theme review guidelines as much as I could.

It helps you realize what is important and what you should look for when writing your code. Every time I think I’m really clever with new stuff I go back to guidelines and check if I’m actually doing something stupid.

When you start following coding standards and guidelines in the beginning they will become a natural workflow for you. That will help you a lot and you don’t have to clean up that much of your code afterwards.

Debugging your code

In your development environment remember to turn debug mode on in your wp-config.php file.

define('WP_DEBUG', true);

This will help you see PHP errors, notices and warnings, WordPress-generated debug messages, particularly deprecated function usage.

There are other debugging constants that I use also, like SCRIPT_DEBUG.

define('SCRIPT_DEBUG', true);

Core, many plugins and my themes can minimize JavaScript and CSS files. For example there can be original navigation.js file and compressed file navigation.min.js. When SCRIPT_DEBUG is turned on you’ll load navigation.js file instead of navigation.min.js.

My current setup looks like this in development environment:

define('WP_DEBUG', true);
define('SCRIPT_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', true);

For more information check out Debugging WordPress Tips and Snippets article by Webdevstudios.

Plugins for debugging

Other than just turning debugging mode on I also use couple of great plugins to help me out.

  • Developer Plugin recommends you several tools and plugins.
  • Query Monitor Plugin for debugging queries and performance. And plenty of more! Heck, I even use it live sites sometimes.

Automated checks

After a while you get blind to your code. Read the lines below out loud. Go a head, it will only take a second.

Remember to follow the
the theme review guidelines

Did you notice any mistakes in that text? If not, read it again. Once more.

The same thing happens when we write code: we don’t spot our mistakes anymore because we think we got it right in the first place.

Some of the mistakes can be prevented using automated checks that will go trough your code.

I run both of the plugins every time I make some changes in the code. I also run them in live demo site, not just in my development environment. That’s because of the extra files I have in development, like .gitignore.

Accessibility review

I try to create my themes as accessible as possible. There are separate accessibility guidelines for themes which I try to follow right from the start. I even wrote article about accessible themes in Post Status.

I start my accessibility review by navigating all the elements without mouse and just using keyboard Tab and Enter. Especially menu elements needs more attention so you can access menu items, and sub menu items using only keyboard also.

I suck at testing my themes using screen readers. I’ll try to improve on this one!

Here are couple of other tools I use for accessibility testing:

Content review

For content I use two similar theme test data:

This will help you check to most common use edge cases on your design. Note that real content is always better than test data. I try to check all content that theme test data creates also on mobile, not just on desktop.

I also check content for valid HTML and structured data markup. There is no need to get in shock if you see some errors in validators. They are not 100 % correct every time 🙂

Final steps

Now do everything again but do it on clean, new WordPress install. First without any possible recommended plugins and then with them.

Go trough every setting you might have in a theme and watch if there are any design problems or PHP notices. This includes WordPress related features like custom header or background.

Then it’s time to clean up your code. Open every file in your theme and check your code line by line. I usually start with style.css file because it’s kind of a mess at this point.

Finally repeat every steps again. If you’re crazy like me you might still repeat every steps once more. And once more. And once more.

Congrats! You have now reviewed your theme and it’s time to submit your theme to WordPress.org or other marketplaces.