Show the themes and plugins that are causing AMP validation errors within the block editor sidebar

[jwold]

Feature description

This expands on our work in #3821 and relates to #4668.

Acceptance Criteria

• When users open the AMP sidebar within the Block Editor, they should be able to see a list of any themes and plugins that are causing validation errors.
• When DevTools are turned off this list should be the only thing that appears in the AMP sidebar
• When DevTools are turned on users should be able to filter the errors via their themes and plugins. This could be via a separate list, or incorporated into the list (preferred)
• Each theme or plugin should include a link to the relative developer support site

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

Implementation brief

QA testing instructions

Demo

Changelog entry

[jwold]

@westonruter and @johnwatkins0 I've created this new ticket for the discussion from: #3821 (comment)

[jwold]

Here's a first draft for what the interface could look like when logged in with DevTools turned off.

I'm not sure about when they're turned on. Any thoughts on how we might integrate the list with the current validation errors? Perhaps just walking through the proposed experience would be helpful.

[westonruter]

@jwold I was thinking of it basically augmenting what @johnwatkins0 has here in #5589:

Above the "Validation Errors" section there could be two new ones for "Incompatible Themes" and "Incompatible Plugins". Or rather, instead of "Validation Errors" that section could be renamed to be just "Compatibility Issues", and then there could be the list of themes/plugins, and then following that the list of the individual validation errors. (Possibly clicking a theme or plugin could serve as a filter to limit the validation errors that appear below.) As discussed in #3821 (comment), if the user has DevTools turned off, the list of validation errors could be hidden by default behind a button.

[jwold]

This captures most of what was outlined above, and in #3821.

It's a bit clunky, but worth discussing.

[westonruter]

I feel good about the iterations on this as discussed over VC.

[johnwatkins0]

Proposing an approach. This applies to plugins but probably works similarly with themes.

When the AMP plugin finds a validation error associated with a plugin it has not encountered before, we will:

1. Make a request to plugins_api using the plugin slug:

plugins_api(
	'plugin_information',
	[
		'slug'   => 'jetpack',
		'fields' => [
			'icons' => true, // Returns icons associated with the plugin.
		],
	]
);

If the plugins_api response is valid, we know it is a plugin available on wordpress.org and that its support URL is https://wordpress.org/support/plugins/[plugin-slug]/. (Is this always the case? Are there plugins on wordpress.org whose support URLs don't match this pattern?)

2. If the plugins_api response is a WP_Error (as is the case when the requested plugin is not on wordpress.org), we fall back to the PluginURI in the plugin data if it exists. If it doesn't exist, then we use the AuthorURI. If that doesn't exist, we give up and can't provide a link for the plugin.

3. Cache this data (it can probably be cached a long time) and make it available to the block validation editor script.

Icons

While we're using plugins_api: some versions of @jwold's designs for this sidebar included icons for the plugins causing validation errors -- e.g.:

We are not including plugin icons in the initial iteration of the editor sidebar (see #5589) because we would need to use plugins_api to get them. But now, since we'll be using plugins_api to get support links, we can go ahead and fetch the icons (they must be requested via the fields arg as shown in the snippet above) and cached along with the support link.

[westonruter]

1. If the plugins_api response is valid, we know it is a plugin available on wordpress.org and that its support URL is https://wordpress.org/support/plugins/[plugin-slug]/. (Is this always the case? Are there plugins on wordpress.org whose support URLs don't match this pattern?)

Yes, that should always be the case.

2. If the plugins_api response is a WP_Error (as is the case when the requested plugin is not on wordpress.org), we fall back to the PluginURI in the plugin data if it exists. If it doesn't exist, then we use the AuthorURI. If that doesn't exist, we give up and can't provide a link for the plugin.

Perfect.

3. Cache this data (it can probably be cached a long time) and make it available to the block validation editor script.

Yes, it could probably be cached for a year, in the case of a non-error response to plugins_api(). If there is an error (due to the plugin not existing not due to a network error), then no request would be made since it is in the plugin metadata on disk. I suppose caching the successful response could be a year and a non-successful response (due to the plugin not being there) could be a month. But that's probably overkill. A year seems good in general.

But now, since we'll be using plugins_api to get support links, we can go ahead and fetch the icons (they must be requested via the fields arg as shown in the snippet above) and cached along with the support link.

Great!