-
Notifications
You must be signed in to change notification settings - Fork 15
Updated bugsnag-php dependency to v3
#71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
| </th> | ||
| <td> | ||
| <textarea id="bugsnag_filterfields" name="bugsnag_filterfields" class="regular-text filterfields" style="height: 150px;"><?php echo $this->filterFields; ?></textarea> | ||
| <textarea id="bugsnag_redacted_keys" name="bugsnag_redacted_keys" class="regular-text redacted_keys" style="height: 150px;"><?php echo $this->redactedKeys; ?></textarea> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be worth trying to keep filterfields in some way so that upgrading users won't lose their existing values?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we keep the old name under the hood to preserve the filters?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how the form data is persisted, but I was wondering if we keep the filterfields name here but make it set redacted keys, would that meant that developers don't lose their settings after the upgrade?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or perhaps you always lose settings when you upgrade?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The settings persisted when I reinstalled the plugin, so I assume as long as we keep the same name in the settings view, the value would stay
| try { | ||
| require_once $this->relativePath(self::$COMPOSER_AUTOLOADER); | ||
| return true; | ||
| } catch (Exception $e) { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the purpose of this change and can you be sure that it's not reducing compatibility? It seems to be assuming use of Composer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I understand, this does not reduce compatibility, because we don't actually use composer here. We just use the autoload it generates to load all of the dependencies. All of the code the autoloader depends on is shipped alongside the plugin.
In v2 of bugsnag-php there were no dependencies, so we were only copying bugsnag-php from the vendor folder to bundle it with the plugin. Now, that we've updated to v3 we have to ship all of the dependencies anyway, for example Guzzle, so we can rely on the Composer generated autoloader and simplify the logic.
Goal
Updated the
bugsnag-phpdependency to v3.Changeset
bugsnag-phpto v3Testing
All changes tested manually