Configuring the JavaScript error log
The JavaScript error log offers a number of configurable options to customise which errors are captured by the log, the level of detail recorded, and how long data is retained.
Take a look at the video overview for a quick introduction to the options available, or keep reading for further details.
Video Overview
Configurable Options
The following configurable options are available for the JavaScript error log.
Error Type
This option allows you to select which types of JavaScript errors to log.
You can select one or more of the following options:
- Runtime Errors
Errors that occur while code is executing (e.g., calling an undefined function or accessing a missing variable). - Unhandled Promise Rejections
Failures from promises (async operations) that aren’t caught with a .catch() or try…catch.
Recommended Settings
In most cases, you will likely want to log both runtime errors and unhandled promise rejections. For live/production sites, both have the potential to negatively impact user experience on your site, and for developers, both could be indicative of a problem in your code.
Scope
This option allows you to select which sources to log errors for.
You can select one or more of the following options:
- WordPress Core Errors
Log errors originating from core WordPress files. - Theme Errors
Log errors originating from WordPress theme files. - Plugin Errors
Log errors originating from WordPress plugin files.
For theme and plugin errors, the configuration page offers a further option:
- All themes/plugins
- All themes/plugins except selected
- Selected themes/plugins only
Note: Logtastic will track the source of JavaScript errors based on the location of the JavaScript file (eg. /plugin/example.js will be recorded as the source being the relevant plugin), however, inline JavaScript will always be recorded as WordPress core.
Recommended Settings
In most cases, you will likely want to log all WordPress core, theme and plugin errors, as all have the potential to cause fatal errors which can impact your site functionality/experience. Whilst in a development environment, you may want to focus on errors originating from your own custom theme/plugin, it may still be worthwhile logging errors from other sources, as it is possible that an error in your code could trigger an error or conflict in the WordPress core or another third party plugin or theme.
Stack Trace
Where possible, the JavaScript Error Log can attempt to capture a full stack trace (also known as a backtrace) for each error. The stack trace records a list of the functions that were called leading up to an error being generated. This can be useful tool when debugging errors.
The following options are available:
- Should a stack trace be captured for each error?
- Yes
- No
Recommended Settings
Whether or not to capture stack traces is largely a matter of personal preference. Stack traces can provide additional context when debugging errors and, given the relatively small size of a typically JavaScript stack trace, have a relatively low impact on database storage space.
Session Information
Where possible, the JavaScript Error Log can attempt to capture additional session information for each error, including the full url of the page on which the error occurred and information about the user’s web browser.
The following options are available:
- Should session information be captured for each error?
- Yes
- No
Recommended Settings
Whether or not to capture session information is largely a matter of personal preference. Session information can provide additional context when debugging errors and, given the relatively small size of a the captured data, have a relatively low impact on database storage space.
Log Retention
The log retention setting allows you to manage log storage by defining how long captured errors and their occurrences are stored for.
The available options are:
- Keep records indefinitely
- Delete records after 30 days
- Delete records after 7 days
Recommended Settings
The recommended settings will vary depending on your use case and personal preferences. In most cases, retaining records for 30 days will strike a good balance between error visibility and efficient use of storage space.
Ignored Errors
If you have ignored any errors, via the Delete & Ignore action on the view error log page, these will be displayed here. If you no longer want to ignore a particular error, you can click the Stop Ignoring button next to that error. Any future occurrences of that error will then be logged.
