I am pretty new to plugin authoring and was having a hard time debuging.

I used lots of echo and it is sloppy and ugly.

I am sure there is a better way to do this, maybe an IDE with a debugger that I can run the entire site in including the plugin?

  • 1
    I haven't seen an IDE that runs WordPress entirely within the IDE ... though that would be awesome. I debug plug-ins by running WAMP locally and code in Dreamweaver. If you set WP_DEBUG to false, as John recommends, then you get a pretty good idea of what's going wrong, if anything, within your scripts. Then you can edit in Dreamweaver, hit Ctrl+S and then F5 in the browser to immediately view the changes.
    – EAMann
    Commented Aug 12, 2010 at 0:11
  • 1
    @EAMann - Be sure to check out both PhpEd (for Windows) and PhpStorm+XDEBUG (for Mac, Linux and Windows). Commented Aug 12, 2010 at 17:06

16 Answers 16


Go into wp-config.php and change define('WP_DEBUG', false); to define('WP_DEBUG', true);. Also, install Andrew Nacin's Log Deprecated Notices plugin.


If you're getting errors printed, then x-debug is a brilliant PHP extension that adds modern backtraces to PHP.

If you're trying to work out what's going on where there are no errors, my favourite approach is to define a function which logs its output to a file. So I do plog($variable) and that appears in the log file which I can then examine. This is especially useful when you're trying to work out what happened before header() is called, or other situations where you can't print to STDOUT.


Use xdebug + NetBeans IDE. When fully configured - which is easy to do - you can set break points in your plugin and watch variables at the break points. I think it is the best way to debug plugins or any php applications for that matter.


After tinkering with a number of IDE's, I settled into plain old Notepad++ with an ultra-customized Syntax Highlighting color scheme.

I have a macro set up such that when I hit Shift-Ctrl-X , the following code gets output where my cursor is:

echo "<pre>";
echo "</pre>";

It's simple, but I can generally hunt down 90% of my bugs with this macro plus WP_DEBUG enabled.

  • 2
    Nice move. Keyboard hotkeys in editors rock!
    – hakre
    Commented Aug 25, 2010 at 20:59
  • 1
    I prefer the output given by print_r($var, true) instead of var_dump.
    – brasofilo
    Commented Jan 29, 2013 at 21:48

I debug the old fashioned way, error_log()ing and var_dumping. I find that is the most efficient way for me, I have a couple of wrapper functions to handle different types of data, as error_loging arrays and objects can be a pain. Also, using print_r() in can be tricky to read when it is not in a <pre>. I have tj_log() for error logging, and tj() for showing output (which basically shows any data type in a presentable mannor:

function tj( $code ) {

        .tj_debug { word-wrap: break-word; white-space: pre; text-align: left; position: relative; background-color: rgba(0, 0, 0, 0.8); font-size: 11px; color: #a1a1a1; margin: 10px; padding: 10px; margin: 0 auto; width: 80%; overflow: auto; -moz-box-shadow:0 10px 40px rgba(0, 0, 0, 0.75); -webkit-box-shadow:0 10px 40px rgba(0, 0, 0, 0.75); -moz-border-radius: 5px; -webkit-border-radius: 5px; text-shadow: none; }
    <br /><pre class="tj_debug">

    if ( is_null( $code ) || is_string($code) || is_int( $code ) || is_bool($code) || is_float( $code ) ) :
        var_dump( $code );

    else :
        print_r( $code );


    echo '</pre><br />';


function tj_log( $code ) {

    if ( is_null( $code ) || is_string($code) || is_int( $code ) || is_bool($code) || is_float( $code ) ) :
        $code = var_export( $code, true );

    else :
        $code = print_r( $code, true );


    error_log( $code );


So then I just do: tj( $current_user ); or whatever.


I wrote a little class for make a logfile, is very useful when you are debugging ajax calls.


You only needs do something like:

Debug::log("This is a debug message");

When that line is executed a the message will be added in the log file and after that you can use the tail command (if you are using some unix's style operative system)

tail -f mylogfile.log

If you can pass to this function a array or a object as well.

note you needs change the line 20 for a path where you want save your log file


I use Aptane IDE on Linux and UltraEdit on Windows, and this one also has a PHP-parser. Also, I view all hints from xDebug with the constant WP_DEBUG defined in wp-config.php.

See also my post on this topic and feel free to comment and give feedback about your development tools.


I recommend checking out FirePHP. You can send debug info to Firefox's Firebug over HTTP headers, which usually makes for cleaner debug output.


Not that bad too: Eclipse It's close to PhpStorm + free.


There are two IDEs I can recommend and I've used both extensively: PhpED (Windows only) and PhpStorm+XDEBUG (Mac, Windows and Linux.) I'm on Mac now so can only use the latter.

Both of them ROCK! The good news that PhpStorm is $49 before September 2010 and only $99 after that. If I was on Windows and had to choose again, not sure which I would choose.

Frankly I can't help but feel that any plugin developer not using one of these two tools is severely handicapped, especially if they are relatively new to developing WordPress plugins.


Krumo - the styled php debug class

Another really nice thing is the "krumo" php class. It's implemented in ½ min and offers an easy way to debug all sort of variables:

  • objects,
  • arrays,
  • strings/float/integer/etc.

Plus it helps with backtracing, shows loaded classes or included files and everything on demand.

Plus it's FREE!


Krumo @sourceforge


I use a $13 plugin called LogPress you can buy on ThemeForest and it is an absolute God-send. You can debug everything relating to their plugins and site. Supports Firebug console logging and a whole lot more. I can't live without it, that is how much I use this plugin.

This plugin is probably the best money I have ever spent and it has saved countless hours in my Wordpress plugin development.

  • Wow, I was downvoted for recommending a paid plugin of which I have no association with whatsoever? That's a little heavy-handed aint' it? Commented Feb 15, 2012 at 2:53
  • 1
    I'm not the one down voting, but I'm not surprised. You're using words as if you're trying to sell the plugin. Recommending things is fine, but pushing hard sell like "absolute God-send". People hate adverts. Just tone down the language and the recommendation will speak for itself.
    – icc97
    Commented Nov 27, 2016 at 17:01

I'm using phpED and xdebug but for me (and seems for somebody else) it's impossible to debug the plugins or theme's file! The debugger only stops on the breakpoints that are in the main or original "core" files! anybody can help me?


Firstly I add define('WP_DEBUG', false); to the wp-config.php file (as most people have said) to my local install which is a recent copy of a relevant production site (both files and data). This makes stuff quick, safe, separate but reflects well at least one place the plugin will actually be used.

I also add the Debug Bar plugin together with some of the some of the Debug Bar add-ons (Transients for example) - as appropriate to your plugins.

I also use the Firebug add-on for Firefox which is excellent for helping track down html, css and JavaScript issues also well for looking into layout weirdness.

I code using UltraEdit which I have used for 15+ years for a whole bunch of coding (php through to SQL) both at work and home and so this works well for me but maybe doesn't have enough I to rate as an IDE for many folks. It has syntax highlighting, automatic completion and code layout features and a bunch of html and css shortcut tools which can help avoid typos and alike. Mostly this bring familiarity to me which is an important aspect often overlooked in the rush to the new. Muscle memory aids repeatability even in coding.

And of course I usually have some appropriate page from the codex open in another tab on a suitable exemplar.

These all help in different ways to highlight coding, parsing, functional and layout errors and do not interfere much in how I code or if nothing is amiss. Most can be ignored or deactivated for a bit if you're experimenting or working around something you'll revisit later.

Oh, and there's nothing wrong with a well positioned echo or print_r to check something at a key (so long as you remove them when you are done).


Check out Query Monitor combined with Query Monitor Extend for comprehensive debugging of WordPress (PHP errors/notices/stricts/warnings, database queries, paths, constants, HTTP requests, transients, session variables, var dumps).

Also check out All Post Meta and Saving What plugins for specific info on posts.


PHPStorm and Xdebug is a game changing for me for WordPress development. Highly recommend now. Specially with theirs inline debug tools.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.