Repository navigation
Remove the modules that were published as standalone plugins from the Performance Lab plugin #654
Description
Activity
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.
Reacted by Sam L.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.
Reacted by Felix ArntzHey 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.
@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-pluginsbranch intotrunksooner 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 thepluginsfolder).Here's an idea of what we could potentially do:
- Complete and merge the first PR for Introduce
pluginsfolder for standalone plugins #934 (Introduce plugins folder for standalone plugins #948) intofeature/modules-to-plugins. - Update the Auto Sizes PR Add: Auto Sizes for Lazy-loaded Images #904 to go against
feature/modules-to-pluginsinstead oftrunk, move the module files to thepluginsfolder, then merge that PR.- This gives us an actual plugin in the right location to test the remaining work against.
- Implement a PR against
feature/modules-to-pluginsto adjust the unit test infrastructure to support Performance Lab, plus the plugins from thepluginsfolder via independent test suites. - 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-pluginsintotrunk, 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
modulestoplugins) is then the only thing that must not be merged intotrunkuntil 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?
Reacted by Pascal Birchler, Mukesh Panchal and thelovekesh- Complete and merge the first PR for Introduce
Putting up a PR to move modules to the
pluginsdirectory. Modules will be:images/dominant-color-imagesimages/webp-uploads
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
pluginsdirectory 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-pluginsfeature branch.After #934 has been completed:
plugins.jsoninto the newpluginsfolder (without their focus area folders).load.phpfile to have the plugin header instead of the module header.plugins.jsonentries from themodulesproperty to thepluginsproperty.CODEOWNERSto point to the respective plugin folders.perflab_get_standalone_plugins_constants()function.