Support Plugin Previews in the .org Plugin Directory

[joemcgill]

Feature Description

The WP.org Meta team just announced the relaunching of the plugin preview feature, whereby people can try out the plugin in a sandbox using WP Playground before installing. This is pretty cool, but requires plugin devs to opt-in. Here's the post with the details:

https://make.wordpress.org/meta/2023/11/22/plugin-directory-preview-button-revisited/

We should consider adding opt in to Performance Lab and for the standalone plugins.

[swissspidy]

Should be trivial to add in theory, but I don't think it adds any value.

• The Health Check integrations are useless because Site Health is disabled in Playground.
• WebP does not seem to be supported, so JPEG-> WebP conversion doesn't work
• Dominant color is hard to test as a user

[mukeshpanchal27]

I concur with @swissspidy. The opt-in feature seems to lack value as many of its functionalities are either disabled or non-operational within the playground environment. I conducted tests on it here: playground.wordpress.net/?plugin=performance-lab.

Could we initiate an issue on the playground to incorporate support for WebP? Additionally, I'm curious to know why the dominant color functionality isn't working on it 🤔.

[felixarntz]

@swissspidy @mukeshpanchal27 Regardless of the actual feature limitations, wouldn't it still be nice to have a preview available that by default leads to the Settings > Performance admin screen? That at least shows folks what the concept behind this plugin is and which features are provided without reading through the readme (individual performance features).

My only concern is: In Playground the WebP module allows to be activated. Shouldn't it show as disabled with a message if WebP is not supported by the server environment? We should probably implement such a check for the module / plugin.

[joemcgill]

I think value is a fair question. Personally, I'm also interested in being able to spin up a preview and play with server timing in this environment, but I guess it would be no different than running my own Playground instance locally, since WP is just running inside my local browser (which is still mind boggling).

Otherwise, I think it's being a good citizen of the community to include this feature on our plugins for visibility.

[swissspidy]

Regardless of the actual feature limitations, wouldn't it still be nice to have a preview available that by default leads to the Settings > Performance admin screen? That at least shows folks what the concept behind this plugin is and which features are provided without reading through the readme (individual performance features).

If looking at the settings screen is deemed helpful, why don't we add screenshots to the plugins page first?

Right now the Preview feature isn't public anyway, so this is not urgent.

[felixarntz]

@swissspidy

If looking at the settings screen is deemed helpful, why don't we add screenshots to the plugins page first?

It's not very maintainable and risks having outdated screenshots in the repo. The available modules change, and right now we're even reworking the screen as a whole. Having to update the screenshot is a manual task I think we can avoid, with that preview serving that use-case in an easier and more comprehensive way.

Right now the Preview feature isn't public anyway, so this is not urgent.

I thought it was once opted in?

[swissspidy]

IIUC once you add a blueprint, plugin committers can see the preview bit it‘s still not live.

Adding a blueprint for the preview is trivial. If y‘all think it doesn‘t hurt to have a not-so-useful preview, let‘s just add it.

[felixarntz]

I'd say +1 to add a blueprint pointing to Settings > Performance.

My only additional thought is that we should implement a check to indicate when WebP is not supported. It's a separate problem though, so we could also open a separate blocking issue for it, if you prefer.

[swissspidy]

It's a separate problem though, so we could also open a separate blocking issue for it, if you prefer.

+1 to a separate issue, as I don't know how much effort is required to investigate it. I wouldn't consider it blocking though because it's not. The preview is still not fully live after all.

A minimal blueprint in .wordpress-org/blueprint.json could look like this:

{
  "$schema": "https://playground.wordpress.net/blueprint-schema.json",
  "landingPage": "\/wp-admin\/admin.php?page=perflab-modules",
  "phpExtensionBundles": [
    "kitchen-sink"
  ],
  "steps": [
    {
      "step": "login",
      "username": "admin",
      "password": "password"
    },
    {
      "step": "installPlugin",
      "pluginZipFile": {
        "resource": "wordpress.org\/plugins",
        "slug": "performance-lab"
      },
      "options": {
        "activate": true
      }
    },
    {
      "step": "setSiteOptions",
      "options": {
        "perflab_modules_settings": "a:2:{s:28:\"images/dominant-color-images\";a:1:{s:7:\"enabled\";b:1;}s:19:\"images/webp-uploads\";a:1:{s:7:\"enabled\";b:1;}}"
      }
    }
  ]
}

This installs the plugin and enables the WebP Uploads and Dominant Color Images modules.

Note: we could add wp-now as a dev dependency too for easier local testing, but for that we would need to bump our archaic node version requirement.

As for the Site Health modules, I suggest adding can-load.php files to disable them when Site Health is disabled. This should suffice:

return static function () {
	return current_user_can( 'view_site_health_checks' );
};

[mukeshpanchal27]

If we add can-load.php then it will show message like: X Health Check is already part of your WordPress version and therefore cannot be loaded as part of the plugin. so it may be misguide the user. WDYT?

When we disable the site health checks, when it disabled then we don't need setSiteOptions step.