Remove the modules that were published as standalone plugins from the Performance Lab plugin

[felixarntz]

Feature Description

Follow up to #651 #652 #653: The final part of this workstream will be to actually remove the modules that are published as standalone plugins from the PL plugin. This will not actually involve deleting the folders in the repository, as they will still be developed here (i.e. as a monorepo), instead we will need to ensure they are excluded from the plugin, maybe move to a new plugins directory in this repo, and at that point we can also change their file headers to actual plugin headers instead of PL module headers.

Requirements

This work should be implemented against a new feature/modules-to-plugins feature branch.

After #934 has been completed:

• Move the folders for the modules referenced in plugins.json into the new plugins folder (without their focus area folders).
• Keep those modules/plugins unchanged, except for:
  • Update the respective load.php file to have the plugin header instead of the module header.
  • The plugin header should have the same content as if it had been built using our current "module to plugin" build workflow.
• Migrate the existing plugins.json entries from the modules property to the plugins property.
• Update the references to the migrated modules in CODEOWNERS to point to the respective plugin folders.
• Remove references to the migrated modules in the perflab_get_standalone_plugins_constants() function.

[paaljoachim]

Why remove features from the Performance Lab plugin? Can we have the various modules still included in the PL plugin so the user can choose to either use the PL modules on/off plugin or individual plugins?
(Makes me think of a Jetpack light with the opportunity to turn a feature on or off.)

I really would like to continue using the Performance Lab plugin that also includes the various modules so that I just need to install one plugin that includes a lot of really helpful features.

[joemcgill]

Thanks for the feedback @paaljoachim. Ultimately, the decision to publish these features as standalone plugins rather than as a bundled plugin came from the WordPress project leadership. Our goal is to make clear distinctions between the standalone plugins and the main performance lab plugin to not create confusion by having the same features available in two separate places. We're going to do our best to make the user experience for activating performance features as plugins as seamless as we can.

[paaljoachim]

Hey Joe.

This is how I understand it.
Creating separate plugins these will in a sense become the "standard" feature plugin. So that one can campaign the single feature plugins to be included into WordPress core.

This means a feature is first tested out in the Performance Lab plugin and after the testing the feature is pulled out of the PL plugin and added to the single feature plugin. If it fits in with core (hopefully it does) and it will at some time be added to core. It sounds logical to me.

[felixarntz]

@mukeshpanchal27 @joemcgill @swissspidy I was just thinking more about the sequencing of #934, #935, and this issue.

In order to unblock new standalone plugins (like Auto Sizes or Speculation Rules) sooner than later, we may want to merge the feature/modules-to-plugins branch into trunk sooner than later. The only critical consideration with that is that we must not remove the existing modules from Performance Lab yet (i.e. the already launched modules must not be moved to the plugins folder).

Here's an idea of what we could potentially do:

1. Complete and merge the first PR for Introduce plugins folder for standalone plugins #934 (Introduce plugins folder for standalone plugins #948) into feature/modules-to-plugins.
2. Update the Auto Sizes PR Add: Auto Sizes for Lazy-loaded Images #904 to go against feature/modules-to-plugins instead of trunk, move the module files to the plugins folder, then merge that PR.
   • This gives us an actual plugin in the right location to test the remaining work against.
3. Implement a PR against feature/modules-to-plugins to adjust the unit test infrastructure to support Performance Lab, plus the plugins from the plugins folder via independent test suites.
4. Implement a PR for Implement publishing workflow for standalone plugins that aren't modules #935 against feature/modules-to-plugins.

Once all the above is in place, we can merge feature/modules-to-plugins into trunk, regardless of timing. At this point any new standalone plugins are unblocked from using the new infrastructure. I think we should be able to get there by end of next week or early the week after, if we prioritize this work.

This issue here (actually removing the existing modules by moving them from modules to plugins) is then the only thing that must not be merged into trunk until after the 2.9.0 release is out in mid-February. We could already implement it in a PR, but would need to hold off merging until then. But that shouldn't be disruptive for development anyway, as we're rarely touching the two affected plugins (WebP Uploads and Dominant Color Images).

Does that sequencing plan sound reasonable to you?

[thelovekesh]

Putting up a PR to move modules to the plugins directory. Modules will be:

• images/dominant-color-images
• images/webp-uploads