stayallive / wp-sentry

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

Feature Request -- Auto Update of Release Version #168

Closed andrewhenke closed 8 months ago

andrewhenke commented 12 months ago

Hello!

I use Sentry across a large number of WordPress websites with my clients, and I've found that when Dev. teams for my client websites update the code of the custom WordPress themes, they are commonly not changing the release wp-config constant that you set for the PHP Sentry configuration. Would it be possible to add functionality to the plugin to allow the release to be set by the version of the active theme, using the wp_get_theme() function? It would make it significantly more effective for me, since we would then be able to easily track new errors across custom theme releases.

Thank you!

stayallive commented 12 months ago

You mean something like what was done in #161?

I think this behavior is already present in the latest release 🤘

Let me know if I misunderstood or that is not what you were looking for!

andrewhenke commented 11 months ago

Possibly @stayallive? From what I read in the linked issue and discussion, it would seem so, however it does seem that an update of the documentation would be highly useful, as this feature doesn't seem to be documented in an easily understandable/discoverable manner.

If the ability is also already present, would it be possible in the Wordpress admin dashboard where the Sentry plugin can be viewed, to display the auto-detected release version instead of the "not set" message that is currently displayed? Perhaps with an indicator of some form that shows that the release is being auto-populated from the theme version?

What do you think?

stayallive commented 11 months ago

Have you tried it out? I just did and:

image

image

I could for sure improve the messaging a bit that it was auto-discovered and or add that it does that to the admin page of course, that could be an improvement.

It is documented however: https://github.com/stayallive/wp-sentry#wp_sentry_version

andrewhenke commented 11 months ago

Thank you for the clarification -- I removed the WP_SENTRY_VERSION configuration constant in the wp-config.php file and it isn't showing the above example you provided -- here is a screenshot from one of my client websites.

image

Is the feature provided by the plugin version that is released on the Wordpress plugin marketplace, or is there a plugin version from this repository that is more recent? I have plugin version 6.24.0 installed on the website, and it's not showing any value set for me.

Additionally, I'll note that this website has a custom theme, and a custom child theme running on it, for the website contents, however, this theme does follow WordPress development standards and does contain the proper versioning and metadata.

stayallive commented 11 months ago

Yes. That is the most recent version. The releases are automatically synced to the marketplace. The release you have contains the automatic release version.

Do you a non-standard installation? For example by requiring this plugin from the wp-config.php or as a mu-plugin? Because it looks like wp_get_theme is not available when the plugin is being loaded.

andrewhenke commented 11 months ago

I do have the plugin loaded using the mu-plugin config file that was provided as an example in the documentation -- this is because we need to capture the logs from the plugins we have installed, for correlation to how the plugins are interacting with the custom theme.

Does this disable the ability to load the theme version?

stayallive commented 11 months ago

It looks like wp_get_theme is indeed not available there, WordPress load this function later. This feature has been absent a few version and I think this is the reason. It's just not reliable unfortunately since you want to load Sentry as early as possible but reading the theme version requires a lot of setup for WordPress to do.

So even we "fixed" the problem by waiting to set the version after wp_get_theme becomes available, it would not mark every error with the theme version, only the errors occurring after wp_get_theme becomes available. So the question is what makes more sense, no version being set or a part of the errors captured not having a version set. Both are not very good options I think.

andrewhenke commented 11 months ago

Thank you for your time in investigating and working with me on this!

It presents an interesting and unique challenge, for obtaining the version data of the theme while still loading as a mu-plugin.

Is it possible to have the must use plugin drop in obtain and set the version variable from the theme, if it's so desired? I'm not as familiar with this specific operation and the limitations of the must-use drop-ins.

stayallive commented 11 months ago

So as it turns out I tested this incorrectly... mu-plugins do have access to wp_get_theme and setting the release version automatically works as expected with or without the mu-plugin. So there must be something else at play here why it isn't working for you!

andrewhenke commented 11 months ago

Hmm -- if I was to provide you with access to a WordPress instance that is having this issue, would you be able to take a look, perhaps? I've just been using a 'normal' deployment for this system. Thank you for your assistance! :)

stayallive commented 11 months ago

I would love to take a look if that is possible for you, please do reach out to me via e-mail to prevent sharing any pertinent details publicly :)

andrewhenke commented 11 months ago

For sure! I will reach out via the email on your GitHub profile. Thanks!

stayallive commented 8 months ago

We've handled this through e-mail and also possibly #171 fixes the problem. If anyone encounters issues with the version not properly detected feel free to open another issue!

andrewhenke commented 8 months ago

@stayallive could you check my most recent response? I don't think it's fully resolved still