-
Notifications
You must be signed in to change notification settings - Fork 101
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
Remove modules infrastructure and UI from the plugin #1060
Conversation
For the CODEOWNERS files:
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
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.
@mukeshpanchal27 This looks great so far. I left a few comments.
@mukeshpanchal27 #1033 caused merge conflicts 😐 |
@felixarntz, should we update the setting page slug from the existing |
Overall changes look good to me. I just want to verify whether an updater script is required to remove any options or configurations added to the database by the previous PL plugin that will not be utilized in the next version. |
Great catch! I think this is a good idea, though I would suggest we go with the more generally applicable It would be great to add another hook though which catches requests to
Great point as well! It would be great to implement an update routine which deletes the |
- name: Building standalone plugins | ||
run: npm run build-plugins |
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.
Why are the plugins no longer needing to be built? In bin/plugin/commands/test-plugins.js
it is not accounting for assets which may have been generated by Webpack as it is just copying the source files from /plugins
to /build
. It seems rather that test-plugins.js
should be updated to reuse the output from npm run build-plugins
which is already outputting the plugins into /build
. cc @thelovekesh
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.
Thank you for pointing that out. It's on my list to address as a follow-up PR since it scratches the current one.
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.
Based on what @thelovekesh wrote in #1060 (comment), do we even need this anymore? The purpose of the test-plugins
script and this GitHub workflow was purely to test whether standalone plugins don't cause some weird fatal error when built from their modules.
Since we don't build modules into plugins anymore, I think this isn't useful any more. For that reason, I would suggest to remove the whole test-plugins
script and everything around it. Since this is only removing more things, it would be great if you could do it as part of this PR.
I think some of the code changes in this PR are a bit confusing because they're changing those scripts when they don't really have a good purpose anymore as a whole.
@westonruter, I'll update the @felixarntz @thelovekesh, the feedback has been addressed. The PR is now ready for another round of review. |
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.
LGTM! Just a minor feedback ;)
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.
Do we still need this given we aren't converting modules to plugins anymore? I am not sure if we really need this.
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.
That command simply checks if the plugin activates and doesn't return any errors, so I don't believe we need to remove it. I'd appreciate getting other opinions on this matter.
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.
Just replied in #1060 (comment) :)
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.
@mukeshpanchal27 Unless I'm missing something, I think we should remove the test-plugins
script and everything using it, including the workflow, as this was intended to test plugins that were built from modules, which is no longer relevant. See https://github.com/WordPress/performance/pull/1060/files#r1534169130.
I think there is a better way to check for fatals and that would be through E2E tests in #1051. I think it makes sense to remove the existing This can be done in a separate PR, AFAIK. |
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.
Just a nit, but this looks like it can be merged and then further iterated on in subsequent PRs.
Co-authored-by: Weston Ruter <[email protected]>
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 agree with @westonruter's assessment, let's merge this to unblock other PRs. We can remove the test-plugins
command in a subsequent PR.
Summary
Fixes #1030
Things needs to updates:
Note: In
.github/workflows/deploy-standalone-plugins.yml
, I've included some 'TODO' items that need to be addressed and removed before the merge.