stayallive

Ah maybe I misunderstood the feature, it should indeed not interfere with that. Maybe you have “Delay JavaScript execution” enabled or the future that combines (and defers) JavaScript files? I believe that might be the actual culprit if something breaks. I don’t have a WP Rocket site to test with so I can’t replicate the issue myself at the moment.

It is recommended to exclude Sentry from WP Rocket. You do not want to lazy load Sentry.

If you exclude Sentry from being lazy loaded I’m hoping that will also clear up any errors your are seeing.

Let me know if that helps!

Sure, you can just follow the PHP docs: https://docs.sentry.io/platforms/php/crons/

I meant that you could add a tag called “is_admin” with the value of whatever the is_admin() WordPress helper returns which you then can use to filter on inside the Sentry UI. You can apply tags for both the PHP and JS side of the integration.

I think your best bet might be filtering based on the URL, for example doing url:"*wp-* (you can paste this in the Sentry search).

This difficulty is that the line between back-end front-end is a bit blurred with the usage of AJAX requests and the WordPress JSON API.

In theory we can of course add a tag based on is_admin() but not sure if that is actually useful… it is something you can do yourself pretty easily if you want to see if that would solve your question.

There are some differences in what this plugin can provide and the Next.js integration can provide.

This plugin is able to track errors on the PHP side and able to inject the JavaScript SDK to track errors and do performance monitoring.

The second part (injecting the JS SDK) is not applicable to your headless setup but the PHP error tracking will work just fine.

So if you want to see errors occuring in your Next.js front-end you need to add the SDK in your Next.js app manually: https://docs.sentry.io/platforms/javascript/guides/nextjs/

Tracking PHP errors this plugin will do for you!

Does that answer your question?

First of all, I’m very impressed by your report! Thanks for taking the time to first of all research the troubleshooting steps and letting me know how they went, this saves massive amounts of time.

However, since you tried and done almost everything I would also have suggested that doesn’t leave much, but I’m sure we will figure it out!

The first thing that comes to mind, do you have an adblocker? Unfortunately they block most requests to Sentry and might be the cause, that would also explain the success message since when an adblocker blocks te request an event ID is still returned indicating the event was sent. If you do, try to disable it completely and test again.

If you don;t have an adblocker or disabling it has no effect, you can try opening your browsers devtools and see if there are any (network) errors visible when clicking the test buttons.

Sorry for the late reply, this one fell through the cracks. Did you end up figuring it out?

Some of these errors look very much like JavaScript errors… is it possible you also enabled the WP_SENTRY_BROWSER_DSN because the wp_sentry_options filter only works for the PHP side and not the browser side.

Could that be the cause?

The number of errors sent per request makes the impact. It is not expected to sent multiple errors per request to Sentry, most of the requests shouldn’t sent any so if the case is that Sentry becomes unavailable the timeouts (which have been re-adjusted couple of times in the past months) should prevent any major slowdowns but when Sentry is reporting multiple errors per request this can stack up quickly.

However if you want to be sure you can use Relay to solve that problem completely since Relay will accept events even if Sentry is not available and wait for Sentry to become available to sent events so as long as Relay is online your application can send it’s errors quickly.

It depends ??

If you only use the PHP error tracking the impact (unless you have errors to report) is negligible. When reporting errors to Sentry it does cause a slow down (sending the error) which could be mitigated by using Relay (https://docs.sentry.io/platforms/php/performance/#improve-response-time).

The JavaScript/Browser story is more complicated. You are (depending on the features you enabled like performance) loading a sizeable JavaScript bundle. The impact of this bundle varies and is best to test and validate what the impact is.

I know this is not a clear cut answer but hope it shines some light and helps you figure out what is applicable to you and helps you test how the impact in your situation is.

See: https://github.com/stayallive/wp-sentry/tree/v7.3.1#wp_sentry_error_types-php

Do you think you can take it from there?

For future readers, we’ve resolved the issue via e-mail, Damon and his team were very helpful in getting me the access needed to troubleshoot the problem.

The problem ended up being that the Sentry constants were placed after the require_once to the wp-settings.php in the wp-config.php, below the “That’s all, stop editing!” comment. This is incorrect and caused problems where the plugin was not correctly initialized. If you ever run into this issue, consult the documentation: https://github.com/stayallive/wp-sentry#configuration and make sure you place the configuration constants in the correct position.

That was quick with your own answer ??

But yes, setExtra is deprecated but technically still available but they might have chosen to not show that anymore in the UI.

I’ve updated the example to use setContext luckily the link to the Sentry docs was up-to-date ??

I do, my e-mail is on my GitHub, we will work something out.

Happy to do it for free if we can find a bug in the plugin or improvement for others!

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.