This is the sixth article in our plugin development tutorial series. In the last segment, we covered extra features that your plugin can implement. You can access the linked table of contents for the entire series below.
Today, we'll complete our plugin's functionality by reviewing testing techniques.
Table of Contents for this Tutorial
In the process of developing your plug-in, you will certainly encounter typos and occasionally a logic error. Further, you'll want to test the various options to ensure that they perform together as you intend.
Plus, at some point, you'll need to turn on the WordPress debugging feature to thoroughly test your creation. In fact, many folks leave this capability enabled during the entire development cycle. With debug mode enabled, you'll be able to catch coding errors that you wouldn't easily know about otherwise.
Generally, I do the lion's share of plugin coding on a development site … a sandbox (as discussed at the end of the first article in this series). Then, I move it to a production site … interacting with other components, real content, and live visitors. This is where I prefer to implement Debug mode.
The most basic form of debugging is to simply set a special WP constant. This works, but it also shows ALL errors on every page viewed. And, trust me … MANY of these errors will be from OTHER plugins. They function, but that's because WordPress handles their errors and/or warnings internally.
Here's the simple method. Find this line in your wp-config.php file (near the top).
and change it to:
Additionally, there are four more lines of code that you should include to enable debugging on a live site so that the error messages are not displayed on pages … and are instead written to a log file. Moreover, because I do this regularly, I don't like commenting out several lines of code whenever I'm ready to commence the final debugging test. So … I wrote a simple segment that you can use to replace that default WP_DEBUG statement.
The comments explain the purpose of each line. Now, when you want to go into debug mode, just set WP_DEBUG_NOW to true. Revert to false when you're done. It's worth noting that the debug.log file is cumulative. So … you may want to clear its contents occasionally.
Also, note that this code enables display_errors when not in debugging mode. This line should be included in the default wp-config.php file. It only displays critical (script stopping) errors. And, without it, many sites simply show a blank white page when a MAJOR scripting error occurs.
Finally, if you want to tweak the debugging process, here are three tidbits to start you on that path.
- the PHP error_reporting() level is set temporarily in: wp-load.php
- the PHP error_reporting() level is set in: includes/load.php (in wp_debug_mode)
- _deprecated_function is executed from: includes/functions.php
Over the years, browser choices have increased. And in the last three years, cross-browser compatibility has improved significantly. Nonetheless, it's a very good idea to test your plug-in in the top five browsers … even if it does not present a visual interface.
For many years, MSIE (M$'s Internet Explorer) stood out for its many features. Today, it stands apart for its flagrant disregard of standards compliance. In fact, when you do a web search for CSS compatibility issues, at least 80% of the links are regarding MSIE.
They have paid the price … losing half of their market share in the last few years. But with their new 9.0 release, the M$ browser has made major strides forward. At its initial release, it was the most HTML5-compliant browser. However, it excludes many PC users as it is amazingly not available for XP-based systems. Allegedly, this is because XP lacks the ability to handle Direct2D for hardware acceleration.
Here are links to download the top five browsers. Each one is free and available for most operating systems. What's cool is checking out the various features each one offers for developers. Plus, Firefox is supported by a vast array of plugins that add just about any feature you can imagine.
WordPress Version Testing
It's also a good idea to test your plug-in (in your sandbox) with other (major) versions of WordPress. For older version testing, you'd likely start with 2.9 or 3.0. You can download any of these from the WordPress Release Archive.
And, perhaps more importantly you should test your creation with upcoming versions of WordPress. You can download these at the WordPress Releases Category Archive.
Of course, if your plug-in requires a new version of PHP or MySQL, you should state this clearly in your documentation.
In our next article, we'll explore Finalizing Our Plug-in.
In our last article, we discussed Additional Plug-in Considerations.