Skip to content
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

Merged
merged 14 commits into from
Mar 21, 2024

Conversation

mukeshpanchal27
Copy link
Member

@mukeshpanchal27 mukeshpanchal27 commented Mar 18, 2024

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.

@mukeshpanchal27 mukeshpanchal27 added [Type] Enhancement A suggestion for improvement of an existing feature Infrastructure Issues for the overall performance plugin infrastructure no milestone PRs that do not have a defined milestone for release Creating standalone plugins labels Mar 18, 2024
@mukeshpanchal27 mukeshpanchal27 self-assigned this Mar 18, 2024
@mukeshpanchal27
Copy link
Member Author

For the CODEOWNERS files:

  • Should we remove Focus areas?
  • Do we need to add a new section called Site Health, and include WebP Support Health Check, Autoloaded Options Health Check, and Enqueued Assets Health Check with their respective owners? What do you think?

@mukeshpanchal27 mukeshpanchal27 marked this pull request as ready for review March 18, 2024 10:36
Copy link

github-actions bot commented Mar 18, 2024

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: mukeshpanchal27 <[email protected]>
Co-authored-by: felixarntz <[email protected]>
Co-authored-by: thelovekesh <[email protected]>
Co-authored-by: westonruter <[email protected]>
Co-authored-by: joemcgill <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

.github/workflows/deploy-standalone-plugins.yml Outdated Show resolved Hide resolved
plugins.json Show resolved Hide resolved
readme.txt Outdated Show resolved Hide resolved
admin/load.php Outdated Show resolved Hide resolved
Copy link
Member

@felixarntz felixarntz left a 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.

admin/load.php Outdated Show resolved Hide resolved
admin/load.php Outdated Show resolved Hide resolved
admin/load.php Outdated Show resolved Hide resolved
plugins.json Show resolved Hide resolved
readme.txt Outdated Show resolved Hide resolved
readme.txt Outdated Show resolved Hide resolved
readme.txt Outdated Show resolved Hide resolved
load.php Outdated Show resolved Hide resolved
load.php Outdated Show resolved Hide resolved
@thelovekesh
Copy link
Member

@mukeshpanchal27 #1033 caused merge conflicts 😐

.github/workflows/deploy-standalone-plugins.yml Outdated Show resolved Hide resolved
admin/load.php Outdated Show resolved Hide resolved
readme.txt Outdated Show resolved Hide resolved
@mukeshpanchal27
Copy link
Member Author

@felixarntz, should we update the setting page slug from the existing /wp-admin/options-general.php?page=perflab-modules to /wp-admin/options-general.php?page=perflab-features?

@thelovekesh
Copy link
Member

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.

@felixarntz
Copy link
Member

felixarntz commented Mar 20, 2024

@mukeshpanchal27

@felixarntz, should we update the setting page slug from the existing /wp-admin/options-general.php?page=perflab-modules to /wp-admin/options-general.php?page=perflab-features?

Great catch! I think this is a good idea, though I would suggest we go with the more generally applicable /wp-admin/options-general.php?page=performance-lab. Let's also rename the constant, e.g. to PERFLAB_SCREEN or PERFLAB_FEATURES_SCREEN.

It would be great to add another hook though which catches requests to /wp-admin/options-general.php?page=perflab-modules and redirects those to the new location, e.g. on the admin_page_access_denied action hook. For reference, consider this example in the Google Site Kit plugin.

@thelovekesh

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 point as well! It would be great to implement an update routine which deletes the 'perflab_modules_settings' option if it is present. Since the option would be autoloaded anyway, I think we could maybe do that simply on admin_init if the current user has manage_options capabilities. This check should be cheap enough to run in that action hook, and it has the benefit that it works reliably at scale, even on large multisites.

Comment on lines -79 to -80
- name: Building standalone plugins
run: npm run build-plugins
Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member

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.

bin/plugin/commands/test-plugins.js Show resolved Hide resolved
uninstall.php Show resolved Hide resolved
@mukeshpanchal27
Copy link
Member Author

@westonruter, I'll update the test-plugins command in a follow-up PR.

@felixarntz @thelovekesh, the feedback has been addressed. The PR is now ready for another round of review.

Copy link
Member

@thelovekesh thelovekesh left a 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 ;)

load.php Outdated Show resolved Hide resolved
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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) :)

Copy link
Member

@felixarntz felixarntz left a 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.

cc @westonruter @thelovekesh

@westonruter
Copy link
Member

westonruter commented Mar 21, 2024

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 test-plugins script as it currently stands.

This can be done in a separate PR, AFAIK.

Copy link
Member

@westonruter westonruter left a 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.

load.php Outdated Show resolved Hide resolved
Copy link
Member

@felixarntz felixarntz left a 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.

@felixarntz felixarntz changed the title Remove modules infrastructure Remove modules infrastructure and UI from the plugin Mar 21, 2024
@felixarntz felixarntz added this to the performance-lab 3.0.0 milestone Mar 21, 2024
@felixarntz felixarntz removed the no milestone PRs that do not have a defined milestone for release label Mar 21, 2024
@felixarntz felixarntz merged commit fb3553c into trunk Mar 21, 2024
43 checks passed
@felixarntz felixarntz deleted the fix/1030-remove-modules-infrastructure branch March 21, 2024 16:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Infrastructure Issues for the overall performance plugin infrastructure [Type] Enhancement A suggestion for improvement of an existing feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove modules infrastructure
4 participants