Configuration
The plugin is configured from a single screen in wp-admin. After activation, go to Settings → Quiet Guard (a user with the manage_options capability is required).
All values are stored together in one WordPress option named laravel_monitor_options, under the settings group laravel_monitor. The form is a standard WordPress Settings API page titled Quiet Guard, with a single Connection section.
Fields
The settings screen exposes these fields:
| Field label | Option key | Example | Notes |
|---|---|---|---|
| Enabled (1/0) | enabled | 1 | Master switch. Any non-empty value is stored as 1; empty is stored as 0. Capture only starts when this is on and both URL and key are set. |
| Server URL | url | https://monitor.example.com | Base URL of your Quiet Guard server. Sanitised with esc_url_raw. Do not add a path, the plugin appends /api/v1/ingest itself. |
| Project key | key | lm_xxxxxxxx | The per-project API key from your Quiet Guard dashboard. Sent as an HTTP Authorization: Bearer token. Sanitised with sanitize_text_field. |
| Environments (comma-separated, empty = all) | environments | production,staging | Optional list of environment names. See the note below about its current behaviour. |
| Release (optional) | release | 2024.05.1 or a git SHA | Identifier for the deployed version. Attached to every reported event so the server can attribute issues to a deploy. |
All five fields render as plain text inputs. Click Save Changes to persist them.
Minimum setup
To start reporting you only need three things:
- Enabled set to
1. - Server URL, the base URL of your server (no trailing path).
- Project key, created when you add the project in the Quiet Guard dashboard. See the server documentation for how projects and keys are created.
If the plugin is enabled but the URL or key is empty, nothing is sent and nothing errors, the plugin simply stays silent.
How the key is sent
Reports are sent as an HTTPS POST to {Server URL}/api/v1/ingest, with the project key in the Authorization: Bearer … header and a JSON body. The request is bounded by a short timeout so a slow or unreachable server never blocks the page.
Release
Setting a Release lets the server group issues by deploy. A hexadecimal git SHA is ideal, because the server can map an issue's release to the matching commit it has synced for the project. Update this value each time you deploy.
A note on Environments
The Environments field is stored and forwarded to the underlying core configuration, where it is intended as an allowlist of environments to report from (empty means "report from everywhere").
In the current version the WordPress adapter does not compute a "current environment" to compare against, so this list has no filtering effect yet, every captured error is reported regardless of what you enter here. The field is wired through for forward compatibility; environment-aware filtering for WordPress is planned. To stop reporting from a given site today, turn Enabled off.
Advanced options (not in the UI)
Two further keys are read from the same laravel_monitor_options option but are not exposed on the settings screen, so they use their defaults unless set programmatically (for example via update_option):
| Option key | Default | Purpose |
|---|---|---|
timeout | 3 | HTTP timeout, in seconds, for each report. |
trace_limit | 0 | Stack-trace frames sent per exception. 0 (the default) sends the full stack trace; a positive value trims the trace to that many frames. |
Programmatic values are safe to set: the settings sanitizer preserves timeout and trace_limit when the settings screen is saved, so a value written via update_option() survives later saves from wp-admin.
Next step
Continue to Usage to see what the plugin captures and how to confirm it is working.
You are reading the WordPress Plugin v1.0 documentation.