Repository navigation
Overview: Creating standalone plugins #656
Description
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:
- Publish the modules available as standalone plugins
- 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.phpfiles #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-pluginsfeature branch intotrunk#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
pluginsfolder 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.distFiles 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
pluginsdirectory plugin. #1006 - Add: Auto Sizes for Lazy-loaded Images #904
- Move
auto-sizesto plugins folder #972 - Fix unit test for
feature/auto-sizesbranch #971 - Move Auto Sizes plugin assets to plugins folder #999
- Fix unit test for Multisite #1014
- Remove
TODOfromdeploy-standalone-plugins.yml#1020 - Merge: Infrastructure for standalone plugins #1021
- Fix
get-plugin-dircommand 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.
Activity
felixarntz commentedon Apr 5, 2023
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 commentedon Jan 8, 2024
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 commentedon Feb 28, 2024
@joemcgill @mukeshpanchal27 @swissspidy @westonruter @thelovekesh Now that the
feature/modules-to-pluginsbranch 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:
feature/modules-to-pluginsintotrunkas is. This should allow us to work on the standalone plugins code while not changing which modules are available in the Performance Lab plugin.trunk, but do not merge until the decision is clear. Or we could work in a feature branch likefeature/legacy-module-removal.feature/modules-to-pluginsintotrunkas is.trunkwhich we can use to create2.9.xfollow up releases as needed, i.e. without the module removal.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 the2.9.xbranch, and from there we would create those releases too.Let me know your thoughts on those ideas.
thelovekesh commentedon Feb 28, 2024
+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 ontrunkfor3.0.0(based on the decision) without any complex branching limbo state.westonruter commentedon Feb 28, 2024
I also lean toward option 2.
swissspidy commentedon Feb 28, 2024
Option 2 👍
felixarntz commentedon Feb 28, 2024
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.xbranch, 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 commentedon Feb 29, 2024
I also go with Option 2.
I will open PR that removes those
TODO.mukeshpanchal27 commentedon Feb 29, 2024
The PR #1020 ready for review.
joemcgill commentedon Feb 29, 2024
@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-pluginsintotrunkthe less complicated I think additional work during this release cycle will be.felixarntz commentedon Feb 29, 2024
@joemcgill
I just checked and there are a few minor fixes in
trunkalready 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 called2.9.0is 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 called2.9.xor just2.9). We could iterate on the overall branching strategy in the future.felixarntz commentedon Mar 1, 2024
I just ended up creating a
2.xbranch 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-pluginsintotrunkis waiting for two approvals :)joemcgill commentedon Mar 1, 2024
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 commentedon Mar 6, 2024
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 commentedon Apr 29, 2024
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.