Configuration options

All available options for configuring BugSnag with WordPress apps.

Configuration should be put in the theme’s functions.php file.

Configuration options can be set in the global scope:

$bugsnagWordpress->setReleaseStage('development');

or within a function:

function configure_bugsnag() {
    global $bugsnagWordpress;
    $bugsnagWordpress->setReleaseStage('development');
}

configure_bugsnag();

The BugSnag client object has several properties which help you customize the content of error reports, and how the reports are delivered.

setAppVersion

If you tag your app releases with version numbers, BugSnag can display these on your dashboard if you call setAppVersion:

$bugsnagWordpress->setAppVersion('1.2.3');

setAutoNotify

Controls whether bugsnag should automatically notify about any errors it detects in the PHP error handlers.

$bugsnagWordpress->setAutoNotify(false);

By default, this is set to true.

setBeforeNotifyFunction

Set a custom function to call before notifying BugSnag of an error. You can use this to call your own error handling functions, to add custom tabs of data to each error on your BugSnag dashboard, or to modify the stacktrace.

$bugsnagWordpress->setBeforeNotifyFunction(function ($error) {
    // Inspect or modify the error report here
});

See the customizing error reports reference for more details.

setContext

BugSnag uses the concept of “contexts” to help display and group your errors. Contexts represent what was happening in your application at the time an error occurs. By default this will be set to the current request URL and HTTP method, eg “GET /pages/documentation”.

If you would like to set the bugsnag context manually, you can call setContext:

$bugsnagWordpress->setContext('Backport Job');

setEndpoint

Set the endpoint to which to send error reports. By default we’ll send reports to the standard https://notify.bugsnag.com endpoint, but you can override this if you are using BugSnag On-premise, to point to your own BugSnag endpoint:

$bugsnagWordpress->setEndpoint("http://bugsnag.internal.example.com");

setErrorReportingLevel

Set the levels of PHP errors to report to BugSnag, by default we’ll use the value of error_reporting from your php.ini or any value you set at runtime using the error_reporting(...) function.

If you’d like to send different levels of errors to BugSnag, you can call setErrorReportingLevel:

$bugsnagWordpress->setErrorReportingLevel(E_ALL & ~E_NOTICE);

See PHP’s error reporting documentation for allowed values.

setFilters

Sets the strings to filter out from the metaData arrays before sending them to BugSnag. Use this if you want to ensure you don’t send sensitive data such as passwords, and credit card numbers to our servers. Any keys which contain these strings will be filtered.

$bugsnagWordpress->setFilters(['password', 'credit_card']);

By default, this is set to be ["password"].

setMetaData

Sets additional metadata to send with every bugsnag notification

$bugsnagWordpress->setMetaData([
    'account' => [
        'paying' => true,
        'name' => 'Acme Co'
    ]
]);

setNotifyReleaseStages

By default, BugSnag is notified of errors that happen in any releaseStage If you would like to change which release stages notify BugSnag of errors you can call setNotifyReleaseStages:

$bugsnagWordpress->setNotifyReleaseStages(['development', 'production']);

setProjectRoot

BugSnag marks stacktrace lines as in-project if they come from files inside your projectRoot.

You can set this manually by calling setProjectRoot:

$bugsnagWordpress->setProjectRoot('/path/to/your/app');

If your app has files in many different locations, you should consider using setProjectRootRegex instead.

setProjectRootRegex

If your app has files in many different locations, you can set the a regular expression for matching filenames in stacktrace lines that are part of your application:

$bugsnagWordpress->setProjectRootRegex('('.preg_quote('/app').'|'.preg_quote('/libs').')');

setProxySettings

Note: Proxy configuration is only possible if the PHP cURL extension is installed.

If your server is behind a proxy server, you can configure this as well:

$bugsnagWordpress->setProxySettings([
    'host' => 'bugsnag.com',
    'port' => 42,
    'user' => 'username',
    'password' => 'password123'
]);

Other than the host, none of these settings are mandatory.

setReleaseStage

If you would like to distinguish between errors that happen in different stages of the application release process (development, production, etc) you can set the releaseStage that is reported to BugSnag.

$bugsnagWordpress->setReleaseStage('development');

By default this is set to “production”.

setSendCode

BugSnag automatically sends a small snippet of the code that crashed to help you diagnose even faster from within your dashboard. If you don’t want to send this snippet, you can call setSendCode:

$bugsnagWordpress->setSendCode(false);

setSendEnvironment

BugSnag can transmit your $_ENV environment to help diagnose issues. This can contain private/sensitive information, so we do not transmit this by default. To send your environment, you can call setSendEnvironment:

$bugsnagWordpress->setSendEnvironment(true);

setTimeout

Define a custom timeout in seconds for the connection when notifying BugSnag.

$bugsnagWordpress->setTimeout(2);

By default, this is set to be 2.

setType

You can set the type of application executing the current code by using setType:

$bugsnagWordpress->setType('resque');

This is usually used to represent if you are running plain PHP code “php”, via a framework, eg “laravel”, or executing through delayed worker code, eg “resque”. By default this is null.

setUser

BugSnag helps you understand how many of your users are affected by each error, and allows you to search for which errors affect a particular user using your BugSnag dashboard. To send useful user-specific information you can call setUser:

$bugsnagWordpress->setUser([
    'id' => '123456',
    'name' => 'Leeroy Jenkins',
    'email' => 'leeeeroy@jenkins.com',
]);

The name, email and id fields are searchable, and everything you send in this array will be displayed on your BugSnag dashboard.

The id field is used also used by BugSnag to determine the number of impacted users. By default, we use the IP address of the request as the id.