Set up additional standalone plugins for Dominant Color and Fetchpriority

[felixarntz]

Feature Description

As a last step of creating standalone plugins for (some of) the modules in the Performance Lab plugin, we should finalize the config list from #635 to include all modules that should be published as standalone plugins. As part of this, we will need to set up their directories in the WordPress.org plugin repository, then build and deploy them using the tooling that we built in the issues #635, #636, #638, and #639.

This should likely be the last step of that work, to complete at least the first milestone of unbundling the Performance Lab plugin. Which modules to publish as standalone, and how to proceed after that is pending additional discussion in #618.

Requirements

Before working on this issue, let's wait until #638 is completed, and until a first version of the WebP Uploads plugin was successfully released.

• readme.txt files should be added to the module directories images/dominant-color and images/fetchpriority for their upcoming standalone plugins, following the conventions from Add module-specific readme files and enhance CLI command to include standalone plugin readme files #636.
• The plugins.json config file from Implement CLI command to for a build process to transform modules into standalone plugins #635 should be expanded to include the following modules and their standalone plugin information:
  • images/dominant-color: plugin slug dominant-color-images (a plugin with slug dominant-color already exists), plugin version: 1.0.0
  • images/fetchpriority: plugin slug fetchpriority, plugin version: 1.0.0

[felixarntz]

Based on #618 (comment), I'd like to share here the list of current modules we would publish, depending on each alternate policy:

1. Decide for every module individually whether to publish it as standalone plugin
   • maybe images/dominant-color
   • maybe images/fetchpriority
   • maybe images/webp-support
   • images/webp-uploads
   • maybe database/audit-autoloaded-options
   • maybe js-and-css/audit-enqueued-assets
   • database/sqlite
2. Publish every module as standalone plugin
   • images/dominant-color
   • images/fetchpriority
   • images/webp-support
   • images/webp-uploads
   • database/audit-autoloaded-options
   • js-and-css/audit-enqueued-assets
   • database/sqlite
3. Publish every module as standalone plugin that is a feature with the intent to directly affect the performance of WordPress (e.g. Site Health modules are excluded)
   • images/dominant-color
   • images/fetchpriority
   • images/webp-uploads
   • database/sqlite

This shows the benefits of options 2. and 3. over option 1.: No "maybe", we always know which modules to publish as standalone plugins. Option 3. shows a benefit of reduced overhead, as it would avoid the need for maintaining individual plugins for Site Health plugins, so compared to option 2. that's only 4 standalone plugins instead of 7. Since keeping Site Health modules as the primary focus of the PL plugin is also a good separation of concerns, option 3. seems like the most promising option.

cc @joemcgill

[joemcgill]

Thanks @felixarntz. I like how this illustrates the benefits of a clear policy on 2 and 3, and consolidates the decision to publish a module with the initial decision of whether to include a feature as a module in the first place.

Even with my suggested change to wording of option 3, the third list would remain the same as you have here and would still be my preferred option, as it keeps the purpose of the performance lab plugin (i.e., measuring and providing performance feedback about sites) distinct from the purpose of standalone modules that affect some performance aspect of WordPress itself.

[felixarntz]

My comment above in #640 (comment) outlines the 3 alternative options for our policy on which modules to publish as standalone plugins, including a list for each option which of the current modules this would lead to being published as standalone.

Per the discussions that have happened on GitHub and Slack, @ThierryA, @joemcgill, and myself are in agreement that we should go with option 3 (Publish every module as standalone plugin that is a feature with the intent to directly affect the performance of WordPress).

@JustinyAhin @OllieJones @adamsilverstein @getsource @aristath @sgomes @tillkruss @spacedmonkey As focus leads, can you please take a brief look at the above by end of this week? Please either give a thumbs up or otherwise share your feedback why you think we should go with another option. Thank you!

[felixarntz]

A PR for this can be opened against the trunk branch as soon as #699 is merged. However, it must not be merged into trunk until these two plugins have their wp.org repositories approved.

Here's a summary of what the PR needs to include:

• Add entries for the two plugins dominant-color-images and fetchpriority to plugins.json.
• Add the necessary version constants to these modules (see WebP Uploads module).
• Add the necessary generator function to these modules (see WebP Uploads module).

There may be something else, but those 3 things are what I can think of now.

[felixarntz]

Providing a brief update here:

• Configure Dominant Color and Fetchpriority modules for their standalone plugins #704 addresses the two points in the issue description, i.e. the overall issue.
• Separately, we will track creation of the repositories via Set up WordPress.org repositories for standalone plugins #637.
• The code for the standalone plugins can be created using the PR branch from Configure Dominant Color and Fetchpriority modules for their standalone plugins #704.
• Related, Rename Dominant Color module to Dominant Color images #705 renames the Dominant Color module title accordingly, however this can be decoupled from this issue and already merged before we proceed with the standalone plugins.

cc @mukeshpanchal27 @10upsimon @joemcgill