外掛說明
ScriptTrace: JS Error Logger captures frontend JavaScript errors, unhandled promise rejections, and failed script, image, and stylesheet loads. Reports are sent to your WordPress REST API and stored in a local database table.
- View captured errors under the dedicated ScriptTrace: JS Error Logger admin menu.
- Group repeated errors and count their occurrences.
- Record messages, available stack traces, page and source URLs, line and column numbers, and user agents.
- Enable or disable logging and exclude logged-in administrators.
- Keep records for 7, 30, 90, or 180 days, or indefinitely.
- Optionally copy each unique error to the PHP error log at most once per hour across visitors and pages. Reports continue to be stored and counted normally.
Logging is enabled by default. Logged-in administrators are excluded by default, data retention defaults to 30 days, and PHP log mirroring is disabled by default.
Reports are stored on your WordPress installation; the plugin does not send them to an external logging service. Error messages, stack traces, and URLs can contain information supplied by other scripts on your site.
Quality Assurance
This plugin is community-tested on PluginPeer, an independent platform for WordPress plugin quality assurance.
安裝方式
- Upload the plugin ZIP through Plugins > Add New > Upload Plugin, or copy the script-trace folder into wp-content/plugins.
- Activate ScriptTrace: JS Error Logger.
- Open ScriptTrace: JS Error Logger > Settings to configure capture, retention, and optional PHP log mirroring.
- Browse the frontend as an anonymous visitor, then open ScriptTrace: JS Error Logger > All Errors to view captured reports.
常見問題集
-
Why are my administrator’s errors missing?
-
Ignore Administrators is enabled by default. Test in a private window without logging in, or disable this option and reload the frontend.
-
Does the plugin capture every message in the browser console?
-
No. It captures browser error and unhandled rejection events. Calls to console.error() and exceptions evaluated directly by DevTools are not equivalent to page error events. Errors that occur before the listener loads cannot be captured.
-
Where do copied PHP log entries go?
-
They use PHP’s configured error_log destination. When WordPress debug logging is active, this can be wp-content/debug.log or a custom WP_DEBUG_LOG path. The plugin does not enable WordPress debug mode.
-
How does hourly grouping work?
-
Errors are grouped by type, message, source URL, line, and column. Page URL and visitor are not part of the grouping key. The first report is copied immediately; duplicates are suppressed in the PHP log for one hour, while database occurrence counts continue to increase. The next report after that hour can be copied again. Deleting stored errors also removes their mirroring timestamps.
使用者評論
這個外掛目前沒有任何使用者評論。
參與者及開發者
變更記錄
1.0.7
- Fix settings labels so clicking them toggles the associated checkbox or focuses the data retention selector.
1.0.6
- Simplify error details by removing the separate Environment, Line Number, and Column Number fields.
1.0.5
- Prevent AJAX list actions from resubmitting a previous bulk action.
1.0.4
- Fix bulk status changes and deletion in the error list.
- Restore error details, status updates, and individual row actions.
- Fix Delete All Resolved and Clear All Logs, including empty logs.
1.0.2
- Fix error reporting in WordPress Playground and SQLite installations by using a transaction instead of MySQL advisory locks.
1.0.1
- Fix settings registration and error-list rendering.
- Register the reporting endpoint for anonymous frontend requests.
- Capture failed resource loads and preserve reports received in bursts.
- Add optional hourly PHP error log mirroring.
1.0.0
- Initial release.