Tips And Tricks For Testing WordPress Themes

Advertisement

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!

Further Reading

(al)

↑ Back to top

I am a web developer in love with WordPress. I have a company called Bonsai Shed where we make webapps and premium themes like Musico and Estatement.

  1. 1

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

    4
  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?

    1
    • 5

      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!

      0
    • 6

      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,

      Daniel

      2
  3. 7

    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 ;)

    Thanks

    0
    • 8

      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

      0
    • 9

      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!

      Daniel

      1
  4. 10

    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…

    0
    • 11

      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 :)

      1
  5. 12

    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 (http://wptest.io/). It includes a .xml file that I import that data to make sure I have all of my bases covered.

    2
    • 13

      Again, I learn something new from awesome commenters :) I’m used to using the unit tests but I’ve never heard of wptest.io, 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!

      Daniel

      1
  6. 14

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

    0
  7. 15

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

    function de($i=null){
    echo ”;
    print_r($i);
    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.

    0
    • 16

      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.

      Daniel

      0
  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.

    Cheers!

    0
  9. 19

    URL typo – IMHO, Sifter should point to https://sifterapp.com

    0
  10. 21

    “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?

    0
    • 22

      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.

      0
  11. 23

    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.

    -4
    • 24

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

      2
  12. 25

    Great post!

    0
  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, https://github.com/wycks/WordPhing

    1
    • 27

      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.

      Daniel

      0
  14. 28

    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 https://github.com/viewportindustries/starkers/blob/master/external/starkers-utilities.php. The guys at Viewport Industries have done a stellar job in renovating it.

    0
  15. 29

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

    0
  16. 30

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

    0
  17. 31

    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 (https://bitbucket.org). Its an alternative to Github and offers unlimited free private repositories!!

    Luke

    0
  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.

    http://www.myoptimind.com/10-ways-to-improve-wordpress-security/

    0
  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>';

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top