Making WordPress.org

Opened 12 months ago

Closed 5 months ago

#7307 closed feature request (maybelater)

Opt-in Live Preview and External Demo Links for WordPress.org Plugin Repository

Reported by: mdburnette's profile mdburnette Owned by:
Milestone: Priority: normal
Component: Plugin Directory Keywords:
Cc:

Description

Summary:
This proposal aims to enhance the WordPress.org Plugin Repository by introducing an opt-in live preview functionality using WordPress Playground and an option for developers to provide an external demo link. The live preview options would allow users to test plugins before deciding to use them.

History:
A version of this "live preview" was recently (Oct 2023) attempted, but quickly retracted after opposing community feedback because of the unilateral decision to add to all plugins and the large number of plugins that require dependencies to work. Because of this, many developers feared that their plugin would not be chosen due to a broken preview experience.

Proposed solution:
The live preview options are an enhancement to allow site builders to test plugins before deciding to use them, whether using the built-in capabilities of WordPress Playground or setting up an external demo with dependencies. Both options would be added in the plugin headers and parsed alongside the plugin details as usual for the plugin repository.

For inclusion of a "Live Preview" button utilizing the WordPress Playground, a header field of "Playground" that could be set to "true" would opt the plugin into having the button visible. (False would be the default and the Playground field should be omitted if not applicable.)

Example:

/*
Plugin Name: WordPress Plugin
Plugin URI: https://example.com/plugin
Description: An example plugin.
Version: 1.0
Author: Author Name
Author URI: https://example.com
License: GPL2
Playground: true
*/

For a pre-set external demo, a "Demo URI" field would be added with the value of the demo link. This would add a button labeled "Launch Demo" - as opposed to "Live Preview" - to provide context for where the user is directed.

Example:

/*
Plugin Name: WordPress Plugin
Plugin URI: https://example.com/plugin
Description: An example plugin.
Version: 1.0
Author: Author Name
Author URI: https://example.com
License: GPL2
Demo URI: https://example.com/demo-site
*/

Should both fields be present, the "Demo URI" field would take precedence over the "Playground" field.

Original concept written here:
https://mburnette.com/blog/plugin-repo-live-preview-button/

Change History (7)

#1 follow-up: @Otto42
12 months ago

I suggest that no header be added to the readme file, but instead a simple opt-in would be available in the advanced area.

Version 0, edited 12 months ago by Otto42 (next)

#2 in reply to: ↑ 1 @mdburnette
12 months ago

Replying to Otto42:

I suggest that no header be added to the readme file, but instead a simple opt-in would be available in the advanced area.

Additionally, no header would be needed for a Demo URL either, And as such, these are really two different functionalities.

The fact that I've created 2 plugins and have no idea where the advanced area is shows maybe how well that would work. I'm not proposing a change to the README, rather in the plugin main file header (the contents of which I look up in the docs every time I create a new plugin anyway).

I'm not sure I understand what you mean by not needing a Demo URL? Yes, you could add a link in the README file to a demo, but the idea is that you add a button next to "Download" that makes it obvious where you can find a demo or preview via WordPress Playground.

Because the button that is added is either one that says "Live Preview" and goes to WP Playground or "Launch Demo" and goes to an external demo, it seems like the same functionality to me - or at the very least closely related.

This ticket was mentioned in Slack in #meta by courtneyengle. View the logs.


12 months ago

#4 @Otto42
12 months ago

Headers that are intended for the wordpress.org directory only are always in the readme file. The plugin main PHP file only gets headers when they are intended for WordPress core itself to see.

In this case, neither one of those needs to have a header. Because all future new developments in this respect are going on the /advanced page, so that plugin authors can see them and make adjustments directly in the directory, rather than requiring an SVN change in the readme file. We have had that for a couple years or so now.

Also, I agree that they're related, but it's still two separate things. Code-wise, they have little to do with one another.

#5 @joostdevalk
12 months ago

I’m fine with the advanced area. If plugin devs don’t know where to find that, we need to fix that with comms & UX, not stop using it.

I do think the feature would be even better if we let people define their own blueprint.json (maybe in the svn-assets directory) which helps plugins create blueprints with specific extensions or other required plugins.

Docs for blueprints: https://wordpress.github.io/wordpress-playground/blueprints-api/index/

Last edited 12 months ago by joostdevalk (previous) (diff)

#6 @dd32
7 months ago

Is this a duplicate of #7251 ?

#7 @dd32
5 months ago

  • Resolution set to maybelater
  • Status changed from new to closed

I'm going to close this; At this point there is no plan to add a demo site field, but Blueprints with Live preview fulfils most of the use-cases that come up there.

Through Live Previews with Blueprints #7251 a user can test any plugin, and if the developer has set it up, with test data too and default configurations.

Note: See TracTickets for help on using tickets.