stayallive / wp-sentry

A (unofficial) WordPress plugin reporting PHP and JavaScript errors to Sentry.
https://wordpress.org/plugins/wp-sentry-integration/
MIT License
320 stars 48 forks source link

[FEATURE] add predefined filters for notices, warnings etc. #177

Closed LordSimal closed 9 months ago

LordSimal commented 9 months ago

It would be pretty nice if this plugin has some commonly usable filters to ignore events on specific levels (notices, warnings etc.) without the need to add those filters oneself via a theme or another plugin.

E.g. this ignores all warnings so they are not sent to sentry.

add_filter( 'wp_sentry_options', function ( \Sentry\Options $options ) {
    $options->setBeforeSendCallback( function ( \Sentry\Event $event ) {
        $exceptions = $event->getExceptions();

        if( isset( $exceptions[0] ) &&
            method_exists( $exceptions[0], 'getValue' ) &&
            str_starts_with($exceptions[0]->getValue(), 'Warning')) {
            return null;
        }

        return $event;
    } );

    return $options;
} );

We needed this for certain very old websites which caused thousands of warning events being sent to sentry per second due to it being upgraded to PHP 8.2

By commonly usable filters I mean something on the sentry settings page in the wordpress backend which we can easily be enabled and disabled.

Since all our websites are automatically deployed (and we don't want to edit files directly on the server since this can cause major problems with the state of the repository) this feature would be pretty awesome.

LordSimal commented 9 months ago

I guess thats what the WP_SENTRY_ERROR_TYPES constant is for... still I'd prefer a backend setting to be honest 😁

stayallive commented 9 months ago

WP_SENTRY_ERROR_TYPES is exactly what this is for 😉 Should work great!

I know a UI setting is preferred by some but by the time we can get the option from the database errors could have already been reported so that is why we are using constants in the wp-config.php because otherwise the setting is applied when it's already too late.

LordSimal commented 9 months ago

Thanks for the quick answer, I can see now why this design was chosen 👍🏻

stayallive commented 9 months ago

You are certainly not the first, nor the last. But until I find a compelling reason / use-case we are for now sticking with the wp-config.php config options. Little harder but hopefully you shouldn't have to touch it too often.

Thanks for taking the time to open an issue though. Appreciate the feedback!

LordSimal commented 9 months ago

Well to give you a bit more context: Other frameworks like Drupal and its sentry integrations allow this kind of "deeper configuration" from a UI perspective.

This of course heavily depends on the framework because the bootstrapping process of Drupal is totally different from what wordpress is doing, so I totally get it.

But from a pure user perspective this would of course heavily increase the UX of this awesome plugin 😁

stayallive commented 9 months ago

Yeah agreed. We might offer something in the future but WordPress has no standard way to write a static config only database options. This might be different in other environments.

WordPress plugins do things like write files to the filesystem or try to modify the wp-config.php with code which for a developer tool like this feels a little to brittle (and also for me to maintain that since I don't feel confident I can guard against all the edge cases).

So if someone comes up with a simple and good plan I'm happy to oblige. Until that time I feel like the trouble is not worth the benefit to mostly developers interacting with this plugin.

So long story short, I'm not against it. I'm just not seeing a good way to implement it at this time. I'm sure we'll figure it out at some point though!