Add a Preview in Playground button to the plugin directory

[tellyworth]

Now that the WordPress Playground has made it possible to safely test any plugin, we should add a button or link to the Plugin Directory so that users can preview a plugin with a single click.

Clicking the button/link would open a new window with a target URL similar to ​https://playground.wordpress.net/?plugin=hello-dolly (with the plugin's slug of course).

The button/link could go near the existing Download button, or it could even replace it. I'll defer to design feedback on the appearance and UX considerations.

Other decisions and considerations:

• Should it simply open a new tab with the playground preview, or something else (popup?)
• Does it need any logic for selecting the WP/PHP version or can we go with the default?
• Should it be available on all plugins, or selectively (eg only those actively maintained, or supporting a recent WP version?)
• What should the landing page of the preview be? (Perhaps /wp-admin/plugins.php?)

Note that this proposal is for a very simple Playground preview, a MVP. There are many additional ideas that we can discuss and add later.

[tellyworth]

Example showing where we might place a hypothetical button

[Otto42]

Sounds like a good idea to me. However, I have some questions.

First, I'm assuming that this is simply a matter of building the link to install the plugin. And then the playground goes and retrieves the plugin and installs it as part of the process. Easy enough to do.

The question I'm wondering about is how does it retrieve the plugin? Does it download the zip file separately? Or does it get the plugin files from SVN? I'm wondering if this would add any load to the system from getting these files for such a temporary use.

[Marc4]

I think it's a good idea. The immediacy of Playground is ideal for discovering content from the repository.

Sorry if this is directly related but I recently created a plugin that also allows you to do that from within your WordPress installation, among other things.

From within your WordPress you access the plugins or themes directory and a "Playground" button appears to test that theme or plugin without having to use your local installation.

As you don't have access to the plugins and themes directory you won't be able to test the buttons, but you can see it here:

​https://playground.wordpress.net/?plugin=toys-for-playground&url=/wp-admin/admin.php?page=toys-playground&mode=seamless&networking=yes (I love how fast it is to get here with Playground).

Plugin: ​https://wordpress.org/plugins/toys-for-playground/

---

What should the landing page of the preview be? (Perhaps /wp-admin/plugins.php?)

I think for plugins it would be interesting to take them directly to the plugin configuration page. As I did in the link above. If the configuration page doesn't exist, you could send them to /wp-admin/plugins.php

In the plugin I send the user to the wp-admin for plugins and to the front end for themes.

Does it need any logic for selecting the WP/PHP version or can we go with the default?

The default ensures better performance (newer versions of PHP and WP).

[JeffPaul]

Answering these questions with my "plugin developer" hat on...

Should it simply open a new tab with the playground preview, or something else (popup?)

From an a11y perspective, my understanding is that we might best default to opening in the current tab.

Does it need any logic for selecting the WP/PHP version or can we go with the default?

I think going with the ​current WP version (major or minor) and the ​recommended PHP version (currently 7.4). Playground would presumably allow from its experience to change these versions, but I think our defaults would best be current major/minor WP and recommended PHP.

Should it be available on all plugins, or selectively (eg only those actively maintained, or

supporting a recent WP version?)
My initial reaction is all plugins, so that we're not "playing favorites" with the ability to test out a plugin but this is not a hill I would die on and would relent to ones that marked as tested with the latest 3 major releases of WP.

What should the landing page of the preview be? (Perhaps /wp-admin/plugins.php?)

I think that's probably best, yeah, as that allows someone to demo the "normal" post-install flow and dive right into activation and testing.

[dufresnesteven]

My initial reaction is all plugins, so that we're not "playing favorites" with the ability to test out a plugin but this is not a hill I would die on and would relent to ones that marked as tested with the latest 3 major releases of WP.

Adding that it's likely still the case (someone else can confirm), not all plugins work in the Playground so we should build in an opt-out mechanism.

[tellyworth]

Replying to Otto42:

The question I'm wondering about is how does it retrieve the plugin? Does it download the zip file separately? Or does it get the plugin files from SVN? I'm wondering if this would add any load to the system from getting these files for such a temporary use.

Playground downloads the plugin zip file. Here's the code:

​https://github.com/WordPress/wordpress-playground/blob/6725fcff2d1d1bbf3a1b638bc0e186941436d944/packages/playground/website/public/plugin-proxy.php#L21-L39

It's using downloads.wordpress.org which I assume will be safe from a bandwidth/resource POV. It will probably affect the plugin download stats though. Which is not a blocker but worth some further thought.

[JeffPaul]

It's using downloads.wordpress.org which I assume will be safe from a bandwidth/resource POV. It will probably affect the plugin download stats though. Which is not a blocker but worth some further thought.

Perhaps a URL param on the Preview/Demo button that launches Playground that would skip the download stat trigger?

[tellyworth]

A URL param to skip counting the download would work, but we'd have to consider the possibility of misuse or unexpected consequences. (The download count is pretty meaningless IMO)

[tellyworth]

Add a simple button.

[tellyworth]

Screenshot of simple button in context

[tellyworth]

Screenshot after clicking the button

[tellyworth]

I added a trivial patch implementing the button, see screenshots.

This could be refined, but other than design/css improvements I would favour deploying something as simple as this first, and then following up with a ticket about allowing plugin devs to customize the experience.

[tellyworth]

Don't show the preview button on outdated plugins

[zieladam]

Yes, yes, yes, I love it! The code change looks great, too. Thank you @tellyworth!

[tellyworth]

In 12931:

Plugins: add a simple Live Preview button (Playground)

Some additional finesse may be needed, this is to get things started.

See #7251

[jeffparker]

• Is there a way to control the previews or for a plugin to detect whether in a preview in any way? Previews for many plugins appear to be broken, especially those that rely on 3rd party API calls for setup. For example, Jetpack Plugin preview doesn't work.

• While such bugs, etc are being worked out, maybe make it opt-in for plugin authors? Users getting to broken previews are likely counterproductive.

• This is a huge change :) Very welcome upgrade once things are running properly. An announcement post would be helpful.

• Having the option to be able to specify an override Preview link in the Plugin Readme would be helpful!

[barrykooij]

I'd love a way to tell the playground what PHP extension are required by a plugin. Or have the playground at least have the PHP extensions installed that WordPress recommends here ​https://make.wordpress.org/hosting/handbook/server-environment/

Currently users get a broken experience when trying out plugins that, for example, require the mbstring extension.

[websupporter]

I love the feature!!!!

But, some plugins do not work in the playground. They might rely on php extensions which are not available or do not consequently use $wpdb for all their database calls. I think it would be good to have an opt-out for those plugins.

MailPoet e.g. needs the PDO_MySQL and the XML extension, which are not available in the playground.

[Ajay]

Can we have a field in the Readme that allows us to specify a Live Demo link that overrides the link to Playground. It’s helpful if we have our own demos set up as currently this won’t work for addon plugins or where plugins need content to work effectively and give a good user experience.

[Marc4]

Replying to Ajay:

Can we have a field in the Readme that allows us to specify a Live Demo link that overrides the link to Playground. It’s helpful if we have our own demos set up as currently this won’t work for addon plugins or where plugins need content to work effectively and give a good user experience.

I thought about this before as well. Specifically in something like a playground.php, this would allow to show or not content for Playground and that this content can be different from the "index.php". Does it make sense?

[Ajay]

I was thinking something even simpler. In the readme we set a field “Demo link” like how we have “Donate Link” where we can link to our own demo.

Replying to Marc4:

Replying to Ajay:

Can we have a field in the Readme that allows us to specify a Live Demo link that overrides the link to Playground. It’s helpful if we have our own demos set up as currently this won’t work for addon plugins or where plugins need content to work effectively and give a good user experience.

I thought about this before as well. Specifically in something like a playground.php, this would allow to show or not content for Playground and that this content can be different from the "index.php". Does it make sense?

[lesleysim]

Yay!! What an amazing feature!

I'd like to request for this feature to be opt-in (or, at least, opt-out).

Simply because the average user:

1. Isn't going to know this is a new feature.
2. Won't have patience if something is broken.
3. Will assume that it's a problem with the plugin and not with the directory or the playground.

So it ends up reflecting badly on the plugin developer, which can be really stressful for them if it means a loss in (potential) revenue/installs (yes, I understand that many people think this shouldn't be a key concern, but it is the reality for many small plugin devs) or if they have additional support burden as a result of this feature, which is completely out of their hands.

Having an opt-in/out option will allow plugin devs to adjust to this new feature and use it when they're ready.

[zodiac1978]

currently this won’t work for addon plugins

Could the plugin dependency feature maybe solve this?
​https://core.trac.wordpress.org/ticket/22316

cc: @afragen

[webdevmattcrom]

Replying to barrykooij:

Currently users get a broken experience when trying out plugins that, for example, require the mbstring extension.

This was pushed live to ALL plugin despite this fact, that's really disturbing. WP has such a challenging reputation when it comes to stability because of the plugin ecosystem, and now we're giving live previews to the world that are broken even though the plugins themselves are NOT broken.

Please implement a Demo link url in the readme like @Ajay recommended above and only show the button if a url is present. Makes it opt-out by default like @lesleysim recommended and gives plugin authors control over this experience. This would improve the experience for users 10-fold.

[YordanSoares]

I think this could be a great feature, but only if the button link is customizable, otherwise it will cause frustration for the developers and users on those plugins that requires some specific environment settings or other plugin dependencies.

For instance, the ​PDF Invoices & Packing Slips for WooCommerce plugin requires WooCommerce activated, but also you would need to have the store configured and with dummy products, to be able to test the PDF documents. Otherwise, the users could be frustrated because they would need to configure all these things manually.

If the above is not yet possible, adding the opt-in/opt-out ability would be very useful to avoid complaints from the developers about this new feature.

[Otto42]

Replying to tellyworth:

It's using downloads.wordpress.org which I assume will be safe from a bandwidth/resource POV. It will probably affect the plugin download stats though. Which is not a blocker but worth some further thought.

Add nostats=1 to the URL to not count in downloads.

[hcabrera]

This is a nice addition and I'm sure lots of users will love it.

Would it be possible to preconfigure Playground so it uses a Permalink structure that's not the "Plain" one? Or maybe add a way for plugin devs to set specific settings for their plugin demo?

[maartenbelmans]

I like the power the playground offers! However, I also think it's too early to push it to the whole plugin repository. My thoughts:

• A lot of plugins require another plugin to be active, such as all WooCommerce extensions.
• Similarly, a lot of plugins require some sort of base setup (or WP settings to be active) to function properly.
• When someone clicks "preview", do they expect to see the WP admin, or do they expect to see a demo site showing plugin features?

As it stands, none of the WooCommerce (and many other) plugins can make proper use of the preview. I think it would be great if the plugin developer can choose the link for the button:

• Do not show a link (opt-out).
• Show a link pointing to the playground.
• Show a link pointing to a demo site hosted by the developer.

[illuminea]

This is a really cool concept, and I love seeing the Playground in action!

But as many people mentioned above, a lot of plugins will be broken out of the box in this scenario due to dependencies or other issues. This will create a confusing and poor experience for users hoping to preview a plugin's functionality.

When this does work, the user ends up on the plugin installation screen, which indicates that the plugin has been installed. I wouldn't exactly call this a preview, because the plugin functionality is not being presented to the user, only the technical fact that installation has been completed.

At that point the user would have to know WordPress well enough to understand which screen they have landed on, and start clicking around to figure out how to actually see what the plugin does. If they don't, all they've seen is a screen that shows the plugin's name in the WP Admin somewhere.

As a result, I suggest that the button be called something else, like "Try it out" (or anything else that doesn't make it sound like the user is going to now get some smooth demo of the plugin's functionality).

And I also agree that this should be opt-in. Currently it doesn't look great for plugins, and for WordPress in general.

[ReneHermi]

We offer a backup and staging plugin. Our plugin will never be able to run on the Playground due to the nature of it. Everyone new who tries out our plugin on Playground will get a terrible experience, full of errors and will think our plugin does not work on his site. This will harm our reputation!

Please roll back this feature asap and communicate beforehand with us developers how we can detect if a plugin runs on playground (Then we can at least show a user a friendly message and disable our plugins core features) or give us the option to opt-out of it.

[stevejonesdev]

This is a great feature but our plugin is generating fatal errors and we need time to resolve them. I would also advocate for a way to opt out of the Live Preview.

[nawawijamili]

Of course, this is a great feature, but not all plugins are suitable for it. At least should have the option to opt-out of it.

[aurooba]

Popping in my two cents as well, echoing the surprise others have expressed at this being deployed in its current state to the entire repository.

The idea @Ajay proposed, where the README file's frontmatter has a demo link allowing the link to the customized sounds fantastic.

I also think that as a new feature with complex consequences, this should become an opt-in feature first as @lesleysim suggested, and after being thoroughly battle-tested, could perhaps move to an opt-out feature status in the future.

In addition, I think further configuration options would be super helpful. For example, for my simple block plugin, I would love to offer demo content that is a true preview of the block, rather than just being installed.

The call to action also needs some work, something along the lines of Try on a Demo Site would be more accurate.

image above shows a screenshot of the Super List Block plugin page in the repo, where the text for the "Live Preview" button has been changed to "Try on a Demo Site"

[alanfuller]

As this doesn't work for some 40% estimate of plugins, and there is not opt out / in, can this release be reverted immediately until ready and then properly communicated to the plugin developer community and then rolled out as OPT IN

[alexstandiford]

I LOVE THIS IDEA.

If it isn't already, it would be really nice to have a way to detect that the current environment is the playground. That could allow developers to tailor parts of the experience for the preview, such as pre-importing sample data, pre-configuring connections to APIs, or other un-imagined things.

Or, perhaps something like an extension for a plugin could install the base plugin, as well, allowing it to actually function as-expected.

By doing this, a plugin developer could make this experience better.

[alanfuller]

The issue is it was released today - with ZERO official communication impacting 60,000 plugins

We can detect

with [SERVER_NAME] => playground.wordpress.net and[SERVER_SOFTWARE] => PHP.wasm

But that isn't the issue, the issue this needs to be coded and tested into 1,000s of plugins as a an emergency fix to this release.

The suggestions - OPT IN and allow an alternative link to demo sites are sound. But the release should be pulled, the OPT In implemented and the alternate link implemented.

I'm surprised that no action to revert has been taken. This needs to be a the first damage limitation action.

[brianhenryie]

For instance, the PDF Invoices & Packing Slips for WooCommerce plugin requires WooCommerce activated, but also you would need to have the store configured and with dummy products,

Plugin Dependencies should be a good route to solving the former part.

For the latter, incidentally WooCommerce does ship with sample data (csv and xml files in its sample-data directory). If there were a convention for including sample data to be imported for Playground, it would also be very useful for E2E testing.

I.e. incentivising plugin developers to prepare a set of sample data then reduces the work needed to add E2E tests, and provides that sample data to other plugin developers who are looking to extend that plugin and want to write E2E tests.

E.g. I've been working on a plugin that integrates with WooCommerce and a different plugin that integrates with KB Support. It has been easier to write E2E tests for my WooCommerce related plugin because WooCommerce has provided sample data.

[alekv]

Here are my 5 cents.

Please

• make this opt-in, or at least opt-out.
• provide a way to load dependencies. Eg. WooCommerce extensions need WooCommerce installed.
• Let developers choose the preview link. They may want to use an external preview server with more control over the preview experience.

[bahia0019]

I'm here to echo what others have said. This needs to be opt-in.
I think there's been some great points made about this. One that I think might have been missed is that some plugins require some effort to setup, and just don't work well without those instructions.
Once you click Preview, you no longer have access to the Description or Installation information.

And for something like Blocks, and Block templates, a user may have absolutely no idea where to go. For my Copyright Footer ​https://wordpress.org/plugins/copyright-footer/ the user has to know to go from: Plugins page -> Appearance -> Editor -> Patterns -> Footer -> Then click on the Footer... then finally search for and add the Copyright Footer block and customize it.
This ask is already too much for the average WordPress user outside the Preview. But with it, there's absolutely no way this is an enhancement. And it doesn't "market" the plugin any better.

In addition, there's some really weird quirks with how the block is being output. It's missing placeholder text, the justify-contents: space-between; isn't being honored... It looks terrible.

Needs work. Needs to be Opt-in.

[ReneHermi]

Replying to alanfuller:

...But the release should be pulled, the OPT In implemented and the alternate link implemented.

I'm surprised that no action to revert has been taken. This needs to be a the first damage limitation action.

100% ACK. Please escalate it and roll it back to prevent further damages.
It's only a matter of time before plugins that don't work 100% in Playground get bad reviews from users who don't understand what Playground does.

[alanfuller]

I just tested the 4 featured plugins only 2 work ( Classic Editor and Classic Widgets for which you need to download and install a non block theme ) JetPack and Akismet fail

Of the top 4 most popular

• Contact Form 7 you can build a form but it hangs
• Elementor fails on loading its wizard
• Yoast fails on loading its wizard

The 4th is Classic Editor

So basically it must have been totally untested before release!

Why has it not been rolled back yet? Any reason?

[courane01]

How could this launch have been done better?

Proposal

Draft a simple proposal on Meta to outline the plan. Share this proposal, or this Trac ticket, during our bi-weekly team meetings, and also cross-post it to the Plugin team.

Active Meta team members could bring this up during meetings when teams ask to mention special projects.

Detail the steps of the project, including opt-in and opt-out options.

Work with Plugin Team

Identify potential hurdles. @ipstenu highlighted these areas:

There are major use-cases that were missed, which I would think account for 30-40% of plugins right now…

• It won’t work for add-on plugins (like things for Woo) because we can't tell what plugins depend on others, and the sandbox won’t know to install the ‘parent’ plugin
• It won’t work well for things that need a lot of custom changes (like WooCommerce itself)
• It won’t work AT ALL for anything that connects to servers (like Memcached, Redis, etc).
• Multisite

Reach Out to the Plugin Extender Ecosystem

Ask for feedback on the proposal post. If no feedback is received, directly contact active plugin developers/owners.

Use the same email methods we use to notify plugins about new WordPress versions to connect.

Work with Marketing Team

The Marketing team asks for feedback through a ​GitHub Issue to help spread the word about the different projects within the broader WordPress Project.

Marketing can propose content to the WordPress.org social media team and draft communications for news outlets, podcasts, and other media places asking for feedback and sharing information before the launch. They can also assist in drafting an email to the plugin maintainers who receive notifications about the changes at releases.

Pre-Launch Testing

Introduce a beta version of the feature to a select group of developers and users for testing and feedback. Establish a clear process for reporting and tracking bugs.

Host Online Workshops with the Training team on Learn.WordPress.org as part of the user testing process. Also host workshops here with the Developer Maintainers inviting them to provide feedback.

Documentation

Create user guides and developer documentation to help users and developers understand how to use and adapt to the WordPress Playground demo feature.

Put into Action

With feedback collected, potential hurdles identified, and clear communication with everyone, commence Phase 1. Select a small group of perhaps recommended or most popular plugins that have opted into this experiment. Evaluate feedback from users, plugin maintainers, as well as the review team.

Meta

Share project progress and learnings on the team site. Provide updates on deploying to the rest of the Plugin Repo.

Plugins

Team can share updates on how the installation impact is going and additional requests.

Marketing

Promote the updates and facilitate communications around the next stage.

Additional Insights

• Landing Page: Adopt a dynamic landing page approach - direct users to the plugin configuration page if available, else to /wp-admin/plugins.php.
• WP/PHP Version Logic: Utilize the current WP version and the recommended PHP version for better performance and compatibility.
• Plugin Inclusion: Include all plugins to avoid favoritism, with an opt-out mechanism for those incompatible with the Playground.
• Download Mechanism: Implement a URL parameter to prevent the Playground downloads from affecting the plugin download statistics.
• Button Implementation: Commend the initial implementation of the simple button, while encouraging further refinements to allow customization by plugin developers for enhanced user experience.

Suggested Action

Based on the observations and feedback, it is wise to temporarily deactivate the WordPress Playground feature. This pause will provide an opportunity to address identified concerns and refine the feature. A detailed relaunch proposal, encompassing the insights from the community, should be crafted to ensure a more successful and well-received rollout in the future. This will build trust with the Plugin Extender ecosystem and demonstrate transparency that is so foundational to an open-source project. Also detailing the relaunch will foster further cross-team collaboration.

[brianhenryie]

direct users to the plugin configuration page if available

There is no convention for communicating a plugin's configuration page.

Different plugins redirect on activation in different ways. Some redirect no matter what, some check to see has a wp_option been set.

In general, this causes problems with bulk activation. I.e. when a plugin redirects on activation, it prevents the remaining plugins from activating. This applies equally to bulk activating plugins via WP CLI (because die() is usually called after wp_redirect()).

I think the practice of redirecting should be discouraged (outright forbidden by the review team) and the best practice should be an admin notice linking to the settings page (come to think of it, could be a plugin header read by core that works for Playground too).

[ibenic]

As others have stated, I am also for the "opt-in" approach.

For now, this could be done by having a tag "has-preview" in the readme file of the plugin.

My guess, this could be the fastest way to implement this and conditionally show the button.

For further implementation and enabling extensions to have previews (such as an add-on for WooCommerce), I'd propose an idea to think about and discuss:

As we have theme.json now, why wouldn't we try to have a plugin.json which could be used there or a playground.json.

In such json, we can define which plugins needs to be installed for this plugin to work and then also have a way to configure each plugin so that some installation wizards of other plugins won't be shown and such.

I do understand this is a complex thing to solve and that it would require some way of validating the data in such json so it might require lots of work.

But something to think about.

For now, the tag approach might work the best.

[BenSibley]

It stinks to work really hard on a plugin and then have some preview show up that makes it look totally broken when it's not.

This feature is a neat idea, but it needs a lot more work. We've gone decades without live previews; why was there suddenly a rush to launch this today when it's demonstrably unreliable?

As others have stated, this should be rolled back immediately and switched to an opt-in feature. Once it's rolled back, work on giving plugin devs information about how the preview works so we can decide if it's right for us or not. There is no rush to release this without proper communication and testing!

[afragen]

Replying to zodiac1978:

currently this won’t work for addon plugins

Could the plugin dependency feature maybe solve this?
​https://core.trac.wordpress.org/ticket/22316

cc: @afragen

Plugin Dependencies feature would make it so the dependent plugin could not be activated without the dependency installed and active first.

[tellyworth]

Add a button to the Advanced view allowing plugin committers to opt out of the Live Preview

[tellyworth]

In 12933:

Plugins: add opt-out toggle for Live Preview button

This allows plugin committers to disable the Live Preview button for specific plugins. It adds a button to the Danger Zone section on the Advanced view of the plugin page.

See #7251

[tellyworth]

Thanks for the feedback everyone! I didn't expect this would be controversial.

I've deployed a commit that adds an opt-out toggle so plugin committers can disable the Live Preview button. It's on the Advanced view, same place as the self-service buttons to close or transfer a plugin.

I want to note that this feature (and the opt-out) is simply for the Live Preview button which takes you to the Playground ​https://developer.wordpress.org/playground/. Playground has been live for some months now; if your plugin looks broken in Playground, it was broken before this ticket and it remains broken in Playground if you opt out of the Live Preview button.

I know the Playground team is hard at work on addressing bugs and compatibility issues there. And I intend to further improve the Live Preview support in the plugin directory to make things better for users and plugin developers alike. Many of your concerns can be addressed using Blueprints ​https://wordpress.github.io/wordpress-playground/blueprints-api/index which will allow configuring and installing dependencies, importing demo content, and other neat things. I'll work on making Blueprint support available as soon as I've confirmed some engineering details with the Playground team.

[bahia0019]

Sorry dude. This needs to be OPT-IN.
Setting it as opt-out puts the onus on all the developers who have ever published a plugin to:

1. Know about the change in the first place.
2. Log in.
3. Set the toggle.

Do you realize just how many people this will effect? Not to mention the huge impact that will have on the servers when they all clamor to turn this ish off.
No one was informed. There is no way for them to even know they have an option.

OPT-IN!!!

[bahia0019]

Replying to tellyworth:

I want to note that this feature (and the opt-out) is simply for the Live Preview button which takes you to the Playground.

And, fine Playground is online, and they have problems, and it's a work in progress.
But your feature unlocked the door for the entire public to just walk in and see that mess.
Don't try to downplay this. The button is the problem. Not the project in progress.

[ReneHermi]

@tellyworth thanks for the opt-out+ 1
I still vote for to making it opt-in until it is polished for the mentioned reasons above. Once it is polished it can still be default activated.

I also recommend to communicate this new feature to the plugin developers.

[tellyworth]

In 12934:

Plugins: remove Live Preview button

Remove the button for now.

See #7251.

[sephsekla]

This is unquestionably a really cool idea, and I can see it being really useful in future.

Like other commenters I think the rollout (not the feature itself) is the issue here. Opt-in absolutely is the way to go, at least for a lengthy grace period.

I'd also compare this to a new WP version release, where plugin devs have access to beta versions, field guides etc to make sure their plugin works smoothly long before the stable release. We should aim for the same level of prep before this is shown to end users.

[tellyworth]

Based on feedback, I’ve removed the button and we’ll revisit the idea later.

[ReneHermi]

@tellyworth Thanks for listening and the roll-back. Everyone, including me, who shouted so loudly should now help polish this feature and bring it out. At least now the playground has the attention it deserves:-)

[alanfuller]

100% agree with ReneHermi, and the idea is great, any help you need that I can give please ask.

[bahia0019]

@tellyworth Thank you.

I apologize if I came off as harsh. It wasn't meant to be personal.
There are ramifications that I don't believe were discussed before approving this feature. And I wanted to ensure the gravity of the situation was fully realized.

[zieladam]

Surfacing some of the conversation that happened on Twitter

​Igor Benić said:

A readme tag "has-preview" should be enough there to enable such a button.

A lot of plugins are extensions of other plugins so they won't work out of the box.

Yep, and with a "plugin.json", you can define the configuration of such so installation wizards and similar are skipped (at least for other plugins).

​Katie Keith said:

it could install WooCommerce on the preview of plugins which are WooCommerce extensions.

​Aditya R Sharma said

They should allow plugin authors to upload custom url for live preview button so that we can use url parameters to install dependency like - ?plugin=elementor&plugin=elementor-addon-namr&theme=hello

​Milan Petrovic said

I have plugins for bbPress; if you run preview, nothing happens since bbPress is missing. Even if bbPress is active, it is empty, there is nothing to show. Without plugin requirements, Preview can't install required plugins. Without demo data, users have nothing to see.

---

To add to that – Playground, the library, has support for multiple plugins and demo data. Sounds like making these features available in live previews is a must-have for many plugins.

[homescript]

It sounds like a great idea, if there is a way to pick the dependencies for the plugin before running the link preview, it will be great too.

[webdevmattcrom]

Thank you @tellyworth and the Playground team for listening and acting quickly on the rollback. I agree 100% with @ReneHermi that I and others will be supportive and helpful (as much as my capacity allows) to help see this feature brought back with tons more confidence. Thank you!

[carlosmoreirapt]

This needs to be opt-in, even in the future when it's matured. There are just so many variables and different ways a plugin could work that it doesn't make sense to be there by default. Still, a great feature that I would like to see in the repo for sure!

[BenSibley]

Thank you for quickly rolling back the button. This will be a great addition to the repo now that we have time to prepare and test our live demos before making them accessible to users.

[dmsnell]

What fun and challenge here. This stuff is hard, and thanks everyone for both making this possible and for everyone who highlighted its impact on yourselves and others.

@tellyworth I wonder if we could look for something like registry-preview-blueprints.json in a plugin’s root dir, and if it exists, link it to the button. That way, there’s no need to toggle a setting in an admin panel; the opt-in is someone choosing how they want to present their plugin. What do you all think about that idea?

Obviously there’s much work to do to dynamically load PHP extensions and button up the missing functionality around networking, but blueprints can do so much today and I think we could definitely make up some guides to demonstrate how to prepare a plugin for its preview/display.

For everyone sharing their support while sharing their critiques; thank you so much. Sometimes discussions online get so nasty, and it’s refreshing to read people who are upset but still understanding and encouraging.

[alanfuller]

I would like to say, that I was only passingly aware of playground, it was something I put on the back burner of my mind to deal with another day. I had always thought about using one of the 'spin-up' services in my readme for a demo, but other priorities took precedence.

So the brilliant thing, is this recent issue had brought playground to the foreground and now there is collective community engagement.

So having known close to nothing I was unaware of blueprints until I looked it up just now ( link to examples ​https://wordpress.github.io/wordpress-playground/blueprints-api/examples )

and I think that having plugin devs opt-in with a blueprint json is a fantastic idea.

I think you could look for it in the /assets folder ( where icon / banners are ) to keep it specific to the repo

[maartenbelmans]

Replying to dmsnell:

What fun and challenge here. This stuff is hard, and thanks everyone for both making this possible and for everyone who highlighted its impact on yourselves and others.

@tellyworth I wonder if we could look for something like registry-preview-blueprints.json in a plugin’s root dir, and if it exists, link it to the button. That way, there’s no need to toggle a setting in an admin panel; the opt-in is someone choosing how they want to present their plugin. What do you all think about that idea?

My concern is: do we want to load the admin plugin screen if someone clicks “Live Preview”. Most plugins are front-facing and users may expect a demo page showcasing the plugin’s capabilities rather than the WP admin. If we go through with this idea, I think it would be great if plugin authors can decide which URL goes behind the button. It could be the playground, but also a privately hosted demo site (like many plugins already link to in the description).

[alanfuller]

@maartenbelmans

That is exactly the problem solved by blueprints, a simple configuration would fire a 'live demo' rather than wp admin ​https://wordpress.github.io/wordpress-playground/blueprints-api/examples/#showcase-a-product-demo

Sure there would be work for plugin devs that dont have suitable live demos but the tools are there.

[vapvarun]

Thank you for quickly reversing the Live Preview button.

Would it be possible to have the option to opt in or opt out of this feature? It would be greatly appreciated.

Install required plugins together. For example, BuddyPress add-ons require BuddyPress to be installed.

My most of plugins are an addon for BuddyPress and they will not be functional if BuddyPress is not enabled and even if those components are not enabled

Eg. BuddyPress Group Review will not work unless the BuddyPress Group Component is enabled, just installing BuddyPress will not be enough.

[tellyworth]

Replying to dmsnell:

@tellyworth I wonder if we could look for something like registry-preview-blueprints.json in a plugin’s root dir

This is roughly what I intended to do next (though I was thinking of storing it in the plugin assets folder). It could also potentially allow for assets like WXR files to be used by the blueprint, though that might need some minor additions to the Playground proxy code to support it.

[jeffparker]

@tellyworth Can there be a way to enable 3rd party API calls? For example, Jetpack plugin needs to make a 3rd party call to setup. Currently, it doesn't appear to be able to setup in Playground.

[tellyworth]

Replying to Otto42:

Add nostats=1 to the URL to not count in downloads.

I checked with the Playground devs and it looks like this is unnecessary; the existing server-side code will already be defaulting these requests to nostats=1, so none of it will have been counted in stats. They'll probably add the explicit query string anyway just to be clear about it.

[tellyworth]

Replying to jeffparker:

@tellyworth Can there be a way to enable 3rd party API calls? For example, Jetpack plugin needs to make a 3rd party call to setup. Currently, it doesn't appear to be able to setup in Playground.

There are two parts to this.

One, there is an ongoing issue about supporting network connections in Playground: ​https://github.com/WordPress/wordpress-playground/issues/85

Two, there's the question of how plugins that require network access should present themselves to the user when newly installed. My sense is that this needs to be solved with a combination of things:

• Blueprint support should allow configuring ready-to-go demo content in live previews based on Playground.
• Plugins ought to gracefully degrade in a situation where an external network or API is unavailable. (This goes beyond Playground: people test plugins locally and on staging sites; and even in prod network connectivity may be limited or lost at times)

[alanfuller]

Replying to tellyworth:

Replying to jeffparker:

Two, there's the question of how plugins that require network access should present themselves to the user when newly installed. My sense is that this needs to be solved with a combination of things:

• Blueprint support should allow configuring ready-to-go demo content in live previews based on Playground.
• Plugins ought to gracefully degrade in a situation where an external network or API is unavailable. (This goes beyond Playground: people test plugins locally and on staging sites; and even in prod network connectivity may be limited or lost at times)

Whilst graceful handling of missing connections and demo content may work for some, there is a subset of plugins, small that may be, that the real value of a demo is in the ability for the user to their own live content. An example would be say a feed from a closed system via API. For these plugins a network connection is essential to showcase in context of the user. ( disclosure, one of my plugins is such and the live demo connecting to user data is very popular when users evaluate it )

In these cases, hopefully the network issue gets resolved, the github thread seem it was progressing not a 'no'.

Until networking is resolved an ability to selectively replace the 'Live Preview' with a 'Try on Demo Site' would be the best solution.

[zieladam]

I just added ​Playground support for additional PHP extensions: mbstring, iconv, gd, and the XML ones (libxml, xml, domdocument, simplexml, xmlreader, xmlwriter).

They can be enabled:

• With a checkbox on playground.wordpress.net,
• With a query param ?php-extension-bundle=kitchen-sink
• Via the new Blueprint option "phpExtensionBundles": [ "kitchen-sink" ]

This will help Playground support significantly more plugins. Please report any issues in ​WordPress Playground repo. Also, if your plugin needs any PHP extension that isn't currently supported please open an issue in the Playground repo.

[tellyworth]

In 12976:

Plugins: add Test Preview button.

This is only visible to plugin committers. See for details: ​https://make.wordpress.org/meta/2023/11/22/plugin-directory-preview-button-revisited/

See #7251.

[tellyworth]

In 12979:

Plugin preview: special handling for Akismet

Don't force an install step for akismet, since the plugin is bundled with WordPress.

See #7251

[tellyworth]

In 12998:

Plugins API: add a new endpoint for blueprints.

See #7251

[tellyworth]

In 12999:

Plugins: improved Test Preview button

This uses the new Playground blueprint-url param to pass the blueprint rather than a URL fragment.

Also, opens the preview in a new tab, as per suggestions.

See #7251.

[tellyworth]

In 13018:

Plugin Directory: fix empty blueprint postmeta

See #7251.

[tellyworth]

In 13019:

Plugin Directory: fix _doing_it_wrong in blueprint API

Missed permission_callback.

Props dd32.
See #7251.

[tellyworth]

In 13036:

Plugin directory: add blueprints field to api

Related r13035

See #7251.

[tellyworth]

In 13037:

Plugin directory: endpoint to toggle preview visibility

See #7251.

[tellyworth]

In 13038:

Plugin directory: add blueprints to fields list

Default is false.

See #7251.

[tellyworth]

In 13039:

Plugin Directory: use numeric keys for blueprints field

Per feedback.
See #7251.

[tellyworth]

In 13040:

Plugin directory: add committer button to enable previews

This adds a button to the Advanced view that will allow a plugin committer to enable or disable the Live Preview button for public users.

A valid blueprint.json file must be present in the plugin's assets/blueprints/ folder in its svn repo.

See #7251.

[mujuonly]

When enabling, it shows an empty alert box.

[tellyworth]

In 13046:

Plugin Directory: fix confirmation dialog for preview toggle

Props mujuonly.
See #7251.

[10up]

Committer view showing Live Preview button instead of Test Preview

[10up]

Committer view showing Live Preview disabled, so button should say Test Preview

[JeffPaul]

In working to set this up on ​Ad Refresh Control, I noticed that when logged in as a committer the button says Live Preview instead of Test Preview .

I believe ​our blueprint is correctly formed so seems that the Test vs. Live Preview button rendering is a bit off?

[tellyworth]

In 13061:

Plugin Directory: fix button text for Test Preview

Props @jeffpaul.
See #7251.

[JeffPaul]

Confirming after that update @tellyworth that the committer-only button said Test Preview and after enabling the live preview the logged out, logged in non-committer & committer views the button correctly says Live Preview.

[tellyworth]

Thanks Jeff! You were right, it was just a logic error in the button labeling.

[tellyworth]

In 13078:

Plugin Directory: include preview_link in API results

This adds a preview_link property to plugin API results, which contains a link to a Playground preview for plugins where available.

The link is only set when the plugin developer has enabled public previews and provided a blueprint.json file.

See #7251.

[tellyworth]

In 13079:

Plugin Directory: preview_link api property off by default

See #7251

[tellyworth]

In 13091:

Plugin Directory: include preview link in plugin info API

See #7251.

[tellyworth]

In 13189:

Plugin Directory: change CORS header to *

Seems like this is safe to do, and allows easier development of further Playground improvements.

See #7251.

[dd32]

I'm going to mark this as fixed, any enhancements / bugs should go into new tickets at this point.

If anything above has been missed, please file it as a new ticket.