WordPress.org

John James Jacoby

Konstantin Obenland

mitcho (Michael Yoshitaka Erlewine)

Dion Hulse

Peter Westwood

Samuel Wood (Otto)

Evan Solomon

Juliette Reinders Folmer

Ryan Boren

Andrew Nacin

Joseph Scott

Eoin Gallagher

koopersmith

Andrija Vučinić

Jon Cave

Adds a debug menu to the admin bar that shows query, cache, and other helpful debugging information.
A must for developers!
When <code>WP_DEBUG</code> is enabled it also tracks PHP Warnings and Notices to make them easier to find.
When <code>SAVEQUERIES</code> is enabled the mysql queries are tracked and displayed.
To enable these options, add the following code to your <code>wp-config.php</code> file:
<pre><code>define( 'WP_DEBUG', true );
define( 'SAVEQUERIES', true );
</code></pre>
Add a PHP/MySQL console with the <a href="https://wordpress.org/plugins/debug-bar-console/" rel="ugc">Debug Bar Console plugin</a>.
There are numerous other add-ons available to get more insight into, for instance, the registered Post Types, Shortcodes, WP Cron, Language file loading, Actions and Filters and so on. Just <a href="https://wordpress.org/plugins/search/debug+bar/" rel="ugc">search the plugin directory for ‘Debug Bar’</a>.

Debug Bar

This plugin does a good job.

Extremely useful when debugging own plugins.

Great debugging tool

Very simple and useful.

(CA)
Molt senzill i útil

Very simple and useful

This is a great debugging tool with lots of other supporting plugins available.

Simple and extensible

It is a great help when investigating problematic cases in support of our review plugins

We are using it in our plugin support

I couldn't do without it

Helpful tool


A plugin without which I cannot imagine my work. It would definitely be much more difficult.


it must be!


Debug Bar is still listed in WordPress’s own developer documentation as a go-to debugging tool, yet it hasn’t been updated in over a year and throws PHP errors. It’s a clear example of Automattic promoting a tool while failing to maintain it - a pattern that’s become too common. For a plugin they recommend, its neglect is frustrating and undermines developer trust.


Seemingly abandoned

Adds a debug menu to the admin bar that shows query, cache, and other helpful debugging information.

Brian Fegter

Chris Dillon

Chris Wallace

<blockquote>
This plugin is up for adoption.
</blockquote>
Kint Debugger is a simple wrapper for <a href="https://github.com/raveren/kint" rel="nofollow ugc">Kint</a>, a debugging tool to output information about variables and traces in a styled, collapsible format that makes understanding deep arrays and objects easier.
No more adding PRE tags before print_r or var_dump!
Kint Debugger works well with the <a href="https://wordpress.org/plugins/debug-bar/" rel="ugc">Debug Bar</a> plugin by creating its own panel to display your debug results.
<h4>Basic Usage</h4>
<pre><code><?php d( $var ); ?>
</code></pre>
Examples:
<pre><code><?php
 global $post;
 $term_list = wp_get_post_terms( $post->ID, 'my_taxonomy', array( 'fields' => 'all' ) );
 d( $term_list );
?>
</code></pre>
Kint Debugger also provides some helper functions for dumping variables that are frequently needed.
<ul>
<li><code>dump_wp_query()</code></li>
<li><code>dump_wp()</code></li>
<li><code>dump_post()</code></li>
<li><code>dump_this( $var, $inline = false )</code> – explained below</li>
</ul>
Examples:
<pre><code><?php dump_post(); ?>

<?php add_action( 'wp_head', 'dump_post' ); ?>
</code></pre>
Obviously, if this plugin is not active, calls to the helper functions will cause errors.
<h4>Your Own Functions</h4>
If you are dumping the same information in different places, consider writing your own helper functions in your theme’s functions file or an mu-plugin. For example:
<pre><code><?php
function my_dump_terms() {
 global $post;
 $term_list = wp_get_post_terms( $post->ID, 'my_taxonomy', array( 'fields' => 'all' ) );
 d( $term_list );
}
?>
</code></pre>
Then at strategic points in your theme or plugin:
<pre><code><?php my_dump_terms(); ?>
</code></pre>
<h4>With Debug Bar</h4>
By default, when <a href="https://wordpress.org/plugins/debug-bar/" rel="ugc">Debug Bar</a> is installed and active, Kint Debugger will send d() output to its Debug Bar panel.
To print debug output inline instead, as if Debug Bar was not active, declare the constant KINT_TO_DEBUG_BAR in your config.php (or really anywhere before your d() call):
<pre><code>define( 'KINT_TO_DEBUG_BAR', false );
</code></pre>
Or to print a specific dump inline, use a helper function with the parameter <code>$inline</code>. The generic <code>dump_this()</code> takes <code>$inline</code> as the second parameter.
Examples:
<pre><code><?php dump_post( true ); ?>

<?php
 global $post;
 $term_list = wp_get_post_terms( $post->ID, 'my_taxonomy', array( 'fields' => 'all' ) );
 dump_this( $term_list , true );
?>
</code></pre>
Kint Debugger overrides Kint’s d() function in order to buffer its output for Debug Bar. If you already have a modified d() function, you need to prevent the override in one of two ways.
<ol>
<li>Move your modified d() function to an mu-plugin. Kint Debugger checks if the function exists before declaring it so putting yours in an mu-plugin is the only way to ensure it exists first.</li>
<li>Declare KINT_TO_DEBUG_BAR as described above.</li>
</ol>
<h4>Restricting Output</h4>
To restrict visibility, use the <code>kint_debug_display</code> filter. For example, to prevent non-admins from seeing the debug output:
<pre><code>add_filter( 'kint_debug_display', function( $allow ) { return is_super_admin(); } );
</code></pre>
<h4>Try these plugins too</h4>
<ul>
<li><a href="https://wordpress.org/plugins/what-the-file/" rel="ugc">What The File</a> – Identify template files without fail.</li>
<li><a href="https://wordpress.org/plugins/debug-this/" rel="ugc">Debug This</a> – Peek under the hood with sixty debugging reports just one click away.</li>
</ul>

Kint Debugger

Dump variables and traces in an organized and interactive display. Integrates seamlessly with Debug Bar.

Debug Bar vs Kint Debugger