wbrowar
commented
3 years ago I was looking into how to set up a controller to fire a webhook’s request from a custom module (or a PR here) and it looks like because Webhooks is driven by events, the processing that happens in Webhook’s event handler factors in the event sender’s attributes. Could the stuff in the event handler be abstracted out so that the sender info is only needed when sending a request is done by an event?
I think a good way to handle this would be to be able to get a webhook by it's ID and then do something like $webhook->triggerRequest(). In this case, the webhook could ignore checking in to see if an element meets the filter criteria because we're manually triggering the event and we can assume that filtering isn't applicable.
Description
As we're doing more work on Jamstack sites and projects that use webhooks as part of a build process I'm finding it more necessary to give authors the option on when webhooks are fired. Instead of writing custom modules or looking at some of the hosting provider-specific options, it would be great to have a first-party UI trigger that can fire off an existing webhook.
This could benefit authors who prefer to manually trigger a build after making several changes and proving them in Live Preview.
An unofficial deploy trigger plugin is available to look at as a model: https://github.com/workingconcept/trigger-craft-plugin
While this plugin provides a deployment button in a widget, having something more accessible, like in the edit page sidebar or the main CP sidebar, may be even more convenient for authors.
Cheers, Will