WPGraphQL Extensions Page

[jasonbahl]

What problem does this address?

As a WPGraphQL maintainer I often have to manually redirect folks to extensions that can help solve problems they're running into.

As a WPGraphQL maintainer I would like to maintain different functionality (i.e. the GraphiQL IDE) as a different plugin that can be updated independent from the core WPGraphQL plugin, and want to easily surface the plugin for users (possibly even auto install it or have UIs that highly recommend installing it for new installs?)

As a WPGraphQL user I have to search for existing plugins that might bridge WPGraphQL with another plugin I'm using (i.e. WPGraphQL for ACF) and vet the solutions (i.e. compare WPGraphQL Content Blocks vs WPGraphQL for Gutenberg vs other plugins in the block editor domain).

As a WPGraphQL Extension Author it's hard for me to surface my plugin for WPGraphQL users and indicate what version(s) of WPGraphQL it's compatible with, etc.

What is your proposed solution?

I propose that WPGraphQL adds an "Extensions" page in the WordPress dashboard (similar to WooCommerce, etc) that would allow WPGraphQL extensions to be surfaced in the WordPress admin in a uniform way.

Extensions could be installed and activated from this screen, update notifications, etc could be centralized, and common things like logic around auto-update semver checks could be centralized.

I think there should be some sort of formal "registry" within WPGraphQL that lists all the extension plugins and meta such as "tags" / "documentation urls", etc.

Acceptance Criteria

• An "Extensions" menu item is added under the WPGraphQL menu in the WordPress admin dashboard.
• The Extensions page displays a list of available WPGraphQL extensions.
• Each extension listing includes the following details, displayed in a card layout (similar to the Performance Lab plugin)
  • Extension/Plugin Name
  • Short description
  • Version (maybe)
  • Extension specific support link (even if it opens a modal)
  • Plugins from wp.org can be inline activated
  • Plugins from GitHub need to be linked with instructions (no standards)
  • Support Link CTA

[justlevine]

TL;DR from yesterday's Open Hours:

• There is definitely a huge ecosystem around this, where many WPGraphQL extensions can't or won't be listed in the .org Plugin Directory.
• More work than the actual code mechanism is creating a discovery/submission policy that is both transparent and maintainable. E.g. (non exhaustive):
  • Do we limit first to plugins hosted on @wp-graphql, and if so where does that leave essential ecosystem plugins (e.g. WPGraphQL Content Blocks)?
  • Are directory submissions handled via the website or committed to the plugin?
  • Are the extensions themselves reviewed by any metric? (even base compatibility)
  • How do we handle discovery? E.g. It's easy to suggest the yoast/rank math specific extension if a parent plugin is installed, but what if there's a new extension that supports both plugins?
• This is an additive feature, so there is no reason to explicitly milestone it for v2.0 Roadmapping #3081 (let alone hold up the release).

[josephfusco]

Do we limit first to plugins hosted on https://github.com/wp-graphql, and if so where does that leave essential ecosystem plugins (e.g. WPGraphQL Content Blocks)?

Here is a list of the proposed initial plugins/modules, with the thought that the author/maintainer name would be displayed in the card along with a support link. This would handle both WordPress.org hosted plugins, as well as GitHub hosted plugins.

• WPGraphQL for ACF
• WPGraphQL Smart Cache
• WPGraphQL for WooCommerce
• WPGraphQL Content Blocks
• WPGraphQL IDE - (looking to submit to WordPress.org, matching the gutenberg pattern where activating the dedicated plugin would provide features in development)

Are directory submissions handled via the website or committed to the plugin?

Opening a pull request would be preferred but initial thought is that this might be something like a filterable array of keys other plugins could add themselves to.

Are the extensions themselves reviewed by any metric? (even base compatibility)

We'd like them to be, but otherwise TBD.

How do we handle discovery? E.g. It's easy to suggest the yoast/rank math specific extension if a parent plugin is installed, but what if there's a new extension that supports both plugins?

TBD

[justlevine]

Here is a list of the proposed initial plugins/modules, with the thought that the author/maintainer name would be displayed in the card along with a support link. This would handle both WordPress.org hosted plugins, as well as GitHub hosted plugins.

• WPGraphQL for ACF
• WPGraphQL Smart Cache
• WPGraphQL for WooCommerce
• WPGraphQL Content Blocks
• WPGraphQL IDE - (looking to submit to WordPress.org, matching the gutenberg pattern where activating the dedicated plugin would provide features in development)

[...]

Are the extensions themselves reviewed by any metric? (even base compatibility)

We'd like them to be, but otherwise TBD.

If we can't MVP with review transparency, then I think we need to MVP with criteria consistency. WPGraphQL Content Blocks being on here, while other 3rd party extensions are not (including those hosted on .org, or in a significantly more stable point in their lifecycle), gives me A8C vibes.

Would recommend launching with plugins "curated" from the wp-graphql org, and waiting to add Content Blocks once there's a formal submission process + approval criteria that is open to all.

Are directory submissions handled via the website or committed to the plugin?

Opening a pull request would be preferred but initial thought is that this might be something like a filterable array of keys other plugins could add themselves to.

100% I agree it should be filterable. The question that needs answering is whether a new release is required to get updates (if its stored inside the plugin), versus served as a payload as soon as a new plugin is "approved" (if we're using PRs, they'd just be to the website repo or a new one).

[jasonbahl]

criteria consistency

Yes, I think we need to pin this down.

I think for me the important things to "require" are:

• Plugin Name
• Short description
• Author / Maintainer
  • This will help users identify authors they're familiar with
• Plugin link (either .org or elsewhere)
  • .org plugins could be installed and activated in the UI and external could be linked to in a new tab.
  • the install functionality could be filtered to allow folks to install from Github or elsewhere if they chose to support that, but only .org installs would be natively supported
• Link to get more info (this could open the README in a modal for WordPress.org plugins, or link externally for plugins that are not on .org)
• Support link (💯 required): Where can users get support for this particular plugin. I don't want folks thinking any plugin on this page should be supported by opening a Github issue on the WordPress.org support forum for WPGraphQL or on the main wp-graphql Github repo.

There are a few goals we need to accomplish with this feature:

• Surface plugins for end users
  • Allow them to make informed decisions on the extension(s) to use
• Allow extension authors to get more exposure for their plugins
• Keep the maintenance/support burden minimal for core maintainers
• Direct support for each extension to the proper places