stayallive

Did you also configure WP_SENTRY_ERROR_TYPES (https://github.com/stayallive/wp-sentry#wp_sentry_error_types-php) If you did, you might have excluded the notices?

There is also a possibility that some plugin is re-setting the error reporting level (seens plenty of those int he past) causing those notices (often silenced) to not show up in Sentry.

If you didn’t set it already you can try to set it like define( 'WP_SENTRY_ERROR_TYPES', E_ALL ); which might help.

It’s also possible those errors occur before the Sentry plugin is even loaded, but that is hard to tell from my end, for more info see: https://github.com/stayallive/wp-sentry#capturing-plugin-errors.

That looks good! Events are flowing. So what exactly isn’t working then? ??

And having 2 projects is not a must but it can be useful sometimes. Both option (having a single or multiple projects) should work fine.

Good to hear the JS tracker is working at least!

Have you sent a test error from the wp-admin test page already and searched for the ID presented in your Sentry project?

Also check to make sure you are not over quota already, that will also drop events so we’d be looking until next month ??

Let me know what the wp-admin test page gives you and we’ll go from there!

I’d of course would never recommend anything so drastic… but yeah.

I guess in a managed environment it might make sense but they could also (by accident) collect a lot of sensitive data from the context Sentry collects if they are actively tracking errors on the site which might or might not be clear.

Sorry. No. We already are actually using one of those for our own dependencies. The problem is that this is the Sentry plugin, namespacing our own SDK makes no sense and is also hard to explain to people why they can’t use the PHP docs because every function is called differently because they are namespaced and/or scoped. And that is even besides the point that having multiple Sentry SDKs has some unknown interactions when handling errors.

Unfortunately this needs to be fixed on the GoDaddy side or you need to use the SDK they include and supply your own DSN which might work if you really wanted too ??

In all the years maintaining this plugin you are the first with this issue and I don’t think there will be any effort in this plugin to allow this to function any time soon if ever. Hope you’ll be able to work around it!

Hi Jeremy,

It looks like GoDaddy already includes (not clear if they are using it or not) the Sentry SDK.

Unfortunately there is not much I can do about this… I don’t know what the GoDaddy plugin does or how needed it is but the two plugins cannot be installed together.

Hi @wproscott, as far as I am aware neither my plugin nor the Sentry SDK makes a call to https://www.example.com. Is it possibly you can share the page where this is happening and/or the report details about this “mixed content” issue? I think the scanner is just seeing the http URL and assuming the worst, no request is actually made as far as I can tell.

If you want you can open an issue with the Browser SDK since I have no control over it from this plugin, we just load the SDK: https://github.com/getsentry/sentry-javascript

Hi!

You can for sure, you have to tinker with the Sentry SDK options, it is explained here: https://github.com/stayallive/wp-sentry#wp_sentry_options.

In your case you can do $options->setMaxRequestBodySize('none') to never send any request body.

Hope that helps!

Good to hear, make sure to never place anything after that line, it’s there for a reason ??

Hi!

There are 3 things to check before we go on:

• Did you add the WP_SENTRY_PHP_DSN in your wp-config.php _BEFORE_ the That's all, stop editing! Happy blogging. line? If you put it after it might have no effect so try placing it at the top near the database credentials
• Do the errors occur AFTER the plugin is loaded? Read a little more about this here: https://github.com/stayallive/wp-sentry#loading-sentry-before-wordpress
• Are you using sentry.io and did you exceed your event limits? Events are dropped if you exceed your plan limits.

If the above information doesn’t help we can continue if you can provide a little more information about what kind of errors are not logged to Sentry that you would expect to show up in Sentry and where those errors occur?

For future readers, Bryan and I exchanged a few e-mails and we figured out another developer left a Sentry.init() call in the theme code causing the setting from the WordPress plugin to be discarded resulting in the filtering not working correctly. The fix was removing the extra Sentry.init() call and everything worked as expected. So if you have a similar issue make sure you don’t have a Sentry.init() call in your own theme or plugin code.

I am not too sure anymore what you want to filter. So let’s try and get it straight because I feel like you are mixing 2 things or we are not understanding each other.

There are 2 Sentry trackers in this plugin, the PHP and JavaScript/Browser tracker.

The PHP tracker can be partially configured using constants and the full PHP SDK options can be configured with a filter.

The JavaScript/Browser tracker can also be partially configured using contants and custom simple JavaScript/Browser SDK options can be configured with a filter. The filter and constants can only do simple options but not callbacks like beforeSend since PHP is not executed in the Browser SDK, so if you want to configure options like that you can inject some JavaScript to take full control over the JavaScript SDK options and do whatever you need like setting a beforeSend callback.

Hope that helps!

Hmm, that does look correct to me seeing the example app Sentry provides.

It also looks like the code you added is good, I have for testing placed your snippet in my theme’s functions.php it needs to run before the header is rendered in the theme, if you search for wp-sentry-browser-js-extra in the HTML of your pages do you see your ignoreErrors and/or denyUrls listed?

Otherwise it might be that the strings must match exact error messages instead of partials, we should probably add the option to make sure we allow regex’s in the ignoreErrors option.

There is a (very lightly documented) ignoreErrors option in the JavaScript SDK, you can configure that like this:

add_filter( 'wp_sentry_public_options', function ( array $options ) {
	return array_merge( $options, array(
		'ignoreErrors' => array(
			'Non-Error promise rejection captured with value',
		),
	));
} );

I have to admit I did not had the time to test this, however it “should” work ??

Documentation links:
– https://github.com/stayallive/wp-sentry#wp_sentry_public_options-array
– https://docs.sentry.io/platforms/javascript/configuration/filtering/#decluttering-sentry

You do not mention what exceptions you want to block, but from your code snippet… are the events you are getting possibly JavaScript exceptions? The before send callback you are setting here only works on PHP exceptions.