Context Navigation

← Previous Ticket
Next Ticket →

#7380 closed enhancement (fixed)

Allow plugin reviewers to test newly submitted plugins in Playground

Reported by:	tellyworth	Owned by:	dd32
Milestone:		Priority:	normal
Component:	Plugin Directory	Keywords:	has-patch
Cc:

Description

Currently, the Live Preview button in the Plugin Directory is only available for published plugins.

It would be helpful if the plugin moderation team had an easy way to preview and test plugins that have been submitted to the Directory but not yet published.

This requires a few moving parts:

A mechanism to generate Blueprints specially for plugin reviewers
CORS headers to allow Playground to fetch uploaded plugin zip files (since unpublished plugins are not available from downloads.w.org)
Preview links in the queue admin pages

Change History (14)

This ticket was mentioned in PR #184 on WordPress/wordpress.org by @tellyworth.

9 months ago #1

Keywords has-patch added

This adds a link with corresponding REST APIs to allow plugin reviewers to easily preview a pending/new plugin that has not yet been published.

Note that in this initial version the REST APIs are not authenticated, since Playground does not pass auth cookies back to the API when fetching blueprints and zip files.

https://meta.trac.wordpress.org/ticket/7380

#2 @tellyworth
9 months ago

P.S. There's an additional change to some closed-source code that adds CORS headers to the zip file.

#3 @tellyworth
9 months ago

In 13076:

Plugin Dir: Add Preview links for moderators in plugin queue

This adds private Playground Preview links for the plugin review team to more easily test newly submitted plugins that have not yet been published.

Plugins are loaded with plugin-check active.

See #7380.

#4 @bordoni
9 months ago

It would be a super cool idea to load Dependencies, for now Woocommerce is one of the few plugins that has declarative dependencies we can rely on, so it would be worth using:

WC requires at least: 7.1
WC tested up to: 8.2.2

From the main plugin php file to determine which version of Woo we should install with this.

#5 @bordoni
9 months ago

Also making sure the plugins are not active by default would help a ton, cause some times the plugins will throw warnings and fatals, preventing us from using PCP and other tools to give developers more info on their plugin.

Letting the reviewer activate the plugin manually allows us see those in a more "normal" workflow.

#6 @tellyworth
9 months ago

I can see there being times when active by default is helpful or unhelpful depending on the context. If I want to demonstrate a plugin bug to someone, it'd be much better for the plugin to be active, since I can just share the link and don't have to instruct them to activate the plugin. With that in mind:

What if there were several preview links for different purposes? For example:

A 'PCP' link that runs Playground with the user plugin inactive, and lands on /wp-admin/tools.php?page=plugin-check
A 'test' link that runs with the plugin active and no PCP (but maybe other tools activated?)
A 'test with dependencies' link that runs with deps like WC installed as well
..etc

#7 @tellyworth
9 months ago

Re WooCommerce and other dependencies: I think the right way to do this would be to support the RequiresPlugins header (see #6921).

#8 @dd32
9 months ago

Re WooCommerce and other dependencies:

I agree, but I think there's a middle-ground here - If we can reasonably infer that a plugin likely requires something (WooCommerce, BuddyPress, bbPress, etc) installing it for the reviewer but deactivated could be an option.

The other option is that we could also install a "reviewer tools" plugin (which PCP isn't necesarily) which infers those things and presents an admin notice to the effect of "This plugin appears to support X, <install it>".

#9 @tellyworth
9 months ago

Yeah I like that idea Dion. Should be easy enough to handle that in the blueprint api endpoint - if the plugin name includes "for woo" or "for buddypress" then install that as a dependency.