Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Tips And Tricks For Testing WordPress Themes

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!

Further Reading on SmashingMag: Link

Setting Up Link

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 Link

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 Test5.” 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'   => '',
  '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'   => '',
  '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 Gravatar6. You can grab a bunch of cool images by searching for avatars on ThemeForest7.

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

Version Control Link

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 Subversion10 and/or Pro Git11. They both have a wealth of practical information about version control, both general and specific.

During Development Link

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

“I’ll Do That Later.” Link

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 Link

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 Link

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.


Almost a no-brainer nowadays, LESS12 or Sass13 should be in everyone’s tool belt. While not without criticism14, 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.


I can’t even begin to explain how much I love CodeKit15. 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 Mixture16, Compass and, but none that I know of with the feature set of CodeKit.


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>';
echo '</pre>';

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

I’ve set this up in Coda 2, but you can use TextExpander17 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 Thumbnails18 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 Switching19 is a godsend, enabling you to switch back and forth between accounts with a single click.

Template Hierarchy

The “Template Hierarchy20” — 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()21 function, which lets you send email easily, the wpautop() function, which adds paragraph tags to text, and the human_time_diff()22 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 Link

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 Link

WordPress Theme Check23 (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 Link

CloudApp24 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, FluffyApp25 does exactly the same thing. I’m sure you’ll love it!

Bug-Management Workflow Link

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

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 Link

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.ly2926 and Sifter30 for sure.

Good Documentation Link

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 generator31, 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 Link

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 Link

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 Link

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!

Further Reading Link


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34

↑ Back to top Tweet itShare on Facebook

Hallo, my name is Daniel :) I build plugins, themes and apps - then proceed to write or talk about them. I contribute to various other online sites. When not coding or writing you'll find me playing board games or running with my dog. Drop me a line on Twitter or visit my personal website.

  1. 1

    Another alternative tool for compiling less/sass/coffeescript/haml/markdown/ect is Prepros. It’s pretty much CodeKit but for windows.

  2. 4

    Thanks for the article, I’ve recently started version controlling my themes using Git and this will really help me in the future.

    Unfortunately I couldn’t identify how to update themes using Git if I had a critical update. Do you have any tips or a guide on how to do this as you talk about version controlling themes?

    • 5

      Jason Bradley

      May 29, 2013 6:59 pm

      The best practice I have followed is make a base repository with the theme without changes. Then you will want to clone that repository to make your customizations there, keeping your base repository clean. Then, if the theme has some updates, then you can make those changes in the base repository, then merge them into your customized repository.

      Hope that helps!

    • 6

      Daniel Pataki

      May 29, 2013 9:34 pm

      Hi Michael,

      It depends on where your theme is. If you have a theme running on a test site somewhere on the internets you’ll need to get SSH access and issue a command to pull the latest changes (I haven’t used Git like this yet).

      The way I do it (this is also Git compatible), is I use Beanstalkapp. This is a version control hosting service (SVN, Git, etc.). It has support for automated deployments, ie: whenever a change is committed it can deploy it to multiple servers. I have it set up to automatically update my test version.

      Hope this helps,


  3. 7

    Jason Bradley

    May 29, 2013 6:50 pm

    Great tips here! Definitely beneficial for theme developers. I am a huge fan of using Codekit to compile all of my LESS and JS files. When you combine that with using PHPStorm, your files are saved automatically, then Codekit compiles behind the scenes, then Chrome is refreshed. Huge time savings there!

    I also use WP Test ( It includes a .xml file that I import that data to make sure I have all of my bases covered.

    • 8

      Daniel Pataki

      May 29, 2013 11:34 pm

      Again, I learn something new from awesome commenters :) I’m used to using the unit tests but I’ve never heard of, high time to take a look, thanks so much!

      I am completely in love with Codekit :) I use Coda 2 myself which I find awesome but I will definitely look into Phpstorm, I’ve heard nothing but good things about it!


  4. 9

    Great bunch of tips and tricks!

    Testing has been kind of the missing piece for me in the final stages of development. I like the thing you said about that “I’ll fix that later” mentality. I tend to leave big features at the final stages with one or two small bugs left thinking: “I’ll fix that tomorrow”. But no more! Time to get modular and doing things in the right order ;)


    • 10

      Jason Bradley

      May 29, 2013 7:04 pm

      Couldn’t agree with you more. I used to find myself saying those things too, “I’ll do it later”. I now get in the habit of using TODO’s and make sure to keep track of them. I mentioned PHP Storm in another comment, but it has great support for TODO’s, especially when you go to commit your code. #winning

    • 11

      Daniel Pataki

      May 29, 2013 9:36 pm

      Great stuff Sebastian,

      It can be difficult in the beginning, especially since for me this mentality stemmed from wanting to get a product out there as fast as possible. I think in the long run it makes things run more smoothly and much more quickly, but in the short term it may take a while longer to get things done :)

      Good Luck!


  5. 12

    Thanks for this nice article. I am always test and build the site locally by MAMP then immigrate it online to finish the site. :)

  6. 13

    Great post. I often will find something small to fix or think of a cool function to add and I frequently wait until the pre- launch checklist to make it happen…

    • 14

      Daniel Pataki

      May 29, 2013 11:31 pm

      Hi RW,

      That actually might not be a bad approach, I think it all comes down to balance. They key is identifying the core features and make sure they are well planned and added to the code.

      One of the biggest upsides of the “I’ll fix it now” mentality is that it becomes a breeze to add new features since (if you follow the mentality) you’ll never have large broken things in your code.

      This has allowed me to offer excellent customer support as all bugs could be fixed within minutes. This allows us to add small 5-minute features en-masse to keep people happy :)

  7. 15


    May 30, 2013 12:30 am

    Instead using a snippet, I’m adding a function in functions.php or in plugin file.
    Something like this:

    function de($i=null){
    echo ”;
    echo ”;

    For me this seems to be faster than to insert a snippet.
    Later on before moving to production, I replace this functions with the following:
    function de($i=null){
    return ”;
    So even in case I forgot to remove this function call from somewhere everything will still look good.

    • 16

      Daniel Pataki

      May 30, 2013 4:35 am

      Hi dimasmagadan,

      That’s a great approach as well, my only issue with this would be the “in case I forgot” problem. Knowing myself, I would definitely forget :)

      I would definitely have a separate “functions-development.php” file which I include in the main functions file. I would then remove that file and see if all is well. I would not replace it with an empty function because while better than having an error, it’s not great to have redundant things in there. You can always run a folder-wide search for “de(” just in case.


  8. 17

    Konstantin Kovshenin

    May 30, 2013 4:17 am

    Good read!

    Some examples are the mail() function, which lets you send email easily, the wpautop() function

    You probably meant wp_mail(). mail() is PHP’s internal implementation. Also, SCRIPT_DEBUG is a better alternative to CONCATENATE_SCRIPTS, and finally, for testing and debugging, the Debug Bar plugin series is a gold mine.


    • 18

      Daniel Pataki

      May 30, 2013 7:05 am

      Thanks for the notice, I’ve corrected the wp_mail typo :)

  9. 19

    URL typo – IMHO, Sifter should point to

  10. 21

    Scott Richardson

    May 30, 2013 6:06 pm

    Smashing really feels like it’s too heavily addicted to WordPress. You will get better results, faster performance, NOT using WordPress. Period. Why is everyone so enamoured by it? Write your own code instead of using a bulky, overweight, multi-purpose CMS.

    • 22

      Daniel Pataki

      May 31, 2013 12:05 pm

      Wait, stop the presses! The WordPress section of Smashing Magazine is addicted to WordPress??

  11. 23

    Great post!

  12. 24

    Julian Apong

    May 30, 2013 1:24 pm

    “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.”

    Could you expand on this? What else would you use LESS for, aside from CSS?

    • 25

      Daniel Pataki

      May 31, 2013 11:58 am

      I think you misunderstand. It’s not about what else LESS can do, it’s about what else can do CSS. Many people prefer Sass for example, and a LOT of people hate preprocessors altogether and prefer to write their own CSS.

  13. 26

    I built a phing script to automates much of this because I hated having to install wordpress all the time (or a new nightly) with custom parameters/themes/plugins etc. It has support for running custom install code or running any code once wp is already installed. There are other options that I slowly add like git/code testing/doc support, etc. It’s pretty usful but has not been thoroughly tested,

    • 27

      Daniel Pataki

      May 31, 2013 12:08 pm

      That is thoroughly awesome! I usually sidestep most of this by having a WordPress Multisite installation but this script is still mightily handy!

      If I have some time I’ll try and contribute, although I am no Phing expert. I think the missing link for every developer would be database migrations done easily, any ideas there? I used to have a long terminal command which could do it but it was pretty clunky.


  14. 28

    Colm Morgan

    June 4, 2013 12:24 am

    Excellent post Daniel,
    I think a lot of WordPress Devs are coming around to implementing their own deployment environments and workflows and I think this post covers quite a lot of it. Our dev team use a mixture of DeployHQ / Grunt / LESS / SASS throughout (not just for WordPress) and wp-config.php tricks are especially useful.

    I would point out that the latest Starkers Theme includes some nice snippets that I think you would find useful The guys at Viewport Industries have done a stellar job in renovating it.

  15. 29

    Clay Asbury

    June 10, 2013 7:16 am

    Fantastic – thank you. Terrific overview of what needs to be tested, why, and where to find the tools you need.

  16. 30

    Chris Anton

    June 11, 2013 7:12 am

    Awesome and thorough post. I’ll definitely be adding some of these ideas to our current development process. Thanks for the ideas!

  17. 31

    Luke Clifton

    June 12, 2013 11:33 pm

    Hey Guys. Insightful post Daniel, thanks.

    Does anyone use child themes as part of there theme development process?

    So you have your base theme as the parent theme and then you start developing a new theme as a child theme. This way you can overwrite or add to the base theme code separately from the base theme.

    Then when it comes to shipping you simply merge the child theme into the parent base theme which gives you your full production theme?

    This concept makes sense to me and we’re looking to try it soon.

    Does anyone else work this way?

    Also, we use BitBucket ( Its an alternative to Github and offers unlimited free private repositories!!


  18. 32

    Great content and tips sir!
    Security is also one of the things that must consider in your wordpress site, and I found tips about this topic.

  19. 33

    FYI, you can return the results of `print_r` to make your snippet more concise. Like this:

    echo '<pre>' . print_r( $some_var, true ) . '</pre>';

  20. 34

    Nice, I will try some of these

  21. 35

    Mohammad Qasim

    June 28, 2014 1:00 pm

    Nice informative article thanks for the tips.

  22. 36

    Nice Information about testing theme, there is free html email templates for friends, check and vote:

  23. 37

    I am a web developer and yes I am using most of the tips that you are mention above. These tips are really beneficial for a WordPress developer. People should try to use the above tips and tricks.

    Thanks for sharing.


↑ Back to top