Overview: Creating standalone plugins

[felixarntz]

Originally discussed in #618, this issue acts purely as an overview of all the issues related to creating standalone plugins for the modules that are currently part of the Performance Lab plugin, and then removing the corresponding modules from the PL plugin in favor of the new standalone plugins.

Milestones

This effort should be broken down into 2 milestones:

1. Publish the modules available as standalone plugins
2. Remove the modules from the plugin

The first milestone will unblock the more urgent goal of having standalone plugins for every performance feature project, as well as therefore having a clear path forward also for new features.

The second milestone will ensure those standalone plugins are the canonical way to test those features, with the Performance Lab plugin still providing supporting features e.g. related to performance measurement and management of the performance related features and their plugins.

While the first milestone does not change anything notable for existing Performance Lab plugin users, the second one will require administrators to install/activate the new plugins and can therefore be considered a breaking change. As such, the second milestone should eventually be released with a major version number change, as 3.0.0.

List of issues

The list below includes all related issues, somewhat ordered by their intended sequence of execution. Important to note:

• Some of the issues can be worked on in parallel.
• The issue for milestone 2 can be defined as milestone 1 is being worked on, however milestone 2 issues should only be implemented / merged after milestone 1 has been completed.
• The list is not necessarily comprehensive, more issues will be added as needed.
• You can always get a list of issues also using the "Creating standalone plugins" label.

Milestone 1

• Implement CLI command to for a build process to transform modules into standalone plugins #635
• Implement GitHub workflow to have a basic test for standalone plugins #639
• Add module-specific readme files and enhance CLI command to include standalone plugin readme files #636
• Check for each module to only load it if the corresponding standalone plugin is not loaded #666
• Remove any functions, classes, constants etc. from module load.php files #667
• Set up WordPress.org repositories for standalone plugins #637
• Implement GitHub workflow to build and deploy standalone plugins #638
• Support standalone plugins in PL generator meta tag #692
• Set up additional standalone plugins for Dominant Color and Fetchpriority #640
• Migrate SQLite integration plugin back into monorepo for development #661

Milestone 2

2a (2.8.0 release)

• Update PL settings screen with new UI to manage standalone plugins and built-in modules #651
• Implement migration logic and UI from old PL modules to new standalone plugins in PL settings screen #652
• Enhance experience when installing _and_ activating a standalone plugin #880
• Implement admin pointer to indicate to the user they need to activate the new standalone plugins #653
• Merge feature/creating-standalone-plugins feature branch into trunk #901

Follow-up PRs:

• Fix Plugin card UI and thickbox issue #896
• Follow-up: Minor changes for creating standalone plugins #912
• Revise migration pointer un-dismissal to work for all admins #917
• Load migration script in plugin setting page #920

2b (3.0.0 release)

• Introduce plugins folder for standalone plugins #934
• Remove the modules that were published as standalone plugins from the Performance Lab plugin #654
• Implement publishing workflow for standalone plugins that aren't modules #935
• Add upgrade notice to inform users of major change prior to 3.0.0 update #655

2c (3.0.0 release polishing)

• Make remaining modules (all Site Health) part of Performance Lab core #1029
• Remove modules infrastructure #1030
• Improve UX/UI of enabling performance features via standalone plugins #1031
• Allow marking certain standalone plugins as experimental #1045

Follow-up Issues & PRs:

• Separate phpcs.xml.dist Files for Each Plugin to Isolate Text Domains #997
• Expand workflow and linting checks to run on all branches #998
• Add a build process for the plugins directory plugin. #1006
• Add: Auto Sizes for Lazy-loaded Images #904
• Move auto-sizes to plugins folder #972
• Fix unit test for feature/auto-sizes branch #971
• Move Auto Sizes plugin assets to plugins folder #999
• Fix unit test for Multisite #1014
• Remove TODO from deploy-standalone-plugins.yml #1020
• Merge: Infrastructure for standalone plugins #1021
• Fix get-plugin-dir command for plugins #1026

See #911 for somewhat related discussion, which however is not a blocker to this effort. Additionally, documentation for how to write a module will need to be updated after the 2b changes, and basic documentation for how to start a new plugin in the repo should be added too.

[felixarntz]

See #699 for the PR that brings all the initial Milestone 1 work into trunk, in preparation for tomorrow's release of the first standalone plugin from this repository, WebP Uploads.

Related PL plugin changes (which are minimal) will be included in the upcoming 2.2.0 release.

[felixarntz]

Reopening as the "2b" part (for Performance Lab 3.0 release, tentatively March) is still left to do.

I'm planning to open issues for that this week.

[felixarntz]

@joemcgill @mukeshpanchal27 @swissspidy @westonruter @thelovekesh Now that the feature/modules-to-plugins branch has all the foundational infrastructure set up (as far as I can tell), let's take a step back and consider the next steps.

There are still a few discussions going on regarding whether or when we should go through with the plan to remove the legacy modules from Performance Lab. For that reason, I would advise to not merge #1011 and #1019 until that decision has been finalized. Potentially we may delay the 3.0.0 release until the decision as well.

Here are two alternative ideas how we can deal with that in a way that gets us out of the complex branching limbo state we're currently in:

• We could do the following to unblock the other work apart from module removal:
  • Merge feature/modules-to-plugins into trunk as is. This should allow us to work on the standalone plugins code while not changing which modules are available in the Performance Lab plugin.
  • Update Move published modules to standalone plugins #1011 and Upgrade notice to inform users of major change prior to 3.0.0 update #1019 to go against trunk, but do not merge until the decision is clear. Or we could work in a feature branch like feature/legacy-module-removal.
• Yet another alternative focusing more on simplifying the new status quo would be the following:
  • Merge feature/modules-to-plugins into trunk as is.
  • After that, create a new branch from trunk which we can use to create 2.9.x follow up releases as needed, i.e. without the module removal.
  • Then merge Move published modules to standalone plugins #1011 and Upgrade notice to inform users of major change prior to 3.0.0 update #1019 into trunk. This will effectively be the "future 3.0.0" branch from then on, while any 2.9.x follow up fixes would need to be implemented against the 2.9.x branch, and from there we would create those releases too.

Let me know your thoughts on those ideas.

[thelovekesh]

+1 for the second choice. For any immediate patch releases, we can focus on 2.9.x. This allows us to streamline the module removal and related tasks on trunk for 3.0.0(based on the decision) without any complex branching limbo state.

[westonruter]

I also lean toward option 2.

[swissspidy]

Option 2 👍

[felixarntz]

Thanks, looks like option 2 is already with enough votes to be a decision :)

Before we do that, I just want to double check: I believe both https://github.com/WordPress/performance/blob/trunk/.github/workflows/deploy-dotorg.yml and https://github.com/WordPress/performance/blob/trunk/.github/workflows/deploy-standalone-plugins.yml act on the branch that a release is created from, correct? I just want to make sure that if we release a 2.9.x from the future 2.9.x branch, both Performance Lab and the standalone plugins will come from that branch.

Oh, and on another note: I just noticed we merged https://github.com/WordPress/performance/blob/feature/modules-to-plugins/.github/workflows/deploy-standalone-plugins.yml with the TODOs still in place. Let's fix that :)

[mukeshpanchal27]

I also go with Option 2.

Oh, and on another note: I just noticed we merged https://github.com/WordPress/performance/blob/feature/modules-to-plugins/.github/workflows/deploy-standalone-plugins.yml with the TODOs still in place. Let's fix that :)

I will open PR that removes those TODO.

[mukeshpanchal27]

The PR #1020 ready for review.

[joemcgill]

@felixarntz I agree mostly with option 2, the only modification I would suggest is that we don't need a new release branch for any 2.9.x versions, as we already have release/2.9.0 that we can use to prepare and release any minor releases.

The main thing we may need to be aware of is that many github actions will run the version that is described in the default branch of the repo, so we should review our workflows to make sure we won't be breaking anything (particularly deployment workflows) by merging changes to workflows prematurely.

At this point, the sooner we can merge the current feature/modules-to-plugins into trunk the less complicated I think additional work during this release cycle will be.

[felixarntz]

@joemcgill

the only modification I would suggest is that we don't need a new release branch for any 2.9.x versions, as we already have release/2.9.0 that we can use to prepare and release any minor releases.

I just checked and there are a few minor fixes in trunk already that could be part of the next 2.9.x release. The other thing is that so far the release branches have been used as basically an exact representation of the release from which to create working branches for patch releases as necessary. Basically the branch called 2.9.0 is for the 2.9.0 release, not the "2.9" overall branch, like e.g. WordPress core has it. This may not make the most sense now that I think about it, but so far it's been like that. For the current situation I'd prefer we'd have a dedicated branch for 2.9.x (which could be called 2.9.x or just 2.9). We could iterate on the overall branching strategy in the future.

[felixarntz]

I just ended up creating a 2.x branch for that purpose. Really, it doesn't even need to reference 2.9, it's simply the branch for anything pre-3.0. Eventually we'll remove it, and who knows if there's nothing significant in it, we may never even release another 2.9.x version.

The PR #1021 to merge feature/modules-to-plugins into trunk is waiting for two approvals :)

[joemcgill]

This may not make the most sense now that I think about it, but so far it's been like that. For the current situation I'd prefer we'd have a dedicated branch for 2.9.x (which could be called 2.9.x or just 2.9). We could iterate on the overall branching strategy in the future.

Thanks for the explanation. Given that we also have tags for each release, having additional branches that are release specific, and not for the purpose of being able to handle bug/security fixes related to one of our previous major releases, probably isn't useful, but we can discuss updating our branching strategy elsewhere.

[felixarntz]

I have opened issues for the additional polishing work discussed earlier today, which includes removing modules entirely and revising the UI to focus on features rather than plugins.

See the 2c entry in the issue description for those issue links.

[joemcgill]

I've changed #1032 to be an overview issue where we can define and collect the tasks to be done to enhance the onboarding experience as a separate epic. We can now consider the initial project for transitioning modules to standalone projects to be complete and close this epic.