-
Notifications
You must be signed in to change notification settings - Fork 800
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
Added dynamic plugins_loaded hook priority. #14720
Conversation
Before we were using priority 1 always, but some plugins want to use the hook even earlier than that, so we are watching the filters being added on each plugin load and reassigning our own configure call to an earlier priority.
Thank you for the great PR description! When this PR is ready for review, please apply the Scheduled Jetpack release: March 3, 2020. |
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.
This looks good to me! I manually tested this change as described in the testing instructions and verified that the PR fixes the error.
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's pretty clever. Works as advertised, but definitely want more eyes on it since it is a rather big change that has a point release potential.
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've tested the branch on my WooCommerce test site with one of the problematic plugins activated and have confirmed that this fixes it. Switching back to stable breaks the API again.
Added to |
* Added dynamic plugins_loaded hook priority. Before we were using priority 1 always, but some plugins want to use the hook even earlier than that, so we are watching the filters being added on each plugin load and reassigning our own configure call to an earlier priority.
Does this mean that the autoloader check for |
@peterfabian no, this check applies to other consumers as well that may be using the Autoloader incorrectly. Otherwise we may end up in a situation where a consumer unknowingly forces usage of a library before every plugin has had a chance to load their dependencies. |
Before we were using priority 1 always, but some plugins want to use the hook even earlier than that, so we are watching the filters being added on each plugin load and reassigning our own configure call to an earlier priority.
Fixes a bug with authenticated REST API calls with plugins like Give or WPMU enabled.
Changes proposed in this Pull Request:
plugins_loaded
hook priority determining mechanism.Is this a new feature or does it add/remove features to an existing part of Jetpack?
Testing instructions:
Proposed changelog entry for your changes: