Last week, I wrote up a lengthy guide to finding the right plugin for Tidy Repo. The large majority of this has to do with testing plugins once you’ve found them, and I thought I might expand on this idea a bit. So here’s a couple of tips for anyone who feels like testing their plugins before installing it on their production site.
Getting started
For those looking to get a test site up quickly, there are a number of steps to take. The first is to boot up a fresh WordPress install like you would any other. The only difference is, you’ll want to turn debug mode on so you can quickly spot errors. In your wp-config.php file, where you enter in database credentials, scroll down until you see WP_DEBUG and set it to true.
define( 'WP_DEBUG', true );
The next step is to add some dummy content to your site so you can really stretch a plugin out. I recommend WPTest, which gives you a fully-scaled site with lots of posts, pages, comments, users, menus, and just about everything a living, breathing site has. All you have to do is import the included XML file using the WordPress importer plugin and you’ll be good to go.
Then, actually install the plugin you want to test, and use it. Play around with the settings, add appropriate content, and keep your eye out for errors, warnings, and noticeably slow page loads. For a basic test, this will work just fine. But there are a few more things you can do to really get the most out of your testing environment.
Install on a live server
If at all possible, install your test site on a live server. This can be on a subdomain or subdirectory of your existing site if you don’t have server space elsewhere. If you do choose to go this way, just be careful with the plugins you install, especially with your database. In the past I’ve done this and haven’t run into a problem.
The reason I say this is because plugins respond differently on a live server then they do in a local or development environment, and you’ll encounter unique errors. Things like page load, latency, and general conflicts might not surface on a fully tuned, ideal local server.
Also, some plugins just won’t work properly on a development server. WP Migrate DB Pro, Jetpack, and EWWW Image Optimizer are all examples of this, but there are plenty more. When I first started Tidy Repo, I was doing a lot of testing on a development server, but I’ve since moved to almost 100% live-server testing, and the results have been great.
Leave your plugins installed
On a production site, I would recommend having as few plugins as possible, especially those that effect your front-end. They have a way of slowing things down or causing conflicts.
But on your test site, you should leave every plugin that has passed your test installed on your site. As some plugins come into contact with other plugins, there might be some problems that arise. Code can overlap, scripts can be registered twice, options can conflate or cause errors. These are the types of problems you want to see on your test site. Unless your site is impossibly slow, the more the better. So go ahead and leave those old plugins activated.
Dive into performance
I’ve mentioned this a couple of times, but performance is one of the best indicators of a good plugin. A performant plugin is typically coded well and maintained by a responsible developer.
In my post, I recommend using P3 Plugin Profiler from GoDaddy to test load times of various plugins. That’ll give you a great baseline, and get you most of the way there. But there are also a couple of other things to look out for.
For plugins that load in external Javascript or CSS files, you want to make sure that the developer is concatenating (combining) these into a single file, so only one JS file and one CSS file is loaded in. If you have a chance to dive into plugin code, make sure that these files are being registered and enqueued using wp_enqueue_script. And, of course, you want these to be as small as possible, and only rely on external libraries if absolutely essential.
You also want to make sure that if a plugin is querying your database, it is doing so intelligently. This really means making use of the WordPress API in just about every case, and keeping queries to a minimum. Dynamic round trips to your MySQL database can be costly, but if a plugin takes advantage of baked in hooks and functions, this shouldn’t be a problem.
Some helpful plugins
In addition to P3 Plugin Profiler, there are a few more plugins that can help you understand a plugin’s impact on performance. Helpful Information sits in your admin bar, and gives you a quick list of scripts and styles that have been loaded on to each page, so you can check which files are being added by plugins. Query Monitor gives you a list of each query that has been made on every page, and breaks it down by the source of the query, so you can determine how taxing a plugin is. And Debug Bar gives you quick access to debug warnings and information about your server so you can track a plugin’s overall effect on your site.
User Switching is another plugin that comes in handy. It has nothing to do with performance, but lets you switch between users, with different user roles, simply by clicking a link. Then you can switch back with another one. You can even temporarily log yourself out at any point, then go back to logged in status with a single link. While testing a plugin, it’s useful to switch between logged in users and guests on the fly.
And finally, you might find that Regenerate Thumbnails and Duplicate Post will help you out quite a bit. The former creates new thumbnails for existing files on the fly based on new media sizes. If you’re testing out a plugin that requires additional image sizes, this will make your life a lot easier. And Duplicate Post allows you to clone existing posts as drafts, if you want similar posts with only slight differences.
I created a collection on WPCore, which houses all these plugins if you want a quick start.
Hopefully, this is more then enough to get you started with testing out plugins for yourself. You can check out my full post for more details, but your best bet is to just start the process and tweak your test site as you go along.
Are there any techniques or tools you use for testing plugins I didn’t mention? Let me know in the comments.
Jay Hoffmann is a WordPress developer hailing from NYC. In the strictest sense of the word, he is a WordPress enthusiast with an eye for front-end development and design. He has been working with WordPress since 2006 and currently works for a popular children’s media company. This year, Jay started Tidy Repo, a curated list of the best and most reliable plugins from around the web. You can also follow Jay on Twitter.
2 Comments