Toolset plugins perform complex operations and it’s important to be able to debug its internals.

We’re using an advanced debugger, that can output and tell you what the code is doing.

The Views debug tool

Since Views 1.5 we have a nice debug tool that can be used to check what is happening on a page containing Views or Content Templates. To enable it, go to Views -> Settings and look for the section Debug mode:

Views settings - Debug mode
Views settings – Debug mode

By default, the debug tool is disabled. Once enabled, you will be able to chose between to modes:

  • Compact debug mode: will display basic information, without information about filters and hooks executed by Views.
  • Full debug mode: will show the same basic information plus all the details about the filters being applied during a Views request and the results of every query performed by Views.

The Views debug tool will show the results of its analysis in a popup window that will open when you visit a page of your site containing a View or Content Template. We know that some browsers block that kind of popups from being opened, so we provide a nice test to check your browser settings. In case you need it, here you can find instructions for allowing popups on specific sites for the major browsers: Mozilla Firefox, Internet Explorer, Google Chrome, Opera.

Debug output

Views debug window
Views debug window

In the popup generated by the debug tool, you will see a lot of information:

  • The page being displayed, the memory used to display it and the CPU usage, along with the number of SQL queries.
  • Details about every View or Content Template being used on that page: render time, memory used, SQL query arguments and results.
  • If you are using nested elements (like a View inside a View, or a View using Content Templates to display elements), all the information will be displayed in a nested structure too.
  • Each element will display the original content, the shortcodes being used (with information about their attributes and output) and the output generated.

This way, you will have all the information needed to see what is happening at every moment.

There are two options in that debug popup:

  • Enable line breaks: will wrap the texts so they fit in the window width. Unchecking it will display horizontal scroll bars when needed.
  • Enable syntax higlighter: will add syntax highlighting to the parts that display some kind of code (like SQL queries and filters or shortcodes information). Note that when using the full debug mode, opening a very long section with this syntax highlighting tool enabled can cause some browser delay.

Alternative method

You can also use a more generic debug tool included in Views that will display some information in the browser console.

Enable WordPress Debug

Open your wp-config.php file and change the WordPress debugging mode to TRUE:

define('WP_DEBUG', true);

This enables the WordPress specific debug system. It will cause all PHP errors, notices and warnings to be displayed. You can read more information about WordPress debugging here.

This PHP messages often contain the name and the line of the file that is causing the bug. This way, you can identify errors coming from one of our plugins.

Debug Output to Console

Add the following to your wp-config.php file:

define('WPV_LOGGING_STATUS', 'info');

Then, open the console in your browser. In Google Chrome, click anywhere in the page and click on ‘Inspect element’. Then, click on the ‘Console’ tab.

Views debug to console

The console panel shows you everything that happens to display this page.

In this example, it starts by loading the View ‘Todos’. Then, the View tells us that it loaded 3 posts (my 3 todos) and that it’s calling the Content Template for each of them. We can see the post ID that’s loaded in each iteration.

More Debug Information

You can get more details debugging information about the query that Views is using by adding the following to your wp-config.php file:

define('WPV_LOGGING_STATUS', 'debug');

The console will now display details of how the View query is created, the SQL query executed and the posts found.

If you’re debugging something that doesn’t work, we recommend that you first enable debug mode and try it on a View that works as you intend. This will help you understand the debug output better. You can then proceed to the View that you want to debug, and do that much easier.

PHP Debugging

In case you think that Types or Views are doing something wrong (what we call a bug), you should enable PHP error logging. Again, edit your wp-config.php file and add the following:

ini_set('log_errors',TRUE);
ini_set('error_reporting', E_ALL);
ini_set('error_log', dirname(__FILE__) . '/error_log.txt');

This will produce a file called ‘error_log.txt’ in your WordPress root directory. Make sure that the web server can create and write this file. If it cannot, use an FTP program to create the file and make it writable to Apache (normally, user www-data).

Javascript Debugging

Many of the operations in WordPress require Javascript. Any error, due to anything, may cause all Javascript to stop and prevent things from happening. In Chrome, click on Tools->Javascript console. Normally, it should be clean. If you see any message, we should know about it.