By Tom

Debugging Minified Files in WordPress

As much as I’m a proponent of concatenating and minifying dependencies, it’s not without challenges. Sure, this is includes both stylesheets and JavaScript, but I’m specifically talking about debugging minified files in WordPress.

A minified bug. Get it?

It’s one thing to have your JavaScript files separated and organized in your Development. But when it’s time to deploy to Production, you should be aiming for a few minified files.

For example, say a client contacts you claiming something on their site isn’t working? You load up the site, you check the browser console and see there’s an error in the JavaScript.

Wait. You’ve minified all the files.

So what now?

Debugging Minified Files in WordPress

First, make sure Development is in sync with Production. Don’t edit files live on the server. This should go without saying. Then again, we’re still saying it and people are still doing it.

So there’s that.

Ideally, you need to be able to toggle a flag that will load the un-minified files making it easier to trace code.

The trouble with doing this in WordPress is that people may have their own ways of doing this. That is, other themes and plugins may have their own flags and you may end up causing erratic results when trying to debug those files.

Some ways that developers make it easy to toggle values are:

  • Passing a value in the query string
  • Retrieving a value defined in a plugin
  • Setting a value in an XML file
  • Reading a value from the database
  • …and many, many more.

The problem with doing this is that you never know what side effects you may trigger when toggling your flag. What if the theme or another plugin has opted to use the same flag? Wouldn’t this result in potentially causing something to happen that you didn’t expect?

Maybe.

So what’s the standard way to go about doing this?

If you look through the WordPress source code, you’ll find references to a constant: SCRIPT_DEBUG.

For example, wp-includes/default-constants.php has this code in Lines 69-79 (at the time of this post):

In short, the code is doing the following:

  • Check to see if the SCRIPT_DEBUG constant has a definition
  • If not, check to see if the $GLOBALS collection as -src defined in the wp_version value.
  • If so, then set $develop_src to true
  • Otherwise, set $develop_src to false
  • Set the value of SCRIPT_DEBUG
  • But there’s another key to the code that’s left in the comments:

    // Add define(‘SCRIPT_DEBUG’, true); to wp-config.php to enable loading of non-minified, non-concatenated scripts and stylesheets.

    This means that we can go into wp-config.php and define the constant ourselves. And if we do that, then we can use code like the following:

    Your code may vary from this particular implementation, but you get the point:

    Check to see if a value common to WordPress has been set. If so, then load the un-minified files; otherwise, use the minified files.

    Although this may avoid any collisions with other theme files, plugins, and so on, it will load anything that’s toggled via this flag. So, as mentioned earlier, use it with caution.

    Debugging Minified Files in WordPress was written by Tom. For more information about WordPress, development, and resources then visit Tom McFarlin’s blog.

    Read more here:: Debugging Minified Files in WordPress