Repository navigation
Set up additional standalone plugins for Dominant Color and Fetchpriority #640
Description
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.txtfiles should be added to the module directoriesimages/dominant-colorandimages/fetchpriorityfor 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.jsonconfig 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 slugdominant-color-images(a plugin with slugdominant-coloralready exists), plugin version:1.0.0images/fetchpriority: plugin slugfetchpriority, plugin version:1.0.0
Activity
felixarntz commentedon Feb 14, 2023
Based on #618 (comment), I'd like to share here the list of current modules we would publish, depending on each alternate policy:
images/dominant-colorimages/fetchpriorityimages/webp-supportimages/webp-uploadsdatabase/audit-autoloaded-optionsjs-and-css/audit-enqueued-assetsdatabase/sqliteimages/dominant-colorimages/fetchpriorityimages/webp-supportimages/webp-uploadsdatabase/audit-autoloaded-optionsjs-and-css/audit-enqueued-assetsdatabase/sqliteimages/dominant-colorimages/fetchpriorityimages/webp-uploadsdatabase/sqliteThis 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 commentedon Feb 14, 2023
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 commentedon Feb 21, 2023
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!
[-]Finalize list of modules to publish as standalone plugins[/-][+]Set up additional standalone plugins for Dominant Color and Fetchpriority[/+]felixarntz commentedon Apr 5, 2023
A PR for this can be opened against the
trunkbranch as soon as #699 is merged. However, it must not be merged intotrunkuntil these two plugins have their wp.org repositories approved.Here's a summary of what the PR needs to include:
dominant-color-imagesandfetchprioritytoplugins.json.There may be something else, but those 3 things are what I can think of now.
felixarntz commentedon Apr 6, 2023
Providing a brief update here:
Dominant ColorandFetchprioritymodules for their standalone plugins #704 addresses the two points in the issue description, i.e. the overall issue.Dominant ColorandFetchprioritymodules for their standalone plugins #704.Dominant Colormodule toDominant 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