-
Notifications
You must be signed in to change notification settings - Fork 2
feat: webhooks plugin core registration api #193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One small thing is I did try and test the snippet in your PR and I got the following error:
Not sure if I was missing anything but the plugin was installed (symlinked from this PR) |
@colinmurphy that is strange as I copied those to the same location and does not have any issues can you try using the https://wordpress.org/plugins/code-snippets/ plugin |
* | ||
* @internal | ||
*/ | ||
class Autoloader { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be great for the team to discuss and find the common solution/way for the autoloading for our new plugins. And use unified for all new plugins.
/** | ||
* Register the webhook CPT | ||
*/ | ||
public function register_webhook_cpt(): void { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe there is a benefit to have Post registration functionality separately, in a separate class?
Also can we discuss what benefits we have when utilizing it as a Post Type vs Options/Settings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @whoami-pwd . I will refactor. After discussion with @josephfusco I think using CPT provides several benefics over settings:
CPTs provide built-in admin UI, revision history, meta fields per webhook, and native REST/GraphQL integration. We can create multiple hooks as a separate database entry rather than bloating a single serialized options array. The CPT structure also enables more granular permissions as well. So Im not sure how scalable the Options/Settings variant will be in that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@theodesp LGTM 🚀 🚀 🚀
The merge-base changed after approval.
@@ -0,0 +1,64 @@ | |||
<?php |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Separated this in a new class
Description
This PR introduces the core Webhooks Registration API for WPGraphQL Headless Webhooks. It provides the
WebhookRegistry
singleton class responsible for managing webhook types and webhook instances as a custom post type (graphql_webhook
). The API includes functions to register webhook types (register_webhook_type
), create webhook instances (create_webhook
), and retrieve registered webhook types (get_webhook_type
,get_webhook_types
).Related Issue
#164
Dependant PRs
Type of Change
How Has This Been Tested?
graphql_register_webhooks
hook.Screenshots
Checklist
#Testing snippet
Use this snippet to test the code: