Repository navigation
Make the beta status of standalone plugins visible in wp-admin, and tell users when a feature has landed in core #2709
Description
Feature Description
Problem
The Performance team's standalone plugins have large active install counts. As of October 13, 2026, the WordPress.org plugin directory reports:
- Performance Lab: 100,000+
- Modern Image Formats: 100,000+
- Speculative Loading: 70,000+
- Optimization Detective: 60,000+
- Image Placeholders: 60,000+
- Embed Optimizer: 50,000+
- Enhanced Responsive Images: 50,000+
- Image Prioritizer: 40,000+
The Performance Lab handbook page says that Performance Lab and its suite of plugins "are considered beta testing plugins", and the Performance Lab FAQ says it "can mostly be considered a beta testing plugin". However, a site owner doesn't see this in any of the places they normally look:
-
Directory pages: there is no beta or experimental label. The only one is "(experimental)" next to View Transitions, inside the Performance Lab description.
-
Beta section of the directory: it lists Performance Lab but none of the standalone plugins.
-
Plugins > Add Plugin: the "Beta Testing" tab only appears on development versions of WordPress (
str_contains( get_bloginfo( 'version' ), '-' )inclass-wp-plugin-install-list-table.php), so it never shows on production sites. -
Plugins screen: the descriptions of Speculative Loading and Modern Image Formats give no hint, and only some plugins carry "-beta" in their version number.
When a feature lands in core, the standalone plugin keeps running and says nothing about it: -
Speculative Loading: speculative loading was merged in WordPress 6.8, and the readme says so. But with the plugin active, the site moves from core's prefetch with conservative eagerness to the plugin's prerender with moderate eagerness, and nothing in wp-admin tells the user that core already provides the feature.
-
Enhanced Responsive Images:
sizes="auto"was merged in WordPress 6.7. According to the readme, the remaining feature (accurate sizes) is not available to classic themes, so on a classic theme the plugin adds nothing, and there is no notice either.
In the client sites I maintain I regularly find these plugins active, with owners who don't know they are testing plugins, or who keep them after the feature is already in core.
The April 2025 core committers check-in pointed in the same direction: "It's often not widely known that canonical plugins exist or that they are officially maintained", and "Feedback is mainly received from users when something breaks."
Precedent
- Allow marking certain standalone plugins as experimental #1045 added an experimental flag that the Performance Lab settings screen displays (View Transitions shows "(experimental)"). It only shows there, not in the plugins themselves.
- Older feature plugins handled the merge into core:
- WP Auto-Updates and Plugin Dependencies deactivated themselves once their functionality was in core.
- Better Code Editing showed an admin notice saying its functionality had been merged into core and the plugin could be deactivated and uninstalled.
- The Features as Plugins handbook page says: "Make sure the feature plugin noops once the feature is merged."
Proposal
None of this needs changes to core or to the plugin directory. It can all be done inside the plugins.
- Persistent label on the Plugins screen: a line in each standalone plugin's row (for example via
plugin_row_meta) stating that it is a beta or feature plugin from the Performance team, with a link to its FAQ. Not dismissible. - One-time notice on activation: explain what the plugin is, that it is meant for testing features, and the main trade-offs of running it in production.
- Notice when the feature is in core: when the plugin's feature, or part of it, is already in core, show an admin notice saying so. Where the plugin no longer adds anything for that site, make it a no-op or offer to deactivate it, as older feature plugins did. Candidates:
- Speculative Loading on WordPress 6.8+: say that core already does speculative loading and that the plugin changes its default mode and eagerness.
- Enhanced Responsive Images on classic themes.
- Consistent status everywhere: use the same beta or experimental status in the readme, the directory description, the version string and the Performance Lab screen.
Why It's Important
Active installs are currently the main signal of adoption for these features. Making sure those installs are informed makes the signal more meaningful, and fewer surprises end up in the support forums.
I'm happy to help test or review a PR.
Activity
adamsilverstein commentedon Oct 23, 2026
Thanks for the issue @fernandotellado - a few comments inline
or just add (beta) to the name?
generally we retire features or plugins entirely when merged to core.
this is still true, right?
fernandotellado commentedon Oct 25, 2026
Thanks @adamsilverstein.
That would work, and it reaches more places than a row meta line: directory search results, the Add Plugin cards, the Plugins and Updates screens and the Performance Lab screen. People would see it before installing, it needs no code, and nobody can dismiss it. Applying it to Performance Lab and all the standalone plugins at the same time would also cover point 4.
Agreed, and Fetchpriority is a good model. Version 1.1.0 added an admin notice when the feature was already in core (#769): "Fetchpriority is already part of your WordPress version. Please deactivate the Fetchpriority plugin." The plugin was closed later, in June 2024.
The plugins in this issue are the ones where that hasn't happened yet:
sizes="auto"has been in core since 6.7.The notice step matters because closing a plugin on WordPress.org tells nothing to the sites that still have it active. They just stop getting updates. Could the Fetchpriority sequence (a release with a notice, then retirement) become the documented process for standalone plugins?
Yes. I tested it on WordPress 7.1.3 with Speculative Loading 1.7.0 and pretty permalinks:
wp_get_speculation_rules_configuration()returnsprerender/moderatewith the plugin active andprefetch/conservativewithout it. The plugin also adds the mode and eagerness settings under Settings > Reading, which core doesn't have, so the issue doesn't ask to retire it. A notice saying that core already does speculative loading and that the plugin changes its defaults would be enough.adamsilverstein commentedon Oct 25, 2026
I'm supportive of improving our messaging here to make it very clear what each plugin offers beyond what core already offers. I'm not sure the best place to put that information, I'm hesitant to add admin notices because those tend to be so overused they also ignored because of overuse. Maybe adding to the readme and settings pages is enough. I'm curious to hear from other maintainers what they think.
fernandotellado commentedon Oct 25, 2026
Thanks Adan. Fair point about admin notices: there are so many that people stop reading them.
Readmes have the same problem, if not worse. Very few people open the full readme, before or after installing. The part they do see is the short description, which shows on the
Add Plugincards and in directory search results. Settings pages don't help much either: Enhanced Responsive Images and Performant Translations don't have one, and the Speculative Loading section under Settings > Reading is only seen by people who go looking for it.Three places reach every site owner without being notices:
Descriptionplugin header), which they see every time they manage their plugins. None of the current ones mention core. Performant Translations says "Making internationalization/localization in WordPress faster than ever before", while its readme says "You might not need it anymore".Some examples that say what each plugin adds beyond core. They're under 150 characters, so they'd work for both descriptions:
None of this needs notices or new code. For plugins that end up retired, a final notice like Fetchpriority's still seems worth it, since it's the last update those sites will get.