Usage

Once the plugin is configured and enabled, there is nothing else to call from your code. The plugin installs global PHP handlers automatically and reports problems for you.

What is captured automatically

When the plugin is enabled with a valid server URL and project key, it registers three global PHP handlers (via the core ErrorHandler):

• Uncaught exceptions: any Throwable that reaches PHP's exception handler is reported.
• PHP errors: warnings, notices and other errors raised during the request are wrapped as exceptions and reported. The handler respects @-suppression and your error_reporting level, and it lets PHP's own handler run afterwards, so existing behaviour is unchanged.
• Fatal shutdowns: on shutdown the plugin inspects the last error and reports it if it was fatal (E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR). This is how a fatal that terminates the request still reaches your dashboard.

Each report contains the exception class, message, file and line, plus the full stack trace by default (trace_limit is 0); a positive trace_limit trims the trace to that many frames. The configured release is attached to every event.

Reporting is designed never to break your site: if the server is slow or unreachable, the failure is swallowed silently and the page continues to render.

Verifying it works

After saving your settings, trigger a harmless error and confirm it appears in your Quiet Guard dashboard for the project. A quick way is to add a temporary snippet to a theme or a small must-use plugin:

add_action('init', function () {
    throw new RuntimeException('Quiet Guard test exception');
});

Load any front-end page once, then check the project's Issues in the dashboard, a RuntimeException with the message "Quiet Guard test exception" should appear. Remove the snippet afterwards.

If nothing arrives, re-check that:

• Enabled is 1, and both Server URL and Project key are filled in;
• the Server URL is the base URL only, with no trailing path;
• the server is reachable over HTTPS from the WordPress host;
• the plugin folder was built with composer install so its vendor/ directory exists (see Installation).

Scrubbing of sensitive data

Before any report leaves the site, its context data is passed through the core scrubber, which masks values by key. Any key whose name contains one of the following (case-insensitive substring match on key names, applied recursively through nested arrays) has its value replaced with [scrubbed]; a configured password therefore also masks user_password:

password, pwd, passphrase, token, secret, authorization,
cookie, referer, referrer, auth, api_key, nonce

This keeps obvious credentials out of the data sent to your server. The scrubbing list is defined inside the WordPress adapter and is not editable from the settings screen in this version.

A second pass runs on top of it, from the core and with no setting of its own: values shaped like an email address, an IBAN, a card number, a French social security number or a French phone number are masked wherever they sit, including in the text of an error message, and the mask names what it hid ([redacted:email]).

Reporting endpoint

For reference, reports are delivered as an HTTPS POST to:

{Server URL}/api/v1/ingest

authenticated with the project key as a Bearer token. This is the same platform-neutral ingestion API used by the Laravel and Symfony clients, so a WordPress site appears alongside them in the same dashboard.

Next step

See Upgrading for how to update the plugin.