Expected behavior

Save settings without seeing PHP notices

Observed behavior

Notice: options.php was called with an argument that is deprecated since version 2.7.0! The bugsnag_api_key setting is unregistered. Unregistered settings are deprecated. See https://codex.wordpress.org/Settings_API

Notice: options.php was called with an argument that is deprecated since version 2.7.0! The bugsnag_notify_severities setting is unregistered. Unregistered settings are deprecated. See https://codex.wordpress.org/Settings_API

Notice: options.php was called with an argument that is deprecated since version 2.7.0! The bugsnag_filterfields setting is unregistered. Unregistered settings are deprecated. See https://codex.wordpress.org/Settings_API

Steps to reproduce

1. Configure PHP to show notices
2. Go to /wp-admin/options-general.php?page=bugsnag
3. Enter API key
4. Submit the form

Version

1.3.1

This actually seems to be due to the settings form posting to action="options.php" (as explained in https://wordpress.stackexchange.com/a/289620/144404). If I remove action="options.php" from views/settings.php the form posts without notices.

Hey guys, I would like you to consider adding WP Enforcer to help enforce WordPress standards for this plugin. You can check it out here:

https://github.com/stevegrunwell/wp-enforcer

https://stevegrunwell.com/blog/wp-enforcer/

Would love to see this plugin also inject the JS error handling, with a separate bugsnag API key for the JS bugsnag project (would of course require setup of two bugsnag projects).

This would dramatically ease the implementation of JS monitoring on Wordpress websites.

Thoughts?

This exception occurred when sending errors using the wordpress package using PHP7

Fatal error: Uncaught TypeError: Argument 3 passed to Bugsnag_Error::fromPHPException() must be an instance of Exception, instance of Error given, called in
/home/vagrant/Sites/example.com/public/app/plugins/bugsnag/bugsnag-php/Client.php on line 360 and defined in 
/home/vagrant/Sites/example.com/public/app/plugins/bugsnag/bugsnag-php/Error.php:31 

Stack trace: 
#0 /home/vagrant/Sites/example.com/public/app/plugins/bugsnag/bugsnag-php/Client.php(360): Bugsnag_Error::fromPHPException(Object(Bugsnag_Configuration), Object(Bugsnag_Diagnostics), Object(Error)) 
#1 [internal function]: Bugsnag_Client->exceptionHandler(Object(Error)) 
#2 {main} thrown in /home/vagrant/Sites/example.com/public/app/plugins/bugsnag/bugsnag-php/Error.php on line 31

Bassed on https://github.com/bugsnag/bugsnag-wordpress/blob/master/composer.json#L5 the wordpress plugin still uses V2.* of bugsnag-php.

As v3 was already released in 2016 could you upgrade the dependency for this plugin also to v3 please?

Thanks

Expected behavior

When I install bugsnag locally, I expect it to still output errors. When I have bugsnag enabled locally, no PHP errors are shown, thus making development harder

Observed behavior

It removes PHP errors from being displayed on screen, even with WP_DEBUG turned on

Version

Latest

Expected behavior

I added the $bugsnagWordpress->setReleaseStage('development'); to the theme file, per documentation. The "Test Bugsnag" button that triggers a test event should be affected by this configuration.

Observed behavior

The Test button always reports Production, which was mostly just confusing why records continued to show as Prod. A real error must be triggered for Development to appear in BugSnag dashboard.

Steps to reproduce

Configure BugSnag's setReleaseStage method, and go to BugSnag settings in the Wordpress Admin and trigger a test event.

Version

1.4.0

Thanks Bugsnag team!

Expected behavior

I am calling $bugsnagWordpress->setReleaseStage( below. I would expect it to work.

  if(isset($bugsnagWordpress) && !is_null($bugsnagWordpress)) {
    $bugsnagWordpress->setReleaseStage(get_stage_environment());
  }

Observed behavior

I am receiving error:

Method setReleaseStage does not exist on Bugsnag_Wordpress or Bugsnag_Client

How come? Obviously $bugsnagWordpress exists.

Describe the bug

if the 'bugsnag_filterfields' option isn't set, get_option('bugsnag_filterfields') will return false. this will make Bugsnag_Wordpress::filterFields return [""] (i.e. an array with one item containing an empty string (array(1) { [0]=> string(0) "" })). further down the line this array will make Error::cleanupObj believe that all values should be filtered, because https://github.com/bugsnag/bugsnag-php/blob/2.10/src/Bugsnag/Error.php#L386 will always be true (since strpos($key, "") will always return 0, and 0 is !== false).

my suggestion would be to rewrite https://github.com/bugsnag/bugsnag-wordpress/blob/master/bugsnag.php#L156 to
if ($filter_fields === '' || $filter_fields === false) {
or maybe even better
if (empty(trim($filter_fields ?? ''))) {
(to catch the case where the user has written just whitespace in the wp-admin (perhaps this line must be rewritten to support older php versions though). i could make a pr for this if you want?

pls note that setting 'bugsnag_filterfields' to "whatever\n" will yield the same problems since Bugsnag_Wordpress::filterFields then will return ["whatever",""] and then filter everything out based on the second item in the array. you should probably take a look at https://github.com/bugsnag/bugsnag-wordpress/blob/master/bugsnag.php#L160 and make sure it doesn't return any empty strings in the array.

Steps to reproduce

1. do nothing
2. trigger an error
3. see the error in the dashboard with all custom fields and request and cookies set to [FILTERED]

Environment

• Bugsnag version: 1.6.1
• PHP version: 8
• Wordpress version: 6.0.2

Expected behavior

$bugsnagWordpress to be Bugsnag_Wordpress object

Observed behavior

$bugsnagWordpress is null

Steps to reproduce

Run wp-cli's eval-file ( https://developer.wordpress.org/cli/commands/eval-file/ ) to file which has a $bugsnagWordpress variable

Version

1.3.0

Additional information

Suggested fix:
Add: global $bugsnagWordpress;
before: $bugsnagWordpress = new Bugsnag_Wordpress();
On bugsnag.php

Allows people to use setContext() etc

Not sure if this is related to PHP7 but I'm getting the following error very frequently:

PHP Fatal Error POST /wp-cron.php

PHP Fatal Error Uncaught TypeError: Argument 3 passed to Bugsnag_Error::fromPHPException() must be an instance of Exception, instance of Error given, called in /app/htdocs/assets/plugins/bugsnag/bugsnag-php/Client.php on line 360 and defined in /app/htdocs/assets/plugins/bugsnag/bugsnag-php/Error.php:31
Stack trace:
#0 /app/htdocs/assets/plugins/bugsnag/bugsnag-php/Client.php(360): Bugsnag_Error::fromPHPException(Object(Bugsnag_Configuration), Object(Bugsnag_Diagnostics), Object(Error))
#1 [internal function]: Bugsnag_Client->exceptionHandler(Object(Error))
#2 {main}
  thrown 
    assets/plugins/bugsnag/bugsnag-php/Error.php:31 [unknown]

Only happening in staging and production (both are 1:1 replicas) but not VVV. staging/production are 7.0.3, my VVV install is 5.5.9. Seems similar to bugsnag/bugsnag-php#102

Expected behavior

$bugsnagWordpress->setNotifyReleaseStages(['production']);
Should only report errors from production env

Observed behavior

Reports errors from all env

Steps to reproduce

• Install plugin
• Add $bugsnagWordpress->setNotifyReleaseStages(['production']); to the theme functions file
• Produce an error/exception

Version

1.3.1

Additional information

In Configuration.php in the method shouldNotify is $this->notifyReleaseStages = NULL, setNotifyReleaseStages in Client.php is never triggered for what I was able to debug.

https://docs.bugsnag.com/platforms/php/wordpress/configuration-options/#setnotifyreleasestages

Also added on the Wordpress support forum: https://wordpress.org/support/topic/bugsnagwordpress-setnotifyreleasestages-doesnt-work/

It would be really useful to report plugin/themes versions out of the box, maybe this can be included in the runtimeVersions section?

Describe the bug

Install/Activate Gravity Forms 2.5.3 or higher, site will slow down and bugsnag will just start filling with lots of errors, such as the example below:

PHP Warning · DOMDocument::loadXML(): xmlParseEntityRef: no name in Entity, line: 838

https://screenshots.brandonhubbard.com/9ZudRlN6
https://screenshots.brandonhubbard.com/lluNkRYK

Environment

• Bugsnag version: 1.6.0
• PHP version: 7.4
• Wordpress version: 5.7.2
• Gravity Forms version: 2.5.6

We should check for cURL support in PHP and show an error/warning banner on the bugsnag configuration screen.

Expected behavior

I would like to enable display_errors

Observed behavior

dispaly_errors is turned off by Bugnsag plugin

Steps to reproduce

None

Version

1.3.0

Additional information

I had to go deep to understand where the display_error was being turned off. I used ini_get('display_errors') on wp-settings.php where it loads the plugins and found out that Bugsnag disables it. I couldn't find in the plugin where to turn it on.

• Installed plugin as per Wordpress standards.
• Then this was thrown up after adding my API key for the project and then clicking save.

GET /wp-admin/options-general.php

Following that, it renders the site useless (blank screen).

Bugsnag helped me find that screen_icon() is deprecated. My version is 1.3.0, this repo has version 1.3.0, so I wanted to PR it, but then I see that it's already been fixed (commit)

Soo... this 1.3.0 does not match the wordpress.org 1.3.0. And this being a WP plugin, I'd say it's pretty important to get the latest version up to wordpress.org. The "wp repo" version already has a warning on it for not being updated for a long time so it's about time.

When developing locally I would like to use PHP's native error handler instead of Bugsnag's, but still have the same code base/database for my local and live server (and not being forced to manually deactivate the plugin for different servers).

ATM it's impossible to override with the bugsnag_set_error_and_exception_handlers filter from within functions.php (since it's applied directly when the plugin loads (which is before the theme)).

Expected behavior

add_filter('bugsnag_set_error_and_exception_handlers', function() {
    return false;
});

should disable this plugin's custom error handlers.

Observed behavior

Nothing is happening with the above filter present in my theme's functions.php.

Steps to reproduce

See above.

Version

1.3.0

Additional information

If I rewrite the Bugsnag_Wordpress constructor so that activateBugsnag() is called on init:

        add_action('init', array($this, 'activateBugsnag'));

and change activateBugsnag() to public, the error handlers are indeed disabled, but I get this warning:

Warning: strpos(): Empty needle in plugins\bugsnag\bugsnag-php\Error.php on line 386

The same warning appears without the modified class if I run restore_error_handler(); in my functions.php.

As this is a WordPress plugin, I would like to see it move into a direction to better support WordPress Coding Standards.

For those sites that use CloudFlare it would be great to track their proxy info:

$_SERVER['HTTP_CF_IPCOUNTRY'] and $_SERVER['HTTP_CF_RAY']

Hi,
I need to integrate Mangopay API into wordpress site.
I am new to wordpress and mangopay too.
Could you please help me?
Thanks in advance

I can't find any way to call the setNotifyReleaseStages(). How can I configure that with WordPress?

WordPress now has a default function called wp_get_environment_type, this should be used instead of WP_ENV for the release stage.

https://developer.wordpress.org/reference/functions/wp_get_environment_type/

Hi,
Due to the way we work on our sites across multiple environments (3-6 Development servers, plus Staging and Production, etc), we occasionally have issues with the Bugsnag plugin being enabled on the wrong environment.
For example, a Developer brings in the database from the Production site to make local changes, and this causes his Bugsnag installation to start reporting bugs.

To get around this we added the following method to the Bugsnag class in the plugin:

private function apiKey()
{
  return defined('BUGSNAG_API_KEY') ? BUGSNAG_API_KEY : get_option('bugsnag_api_key');
}

If the BUGSNAG_API_KEY constant has been defined, it will use that. Otherwise it falls back to the key defined in the database (which we usually leave blank).

We can then add code like this in our configuration:

if(WP_ENV !== 'development') {
  // Only log Bugsnag errors on Staging/Production
  define('BUGSNAG_API_KEY', '(OUR_API_KEY)');
}

Is there any chance of a similar feature being added to this plugin? We're more than happy to contribute a PR to save us from having to maintain our own fork, with some guidance from the plugin maintainers. Our current fork is out of date and doesn't include all the new network site options, so this could cause some issues if incorrectly implemented.

Thanks in advance

Expected behavior

When error reporting is set to Warning, then Bugsnag shouldn’t report silenced PHP errors. For example, the following code shouldn’t report a warning:

@unlink( '/path/to/inexistent/file.jpg' );

Observed behavior

Bugsnag reports PHP warnings for code that is silenced with an @.

Steps to reproduce

1. Put this code in functions.php of your theme and reload the page.

   @unlink( '/path/to/inexistent/file.jpg' );

2. See error in the dashboard.

I’m not sure, but this logic might be what causes the warning to be reported:

https://github.com/bugsnag/bugsnag-php/blob/e50a26a5535f5e4ffb386a449710f2ce9c050287/src/Configuration.php#L543-L550

PHP’s documentation for error control operators clearly states:

If you have set a custom error handler function with set_error_handler() then it will still get called, but this custom error handler can (and should) call error_reporting() which will return 0 when the call that triggered the error was preceded by an @.

In shouldIgnoreErrorCode(), the function might return without checking error_reporting(). So I’m guessing that this is why silenced errors are reported.

Version

Bugsnag: 1.3.1
WordPress: 5.0.3

Additional information

Tell me if you need some more information.

Hi there wonderful people,

After running into issue #13, I noticed the WordPress repo for this plugin is still stuck on 1.1.2.

It's a real "gotcha", as the official installation instructions still recommend using this outdated version which doesn't work on all PHP7 installations. I had to download and rebuild from the latest commit to get things working again.