Tips And Tricks For Testing WordPress Themes

About The Author

Hello, I’m Daniel and I make things for the web. I’m the CTO at Kinsta and I write for a number of amazing publications like Smashing Magazine and … More about Daniel ↬

Email Newsletter

Weekly tips on front-end & UX.
Trusted by 200,000+ folks.

In this article, Daniel Pataki will share some of the tricks he uses personally during and after development to achieve a bug-free product. This should give you a good overview of what you can do over the course of the development cycle.

Whether you offer free or premium themes, testing should be a major part of your development process. By planning in advance, you can foster a development environment that deters some bugs by design and that helps you prevent others. The aim of this article is to share some of the tricks I use personally during and after development to achieve a bug-free product.

This article is split into three distinct sections:

  1. Setting up,
  2. Development phase,
  3. Final testing.

This should give you a good overview of what you can do over the course of the development cycle. I invite everyone to chime in with their own tips in the comments. I’d be interested to hear your tips on testing WordPress themes!

Setting Up

Setting up your environment correctly can go a long way to preventing bugs and helping you to find them more easily. For me, it all starts with version control.

Setting Up WordPress

You could do about a million things when setting up WordPress to ensure you make as few mistakes as possible. I always do a number of things:

  • Using a network (WordPress Multisite). While not much different, developing for a network installation does present some differences in methodology (especially with plugins). Because I use one network for the themes that I make, it is still useful, and I can make sure that the themes work properly on network installations as well.
  • Custom table prefix. Installing a custom table prefix helps in two ways. First, it ensures that you don’t hardcode database queries. Secondly, it gives you an additional layer of security. Everyone knows that the default is wp_, so choosing 239Jd_23eKSmCM892_Vuhwedp as your prefix is like adding a mini-password to your database.
  • Enable debugging information. I’ve found that a lot of sloppy developers leave undefined variables and other such nuisances all over the place. PHP might not complain about these by default, but they are annoying and could lead to other problems down the road. To make sure you don’t accidentally trigger notices, simply make sure that WP_DEBUG is set to true in wp-config.php.
  • Disable WordPress script concatenation. A more obscure feature of WordPress is the option to disable script concatenation. Sometimes, when figuring out how WordPress does things, you’ll want to look at some of the built-in JavaScript files. If you set define('CONCATENATE_SCRIPTS', false); in the wp-config.php file, your scripts will be pulled in separately. Don’t forget to reenable it for production environments!
  • Advanced query analysis. If you set the define('SAVEQUERIES', true); constant in wp-config.php, WordPress will save all of the queries performed into a variable. You’ll be able to access it by printing the $wpdb->queries variable.
  • Disable the trash. Normally a great feature, the trash just gets in the way when you’re developing and creating and deleting pages and posts. Disable the trash by setting define('EMPTY_TRASH_DAYS', 0 ); in wp-config.php.
  • Test posts. Right off the bat, I usually import the test content from the “Theme Unit Test.” This test suite contains normal posts, posts without titles, posts without content, posts with and without featured images, sticky posts, posts with a load of categories and so on. It helps you to test fringe cases especially well, which is critical for all themes.

I also like to create 16 users with different roles. Unfortunately, I don’t have a script for this, but writing one wouldn’t be that difficult. You could create an array in a file and just feed it to the wp_insert_user() function in a loop. Something like this:


$users[0] = array(
  'first_name'   => 'Daniel',
  'last_name'    => 'Pataki',
  'user_login'   => 'danielpataki',
  'user_pass'    => 'mysupersecretpass',
  'user_email'   => 'mysupermail@mymail.com',
  'display_name' => 'Daniel',
  'description'  => 'Guitar-wielding Web developer',
  'role'         => 'administrator'
)

$users[1] = array(
  'first_name'   => 'Viki',
  'last_name'    => 'Makra',
  'user_login'   => 'viki',
  'user_pass'    => 'hersupersecretpass',
  'user_email'   => 'hersupermail@mymail.com',
  'display_name' => 'Viki',
  'description'  => 'Front-end developer and awesome admin handler',
  'role'         => 'editor'
)

foreach( $users as $user ){
  wp_insert_user( $user );
}

I actually have a set of test emails for each user account I create, and I add avatars for each of them on Gravatar. You can grab a bunch of cool images by searching for avatars on ThemeForest.

You can also use a plugin such as User Photo or Simple Local Avatars to add the photos locally.

Version Control

Version control is one of the best things to come along since bacon. Whether you prefer Git, SVN, Mercurial or another system, you will be able to roll back to different versions and always have a backup of your work lying around.

Version control is supposedly most helpful with collaboration. While this is true, I’ve found that the order it brings to your coding practice is just as valuable. I highly recommend reading Version Control With Subversion and/or Pro Git. They both have a wealth of practical information about version control, both general and specific.

During Development

Here are some useful tips and tricks to follow during theme development.

“I’ll Do That Later.”

As a seasoned coder, I usually know my way around a coding task when one arises, but pushing myself to the end of such tasks is difficult. If I am implementing a map-based search tool, then the biggest tasks are to make sure that the form works and that when the user performs a search, it hooks into Google and the results are returned and displayed on the map and so on. Once those are done, then making sure that the form looks good, that administrators can define the map type to the user and so on are minor matters.

Previously, I would work through major features and then go back and touch up the details. The only problem with this is that it is the worst practice ever. You forget things; your code gets messy; then you can’t maintain it properly; and it becomes a giant headache.

My recommendation is to either develop a feature or not. Make sure that you’ve added all planned features and that they don’t just kinda work or have bugs that are “not big problems because they can easily be fixed later.”

If your code is extremely modular, you could, of course, separate the presentation from the functionality, but that’s a story for another article.

Modularity Is King

The best way to develop is to follow the lessons of object-oriented languages or object-oriented PHP. You can’t (or might not want to) code everything with classes, but the general philosophy is very helpful.

Widgets in WordPress are a great example. Using a pretty simple pattern, you can create the back-end form for a widget and make sure that it saves its data properly and that you can add the front-end code. Then, the widget will work anywhere, anytime.

You can apply the same principles to most coding tasks. Write code that is as independent as possible. Your code will remain clean and will do wonders for maintainability.

The Right Tools

The biggest speed boosts during development come from choosing the right development tools. Below is a list of apps and other tools that speed things up a lot for me.

LESS

Almost a no-brainer nowadays, LESS or Sass should be in everyone’s tool belt. While not without criticism, these tools help way more than they harm.

A quick note about LESS. Many people really hate the idea of using LESS for CSS. While their points are valid, I disagree. But it’s up to everyone to make their own choice. Ultimately, it comes down to preference.

CodeKit

I can’t even begin to explain how much I love CodeKit. It compiles my LESS to wherever I want it to, concatenates JavaScript files based on a file input, checks syntax, and does a ton of other stuff that I never even use.

One caveat is that it is Mac-only. A ton of alternatives are available, such as Mixture, Compass and Fire.app, but none that I know of with the feature set of CodeKit.

Snippets

I don’t know if I’m alone on this, but I’ve never found snippets to be particularly useful. Most things need to be customized so much that just writing them out from scratch would be easier. There are only two snippets that I use, but I use them so much that they have saved me at least a hundred hours by now. The two snippets are for printing a variable and outputting a long comment:


// Printing a variable:
echo '<pre>';
print_r();
echo '</pre>';

// A long comment:
/*********************************************/
/*         This is a section of code.         */
/*********************************************/

I’ve set this up in Coda 2, but you can use TextExpander and various other apps.

Thumbnail Regeneration

As you code, you might find that you need a different-sized image somewhere or that the design requirements have changed. In the former case, you should generate an image with the exact dimensions you need to conserve bandwidth. You can do so with the add_image_size() function, although images would not be processed retroactively.

I use the excellent Regenerate Thumbnails plugin to address this problem. I’ll go into the “Media” section and regenerate thumbnails for a single media item, or the plugin can batch process them all. It might take a while if you have a lot of images, but it’s completely set-and-forget — you can just keep on working.

Switching Users

You’ll need to test different accounts to make sure users see only what they’re supposed to see, especially if you have role-specific functionality. User Switching is a godsend, enabling you to switch back and forth between accounts with a single click.

Template Hierarchy

The “Template Hierarchy” — and especially the diagram a bit further down on that page in the Codex — will help you to remember all of the pages you need to create. Are you sure you haven’t forgotten the 404.php page? Have you created a separate attachment.php file for single attachment display? Never forget a file again with this handy chart!

Browser Development Tools

Learning how to use your browser’s development tools will make your life a lot easier. Being able to go into the DOM and look up styles will make fixing CSS problems a breeze. Going into the “Network” tab and looking at the AJAX response will help you debug AJAX calls in seconds, and using the features of the JavaScript debugger (such as break points) will help with JavaScript debugging.

WordPress Knowledge

Being able to perform complex tasks using database queries is a huge help. If you’ve created 200 test posts and want to delete all whose titles have two instances of the word “or,” that’s easy if you know how to query and manipulate data.

It also helps with “Oh, there’s a function for that?!” syndrome, which kicks in after you’ve spent an hour coding something, only to discover that WordPress has a function for it. Some examples are the wp_mail() function, which lets you send email easily, the wpautop() function, which adds paragraph tags to text, and the human_time_diff() function, which formats dates into the “5 minutes ago” format.

Before attempting to code a small feature, I always search for it, just in case. Before coding a big feature, I search GitHub and other places to see whether anyone has done it before. Perhaps there is a cut-and-pasteable class or something similar.

Final Testing

Once you’re done, you realize you’re never done. There’s always that one last bug, that one feature that doesn’t work in IE 9, and other similar annoyances. To minimize bugs and maximize your sanity, try the tricks and tools below.

WordPress Theme Check

WordPress Theme Check (maintained by WordPress’ own developers) is an extremely useful tool for ensuring that your theme is up to spec. The first thing Theme Forest does when you submit a theme is run this thing on it, and they will mercilessly reject your theme if they see errors.

The tool checks for legacy functions, incorrect text domains, hidden files, required functions and attributes, and much more. Using this plugin is the easiest way to make sure your theme is 100% WordPress-compliant.

CloudApp And FluffyApp

CloudApp is a service that enables you to easily upload files. The reason I love it so is that it comes with a little app that can be configured to play nice with my screenshot-making procedure. On the Mac, I just press Shift + Control + Command + 4 to take a screenshot, and then immediately press Control + Option + C (this shortcut can be reconfigured) and wait for the “ping,” which means the screenshot has been uploaded. A link to the screenshot is already in my clipboard, so I can paste it in an email, chat message or issue tracker.

If you’re on Windows, FluffyApp does exactly the same thing. I’m sure you’ll love it!

Bug-Management Workflow

I won’t go into particular bug-management tools because there are just so many. I personally use Sprint.ly, but hundreds of great services are available, such as Sifter, Lighthouse and Redmine.

More important than what you use is how you use it. One policy that has helped my team with our themes is that the person who fixes an issue may never mark it as closed or accepted. This ensures that the issue is properly tested and approved by someone who is able to see it more objectively.

Version-Control Methodology

Our version-control system gives us two other benefits. We make sure to commit after every bug is fixed; this enables us to keep track of repository changes much more easily. It also means we can roll back versions much more accurately and selectively.

We’ve tied our bug-management system to our version-control system, so that whenever we commit a change, we can close the issue right from the command line by typing, say, Fixes #32. This works in Sprint.ly and Sifter for sure.

Good Documentation

While documentation might not seem directly related to testing, it is an excellent way to test a website. By writing documentation, you force yourself to go through the website’s features and make sure they work.

We found an astounding documentation generator, which we use with all of our themes now. Aside from helping us write the documentation, it generates a beautiful format with no additional work on our end.

The More, The Merrier

One of the most important lessons I’ve learned is that a theme is never bug-free. If 100 people test the living daylights out of the theme, the 101st person (probably the first buyer) will find a bug on launch day. That’s just how it is.

You can minimize this and ensure that bugs are at least restricted to fringe cases by loosing as many people on your theme as possible. We’re all different, which means we use things differently and will find different bugs.

Another major benefit of this — one that I cannot stress enough — is that it allows for user experience testing. If only the people you work with have tested the theme, chances are you’ve missed something because you all think alike. A dropdown button might be dead obvious to all of you, but baffling to a regular user.

A great way to improve your theme is to actually sit and watch as people test your theme. I’ve made more changes than I can remember as a result of stupid things that have come up during testing — and I mean not that the people were stupid, but that I was stupid for designing those things the way I did. Remember, there is no such thing as a bad user, just a badly designed tool.

Make A Video Presentation

This sounds even weirder than documentation-based testing, doesn’t it? But I’ve found that making a presentation video about a theme is a great way to catch little things. Knowing that the first thing people will see is the video inadvertently forces you to get hung up on the tiniest problems.

The general routine for me here is that I’ll get 2 minutes into making the video, let out a huge sigh, stop the recording and go and fix something. I’ll then restart from scratch, get to 2 minutes and 15 seconds, and it all starts over.

The best method for me is to restart from the beginning after having stopped. I could instead just pause and resume, but when I start from scratch I’ll sometimes take a different approach, which uncovers more discrepancies and bugs.

Conclusion

I hope these tips have been helpful and that at least some of them are new to you. I think everyone does a lot of little things we could all learn from. I probably do 50 more useful things that I don’t even notice I’m doing.

I’d love to hear what you do to test both the quality and speed of your themes, so please share in the comments below!

Other Resources

Further Reading

Smashing Editorial (al, mrn)