Easy WordPress Plugin Development (Part 6)

by on May 31, 2011

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
    Toggle Article Details

  1. Introduction: Plug-in Development Overview
  2. Plug-in Development Fundamentals
  3. Our Plug-in's Primary File Source Code
  4. Implementing Dashboard Admin Pages
  5. Additional Plug-in Considerations
  6. Plug-in Testing Techniques  (you are here)
  7. Finalizing Our Plug-in
  8. (coming soon) Submitting Your Plug-in to WordPress
  9. (coming soon) Promoting Your Plug-in's Future
  10. (coming soon) Advanced Plug-in Techniques

Debugging Basics

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

Code: PHP (plus WordPress)

define('WP_DEBUG', false);

and change it to:

Code: PHP (plus WordPress)

define('WP_DEBUG', true);

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.

Code: PHP (plus WordPress)Debug Deluxe

define('WP_DEBUG_NOW', false);
 
if (WP_DEBUG_NOW == false)
{
    define('WP_DEBUG', false); // disables WordPress debugging
    @ini_set('display_errors', 1); // enables display of major PHP errors
}
else
{
    define('WP_DEBUG', true); // enables WordPress debugging
    define('SCRIPT_DEBUG', true); // enables WordPress' built-in JavaScript debugging
    define('WP_DEBUG_LOG', true); // logs errors in: wp-content/debug.log
    define('WP_DEBUG_DISPLAY', false); // disables enforced 'display-errors' activation
    @ini_set('display_errors', 0); // disables display of all PHP errors
}

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
Cross-browser Testing

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.

 

Continue Reading…

In our next article, we'll explore Finalizing Our Plug-in.

In our last article, we discussed Additional Plug-in Considerations.

 

Share This Article: “Easy WordPress Plugin Development (Part 6)”

(Also Available: Press CTRL+D to Bookmark this Page)

Comments

Share Your Thoughts  8 Responses to “Easy WordPress Plugin Development (Part 6)”
  1. 1
    Tren says:

    I’m really enjoying this plugin tutorial series. Learnin’ a lot.

    I like wpcodesnippets.info. bookmarked for future reference

  2. 2
  3. 3

    Hello there! I could have sworn I’ve been to this website before but after reading through some of the post I realized
    it’s new to me. Anyways, I’m definitely happy I
    found it and I’ll be book-marking and checking back frequently!

  4. 4

    I am really impressed along with your writing talents and also with the format on your weblog.
    Is that this a paid topic or did you customize it yourself?
    Either way stay up the excellent quality writing, it is rare to see a great weblog like this
    one these days..

Trackbacks

Check out what others are saying about this post...
  1. [...] Javascript Files · Types of Plug-in Capabilities ·Internationalizing Your Plug-inPlug-in Testing TechniquesDebugging Basics · Cross-browser Testing · WordPress Version Testing(coming soon) [...]

  2. [...] more here: Easy WordPress Plugin Development (Part 6) | WP Code Snippets This entry was posted in Techblog and tagged covered-extra, plugin installation, sixth, [...]

  3. Dustin says:

    Guter artikel. Sehr lehrreich.

  4. [...] Javascript Files · Types of Plug-in Capabilities ·Internationalizing Your Plug-inPlug-in Testing TechniquesDebugging Basics · Cross-browser Testing · WordPress Version TestingFinalizing Our [...]



Share Your Thoughts

(Some editor features are restricted unless you're logged in.)

(When replying to a specific comment, your browser may require Shift+Enter instead of just Enter.)


(get a gravatar)


Notify me of followup comments via e-mail. You can also subscribe without commenting.