Good professional knows their tools. One of the main tools that WordPress developers have at our disposal is the JavaScript developer console included in our browsers. In this post, we will see everything you need to know about the browser developer console, along with some tricks and curiosities that, perhaps, you didn’t know about.
How to Access the Developer Console
First things first: let’s see how you can open your browser’s developer console. If you’re a Firefox user, just click on the menu (upper right corner) and look for the Web Developer option, as you can see below:

Then, select Web Console:

and the console will show up in your browser, as you can see in the following screenshot. Remember that it is possible to configure where you want the panel to appear exactly. You can even set it to appear in a separate window (which comes pretty handy if you’re using multiple monitors).

If, on the other hand, you are a Chrome user, the procedure is very similar. Simply access its menu, select More Tools and then Developer Tools:

How to Use the Developer Console
Our browser’s JavaScript console is extremely helpful to debug our code, see what our scripts are logging, and run small commands and see their effects on the web in real-time. As a plugin developer for WordPress, the main utility the console has for me is obviously debug, so let’s see in detail what it offers precisely.
#1 Different Log Levels
The first reason why a developer usually opens the JavaScript console is to debug their code. When an error occurs or something is failing, you’ll probably find some info about it in the console. You can even launch your own informational messages, warnings or errors when you want!

In the previous screenshot, for example, we see that the console
object (global object whose goal is to help us debug code) has different methods for writing messages in the console:
debug
andlog
show plain messages.info
shows information messages. In Firefox they show an “info” icon next to the message.warn
shows warnings, usually pointing out a problem or something that is not quite right. It is usually highlighted in yellow and with a warning icon.error
is usually reserved for the most severe errors (that is, things that have really failed). It is shown in red and also prints a stack trace (that is, what function generated the error and all its callers).
The advantage of using different log levels is that we can choose at any time what messages we want to be displayed. For example, in the following screenshot we have deactivated the Info and Debug messages:

#2 Monitoring Execution Times
In agile, you’ll often hear this: “make it work, make it well, make it fast.” After writing some code “to make it work,” it’s not unlikely that the result is slow and inefficient. When this happens, it’s important to identify where are the bottlenecks and address them.
Although there are tools such as profilers to find the culprits and understand exactly what’s going on under the hood in great detail, sometimes we want a “quick and dirty” solution. That is, we simply want to identify the slowest function in our code… and simple timers are great at this task!
If you want to know how long a particular piece of code takes to run, start a timer at the beginning of the code (console.time
) and stop it (console.timeEnd
) when your code finishes:
console.time( 'Timer' );
// code we want to monitor...
console.timeEnd( 'Timer' );
When the code reaches the timeEnd
, you’ll see the time it took to run:
Timer: 655ms - timer ended
Notice that when we start and stop a timer, we give it a name (in my example, “Timer”). This is because we can create as many counters as we want, each with its own name, and have them all at once running.

Nelio Forms
A fantastic contact plugin using the block editor. In its simplicity lies the true power of this plugin. I love it, very versatile and it worked perfectly for me.

Wajari Velasquez
# 3 Automatic Counters
If you are interested in controlling the number of executions of any function in your code or log the number of times a loop runs, use console.count
. Each time the function is executed, you’ll get a new log in your console with the current value of the counter:

console.counter
method.#4 How to Format Your Logs
Logs are here to help us understand what is happening with our code. But that is only possible if we write logs that we can later understand…
Text Strings
At the beginning of this post, I briefly talked about all the log methods console
has. The examples I shared printed some plain text. That is, this statement:
console.log( 'Hello world!' );
printed this text:
Hello world!
What if we wanted to print an object instead? Well, this:
obj = { x: 1, y: { a: 'hola' } };
console.log( obj );
becomes this:

But what if we want to log multiple things? Do we have to use multiple calls to console.log
? Well, the answer is no, it’s not necessary. We can log everything we want with a single call:

Grouping Logs…
When we start having a lot of logs in our code (like, for example, here):
the result can end up being a bit confusing because all logs are merged into a single stream of text:
Retrieving x...
Retrieving y...
Compute result using 2 and 3
Getting max value
Result is 6
Luckily, the console
object offers a couple of methods to solve this problem: group
and groupEnd
. With them, we can group our log messages. Just create the groups (for instance, one group per function):
and they’ll show up like this:

Tables
When we work with data collections, it is not always easy to visualize them. For example, imagine we have a list of items like the following:
data = [
{ id: 1, name: 'David', surname: 'Aguilera' },
{ id: 2, name: 'Ruth', surname: 'Raventós' },
{ id: 3, name: 'Antonio', surname: 'Villegas' },
];
If we console.log
them, this is what we get:

console.log
, it will be displayed in a more or less friendly way.which is more or less OK, until we have more objects with more fields each. When facing this type of data structure, I recommend you use console.table
for logging it:

#5 How to Correctly Display Complex Types (Objects and Arrays)
Finally, I would like to end today’s post with something that not many developers know about… Let’s say, for example, that you are working on a project and want to see what the value of an object is before and after updating it. To do this, it is likely that you will console.log
the variable before making the change and afterward, as you see in the following GIF:

In the previous example, we log an object that contains a value set to 1. We then update the value to 200 and log the object again. One would expect the first log to always show the original value (1), but notice how, when we expand the object, it actually shows the new value 200. What is happening?
Basically, a log message has a reference to the object and, therefore, when we expand it, it shows us the object as it is now and not as it was when the log was made. Damn mutability!
To solve this problem, just send a copy to the log (libraries such as lodash and its cloneDeep
method make this very easy). This way, the first object logged will be a copy that can’t be mutated (because you won’t have a reference to it):

And that’s all for today! I hope you liked this post. If you want more information about everything you can do with console
, check out the documentation in MDN. Don’t forget to share it with your friends ? And if you do something different or have any advice to share with our readers, leave us a comment ?
Imagen destacada the Tim van der Kuip on Unsplash.
Leave a Reply