stayallive

Dang. Always IE! Sorry about that, it was totally overlooked by me.

It’s fixed in 2.7.1 which was just released to the plugins repo (give it a few minutes if it doesn’t show up immediately).

Awesome! Next time don’t place _any_ config after that line since none will work ??

Enjoy!

That looks just fine to me.

There is only 1 think I can think of right now to be honest.

Where did you put that config in the wp-config.php?

There is a /* That's all, stop editing! Happy blogging. */ line, the config should be _above_ that line, below will not work.

If you did that correct I am afraid I am unsure where to look… maybe you could try and debug it placing some echo statements in the plugin source to see if the code get’s executed at all and where it stops.

Okay it’s getting really hard for me to find things that could be wrong.

The last thing I can think of is that the plugin is simply not enabled in the plugins section?

I did a clean 4.9.2 install today and added the plugin and only added define( 'WP_SENTRY_PUBLIC_DSN', 'https://xx@xx/xx' ); to the wp-config.php. And Raven.isSetup(); returns true for me on the frontpage.

Also did you make sure to have installed the latest version of the plugin?

Hey @webtechnology,

I was ask if you could try it _with_ the Twenty Seventeen theme.

This rules out the problem is in your theme. Maybe a WordPress call is missing that should output enqueued scripts.

Can you verify the raven.js is also not added when using the Twenty Seventeen theme, your theme might not properly display enqueued scripts or you removed jQuery from your theme (it looks like we added ‘jQuery’ as an dependency for raven) it might also not load because the dependency could not be met, this will very likley be changed in a future release.

Just a little disclaimer: changing a theme can have unwanted consequences so please try it out on a test environment or backup your site first.

Since you are searching for raven I am assuming you are talking about the front-end implementation.

Only if define( 'WP_SENTRY_PUBLIC_DSN', 'PUBLIC_DSN' ); (where PUBLIC_DSN is replaced by the actual DSN) should raven be found in the html source.

Only setting WP_SENTRY_DSN will not log errors on the front-end.

Hey Paul,

WP_DEBUG should definitly not be on to see notices in Sentry, that is why the performance hit also occures with WP_DEBUG off, it’s still submitting notices.

Unfortunalty there is not much we can do about this, notices can be disabled ofcourse so you won’t be bothered by them by they are “errors” and are submitted to Sentry and that takes time and overhead for the HTTP request, there is not much to do about that I am afraid. Lot’s of errors -> lot’s of overhead.

Usually the performance penalty is a non-issue because if there is an error (or notice causing incorrect behavior) I would say you want to know about it instead of having the best performance on a broken site ??

If you are using the Sentry.io service pleaase do contact support to find out why there are connection issues from your server.

Hey Paul,

This can have all sorts of reasons but trying to submit notices to Sentry is the leading suspect although it’s weird nothing is coming through…

It’s very hard to debug from my seat, but did you make sure the DSN is set-up correctly and not missing a character?

Hey Paul,

You are looking at the official PHP documentation, that does not fully apply to the WordPress version, you need something like this:

if ( class_exists( 'WP_Sentry_Php_Tracker' ) ) {
    $sentryClient = WP_Sentry_Php_Tracker::get_instance()->get_client();

    $sentryClient->captureException( $e );
}

Please do remember that the captureException method only accepts a Exception object.

Something like the version bellow applies if you want to send a message to Sentry:

if ( class_exists( 'WP_Sentry_Php_Tracker' ) ) {
    $sentryClient = WP_Sentry_Php_Tracker::get_instance()->get_client();

    $sentryClient->captureMessage( 'Some Error!' );
}

The $sentryClient in the examples above has the same methods as described in the docs you linked above so that should help you out with figuring out which capture method to use.

Then you have a great caching setup if it is not something you would consider (if it was in your way every time it would be the first thing in your mind) ??

Let me know if it still doesn’t work after the caches expire.

Marking resolved because I recieved no reply, if you are still having issues open another ticket which describes your problem.

Hey @partounian,

If you are using caching some users might still get a page served with the Sentry SDK still loaded.

If that is not the case check if the JS SDK is still loaded on you site (in the <head> section), it it’s still there check that WP_SENTRY_PUBLIC_DSN is either not defined or is defined as an empty string (”), null or false, since that disables the JS SDK.

Since I have not heard back from you I am marking this as resolved.

If you still have issues please open another request.

Hey @pdalberg, sorry for the late reply (I don’t seem to get notified for messages here).

Are you still having issues after updating to the latest version of the plugin?