Forum Replies Created

Viewing 15 replies - 1 through 15 (of 47 total)
  • Plugin Author Alex

    (@stayallive)

    Hi morvy,

    Unfortunately the WordPress plugin is not yet taking advantage of the PHP SDK 3.0 so performance monitoring is not yet available.

    You can follow the progress here: https://github.com/stayallive/wp-sentry/issues/68.

    Do keep in mind that if the PHP SDK 3.0 is available performance monitoring will likely require some extra work to get going and will not capture very much data by default and will take significant effort to get usable data out for WordPress.

    Plugin Author Alex

    (@stayallive)

    Ah sorry I misunderstood, in that case you can use this filter to achieve that:

    add_filter( 'wp_sentry_public_context', function ( array $context ): array {
        unset( $context['tags']['wordpress'] );
    
        return $context;
    } );
    • This reply was modified 6 days, 17 hours ago by Alex. Reason: Fix formatting
    Plugin Author Alex

    (@stayallive)

    Hi there,

    I think you want to disable to browser side error tracking of this plugin but want to keep the server side error tracking?

    This is done by removing the following 2 constants from your wp-config.php file: WP_SENTRY_PUBLIC_DSN and/or WP_SENTRY_BROWSER_DSN (don’t worry if you have only 1).

    If that’s not what you want you will have to explain a bit more what you want to achieve!?

    Plugin Author Alex

    (@stayallive)

    That looks all just fine, I am wondering if this is a bug in Dynatrace somehow.

    This is where it starts: build/vendor/php-http/discovery/src/ClassDiscovery.php:48

    But it’s a try/catch that catches a \WPSentry\ScopedVendor\Http\Discovery\Exception\StrategyUnavailableException which is the exact error you are telling me that is being reported.

    So either Dynatrace is reporting caught errors somehow (technically they can since they seem to use a php extension) or they are incorrectly marking the thrown exception as uncaught for some reason.

    I don’t use and/or know Dynatrace so I am not sure how to debug this further for you but following your stack trace it all looks normal and I would expect that PuliUnavailableException being thrown (and caught), you can also check other logs to see if a 500 error (which a uncaught error would produce) coincides with Dynatrace reporting this exception.

    Plugin Author Alex

    (@stayallive)

    Hmm, that is not supposed to happen… I am extremely confused since this exception should never be able to escape (it’s being caught)…

    Where do you get that exception, logs or inside Sentry?

    Do you have a stacktrace to go with that error too?

    Plugin Author Alex

    (@stayallive)

    > WP Sentry: This is a simple plugin to allow for access-restricted posting, allowing bloggers to discuss sensitive subjects without Google or the world finding the post.

    > WordPress Sentry: This plugin can report PHP errors (optionally) and JavaScript errors (optionally) to Sentry and integrates with its release tracking.

    That is the difference, unfortunately the names are very similar but we are in fact really different plugins doing really different things ๐Ÿ™‚

    Fromt he error message I can see this path: ... predefined construct in /wp-sentry/sentry-widgets.php.

    Our plugin folder is called wp-sentry-integration and the other plugin has a folder called wp-sentry and that is how I know this error is not from this plugin and you might not even have this plugin installed.

    So again sorry for the confusion and the similar naming.

    Plugin Author Alex

    (@stayallive)

    Hi there, please report this on the correct plugin: https://wordpress.org/plugins/wp-sentry/.

    This plugins is the wp-sentry-integration, sorry about the confusion!

    Plugin Author Alex

    (@stayallive)

    Yeah as far as I know trigger_error also ends up in the error_log so that should be what you want indeed ๐Ÿ‘

    Plugin Author Alex

    (@stayallive)

    Hi @mezzomedia,

    Sorry for the late reply, I forgot to reply to you ๐Ÿ™

    Unfortunately as far as I know this is a limitation of PHP.

    error_log is described as: Sends an error message to the web server’s error log or to a file. (https://www.php.net/manual/en/function.error-log.php)

    trigger_error is described as: Used to trigger a user error condition, it can be used in conjunction with the built-in error handler, or with a user defined function that has been set as the new error handler (set_error_handler()). (https://www.php.net/manual/en/function.trigger-error.php)

    Sentry is able to detect trigger_error because it hooks into the error handler.

    But as far as I know there is no API to hook into messages sent to the error_log function and that is why it will not be picked up by Sentry.

    If I’m mistaken and there is a way I’m happy to learn about it but as far as I can tell there is no way for PHP code to detect error_log calls and handle them.

    Plugin Author Alex

    (@stayallive)

    I might want to look into doing this although I do think an UI to enter the DSN and loading it from the database is a bit extreme for how simple the integration should (and could) be.

    I am tracking this here: https://github.com/stayallive/wp-sentry/issues/64

    I will look into this if I have some time for it, however I can’t make any promises it will be anytime soon.

    Thanks for bringing this up though!

    Plugin Author Alex

    (@stayallive)

    No problem @uvo, glad to hear itโ€™s working for you ๐Ÿ‘Œ

    Plugin Author Alex

    (@stayallive)

    Short answer: No, not right know.

    Long answer: I didnโ€™t even know you could install any random plugin to WordPress.com but after closer examination it looks like the business plan offers just that.

    I donโ€™t have an business plan so Iโ€™m not sure if there are (if any) other limitations.

    What is your use case, tracking browser based errors or possible PHP errors too?

    • This reply was modified 4 months, 3 weeks ago by Alex. Reason: Clarify the no
    Plugin Author Alex

    (@stayallive)

    I suspected something like that. Looks like anything less than PHP 7.3 (on php-fpm) could produce that error.

    Thanks again for bringing it to my attention so it could be fixed ๐Ÿ’ช

    Plugin Author Alex

    (@stayallive)

    After some more testing I think I have fixed the issue and pushed version 3.4.5.

    Please let me know if that update solves the error for you and successfully sends a test event to Sentry.

    Plugin Author Alex

    (@stayallive)

    Hi @pgiraudie,

    Thanks for bringing this to my attention.

    I think I’ve found out what’s wrong, but just to confirm, on what PHP version are you running your WordPress installation?

Viewing 15 replies - 1 through 15 (of 47 total)