Open XVII opened 3 days ago
The usual problem with any UI setting is that WordPress only has provisions to store it in the database which is available pretty late so the settings take some time to take effect reducing their usefulness.
I can agree it might be useful to be able to ignore some especially noisy plugins from time to time but not sure the UI is the way to go here. There is a reason no setting to date is configured using the UI.
Ah yeh, good point. I forget it needs to run ASAP.
Maybe the UI can be a visual representation of what's happening? Similar to the other checkboxes that are disabled, and point people to Documentation on how to "change" it.
I'm unsure of the best data structure assuming it needs to be implemented in PHP, but something along the lines of an object/array with plugin/theme "folder name" by "error type" would help me squash a lot of noise.
That is of course always an option (showing it in the UI) but that can also grow to a massive table.
As for how to configure, we might get away with simply doing:
define('SENTRY_PLUGIN_LOG_LEVEL', [
'some/plugin' => null, // drop everything
'other/plugin' => 'error', // only "error" level and above
]);
Unsure what "level" config makes sense here but something like this could work possibly.
wp_sentry_before_send
does a great job at filtering based on any custom situation, it may be more "friendly" to provide a UI to allow certain plugins to be included/excluded, then based on severity?This would kind of be like setting logging levels, used in other languages, on a per-namespace basis (in this case core/plugin/theme) to more easily tune what goes to Sentry. It would basically help automate the "Check the the frame happened inside a theme or plugin" part of the doco.
For example:
An additional filter that might be useful would be:
This obviously could be implemented in code, but a UI would help improve the "friendliness" of such configurations.