Remove modules infrastructure and UI from the plugin

[mukeshpanchal27]

Summary

Fixes #1030

Things needs to updates:

• Document: https://make.wordpress.org/performance/handbook/performance-lab/releasing-the-plugin/

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]

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?

[github-actions]

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 <mukesh27@git.wordpress.org>
Co-authored-by: felixarntz <flixos90@git.wordpress.org>
Co-authored-by: thelovekesh <thelovekesh@git.wordpress.org>
Co-authored-by: westonruter <westonruter@git.wordpress.org>
Co-authored-by: joemcgill <joemcgill@git.wordpress.org>

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

[felixarntz]

@mukeshpanchal27 This looks great so far. I left a few comments.

[thelovekesh]

@mukeshpanchal27 #1033 caused merge conflicts 😐

[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?

[thelovekesh]

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]

@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.

[westonruter]

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

[mukeshpanchal27]

Thank you for pointing that out. It's on my list to address as a follow-up PR since it scratches the current one.

[felixarntz]

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.

[mukeshpanchal27]

@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.

[thelovekesh]

LGTM! Just a minor feedback ;)

[thelovekesh]

Do we still need this given we aren't converting modules to plugins anymore? I am not sure if we really need this.

[mukeshpanchal27]

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.

[felixarntz]

Just replied in #1060 (comment) :)

[felixarntz]

@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]

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.

[westonruter]

Just a nit, but this looks like it can be merged and then further iterated on in subsequent PRs.

[felixarntz]

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.