Making WordPress.org

Opened 7 weeks ago

Last modified 7 weeks ago

#7307 new feature request

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 (5)

#1 follow-up: @Otto42
7 weeks 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.

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

Last edited 7 weeks ago by Otto42 (previous) (diff)

#2 in reply to: ↑ 1 @mdburnette
7 weeks 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.


7 weeks ago

#4 @Otto42
7 weeks 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
7 weeks 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 7 weeks ago by joostdevalk (previous) (diff)
Note: See TracTickets for help on using tickets.