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?
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:
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.
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.
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.
Other than just turning debugging mode on I also use couple of great plugins to help me out.
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
.
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:
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 🙂
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.