How to use your browser console to find and resolve problems

The browser console is one component of the Web Inspector tool that is included with most desktop browsers. Developers use the console to debug Javascript errors as well as HTML and CSS code. It’s incredibly handy to help narrow down problems, particularly ones like this:

• Errors that don’t appear immediately upon page load, but rather occur after the page has loaded. Whether after a period of time or after interacting with something else on the page. E.g.: a button that doesn’t work.
• Problems with page rendering, such as missing images, styles (colours, layout, etc) or iframes like and embedded Google Maps.
• Trouble or glitches with website builders and page builder visual editors like BeaverBuilder, Elementor, or Divi.
• Beaver Builder specific: you receive an error saying “Beaver Builder has detected a plugin conflict that is preventing the page from saving.” ( In technical terms there’s probably a PHP error in Ajax. )
• Some types of WordPress plugin conflicts
• Mixed content warnings

How to access your browser console

Here’s how to get to your browser console in all major browsers. If your browser is not in the list, you can always find the answer to this in the developer’s knowledgebase.

• Google Chrome: under the View menu, choose Developer > JavaScript Console
• Mozilla Firefox: under the Tools menu, choose Web Developer > Web Console
• Apple Safari: under the Safari menu, choose Preferences > Advanced (tab) > Check the box at the bottom called “Show Develop menu in the menu bar”. Then go to the Develop menu > “Show JavaScript Console”
• Microsoft Edge: under the Tools menu, choose Developer > JavaScript Console

Here’s what each of them looks like. They’re all very similar.

---

Most warnings (except mixed-content warnings) are unlikely to have any effect on the functionality of the website, so you can simply ignore those unless you have absolutely no other leads (like errors).

Handling Server Errors

If you see errors that say something like “The server responded with a status of XXX”, match up that HTTP error code (the three numbers) with the errors listed below for further troubleshooting:

• 403: This is either a permissions error or a firewall block. See our guide to viewing and interpreting your web server logs.
• 404: Either the file is missing and the solution is to ensure the referenced file exists at the path provided, or our guide to resolving missing stylesheets or javascript files should help.
• 50x (or any others): See our guide to viewing and interpreting your web server logs.

Resolving Mixed Content Warnings

This means some of the page content is coming from a variation of the URL that you’re accessing the site with. For example if you’re visiting the site at https://websavers.ca but images are loaded from http://www.websavers.ca both the protocol (http vs. https) and domain (websavers.ca vs. www.websavers.ca) are different. The most common reason for mixed content errors is the HTTP vs HTTPS URL differential on resources like photos. Look for errors and/or warnings like this:

[Warning] The page at https://your_url/ was allowed to display insecure content from http://your_url/wp-content/uploads/2015/12/web-design.jpg. (your_url, line 857)

These indicate which files are not being loaded via HTTPS. You will need to find where each of the listed content items (photo, javascript, css file, etc) is being loaded in the website code or website editor, such as the WordPress admin (e.g.: on a page? In the theme settings? In the plugin settings?), and change them to any of the following URL schemes, which will resolve this problem:

1. Relative URLs by removing the entire first part up to the end of the domain. Ex: /wp-content/subdir/myfile.jpg
2. Protocol Agnostic URLs by replacing the http:// with simply //. Ex: //websavers.ca/wp-content/subdir/myfile.jpg
3. Absolute URLs by simply swapping http with https. Ex: https://websavers.ca/wp-content/subdir/myfile.jpg

Or, if you’re using WordPress, you can take the easy way out and use a plugin that automatically forces the switch to https.

Fixing Page Builder Saving Issues

If you’re encountering an error while saving pages with a page builder like Divi, Beaver Builder, or Elementor, the browser console can help narrow done those errors. But before diving into the console to find a solution, it’s best to try fixing it with simpler fixes like:

1. Always check for updates to the page builder and any addons for it (like Ultimate Addons or PowerPack for BeaverBuilder). You should not rely on WordPress’s update checks: manually check the builder’s website directly for new versions and install any that you find. Then clear your server cache and browser cache and test again.
2. If you’re using the CrazyEgg WordPress plugin, disable it and try using the builder again. As of version 2.2, we have received reports that it conflicts with BeaverBuilder. The CrazyEgg devs probably need to exclude ?fl_builder so that their scripts do not load when you’re in the builder. (Or I suppose exclude their scripts when any admin is logged in).
3. Check in your hosting control panel for the ability to change the PHP config values max_input_vars from the default of 1000 to 5000 for most intensive page building tools (we set it to 5000 for all hosted with us). Also look for the memory_limit config value and change it to 256M or 512M.
   Tip: some page builders, like Divi, use a ridiculous amount of input vars and might require this value be set to 10000 or even 15000. Similarly Divi often requires 512M of memory (no wonder it can be slow to save).
4. Check for 403 errors in the logs using our guide here. If you’re hosted with us, that guide will also show you how to either temporarily disable the mod_security firewall or exclude the offending rule to bypass this error.
5. If the issue isn’t fixed by increasing those PHP configuration values nor by identifying firewall conflicts, the remaining option is to use the section below to further troubleshoot specific JavaScript errors.

Narrowing Down JavaScript errors

This is a trickier one. If you see Javascript errors, they’ll indicate the .js file in which the error occurs and on what line. However if the JavaScript is minified/optimized, even a seasoned developer may not be able to trace the error very clearly.

Tip: if you’re using a CMS like WordPress, login to the admin before then attempting to reproduce the error. You’re likely to get more readable errors, or at bare minimum clear file paths to the JavaScript file, when logged in.

Your best next step is to try to determine where the JavaScript code is coming from. For example, if you’re using WordPress and the console indicates the .js file is in wp-content/plugins/bb-plugin/ then the JavaScript is part of BeaverBuilder. If you keep reading along the file path, it might even tell you what specific BeaverBuilder module the error comes from.

This way you can check to see if there’s a specific update for the plugin that’s reporting the JavaScript error that might fix the issue, or at least you’ll have a very specific JavaScript error to report to the plugin’s developers.

---

Experiencing an error in your JavaScript console that this guide hasn’t addressed? Let us know in the comments!