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 project key (an empty server URL meaning the hosted service), it registers three global PHP handlers (via the core ErrorHandler):

• Uncaught exceptions: any Throwable that reaches PHP's exception handler is reported.
• PHP errors: an error raised during the request is wrapped as an exception and reported when its severity is E_USER_ERROR or E_RECOVERABLE_ERROR. 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.

Why warnings and notices are not reported

Every severity used to be forwarded, one synchronous HTTP call each. On WordPress a warning from any theme or plugin lands in this handler, so a single warning inside a loop over five hundred rows was five hundred blocking calls in one page load: an outage as far as the visitor is concerned, and a free plan's monthly events burnt in a day.

Two more guards apply on top of that floor: the same error on the same file:line is reported once per request, and at most twenty errors are reported in one request, because a floor cannot see a loop. Fatal shutdowns are unaffected, they are caught by the shutdown hook and not by this one.

Reporting is designed never to break your site: if the server is slow or unreachable, 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 Project key is filled in;
• the Server URL is optional: empty, it means the hosted service; filled, it is your server's address (a trailing /api or /api/v1 is fine, any other path is not);
• 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).

Then read the log. The plugin writes its own diagnostics with error_log(), which means wp-content/debug.log wherever WP_DEBUG_LOG is on: a wrong key, a wrong address or a payload the server refused each produce a line beginning with [Quiet Guard], naming the status and the address. This client passed no logger at all until now, so a plugin that had never worked had no way to tell you, no exception, no admin notice and no log line.

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, a hyphen counting as an underscore from version 0.3.1, applied recursively through nested arrays) has its value replaced with [scrubbed]; a configured password therefore also masks user_password:

password, pwd, passphrase, token, signature, secret, authorization,
cookie, referer, referrer, auth, api_key, nonce, salt, logged_in, db_

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.