You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
What alternatives have you considered?
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered:
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).
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.
What alternatives have you considered?
No response
Additional Context
No response
The text was updated successfully, but these errors were encountered: