search

craftcms / webhooks

Plugin for integrating Craft with Zapier and IFTTT.
https://plugins.craftcms.com/webhooks
MIT License
84 stars 12 forks source link

Advice on configuration for static site generation #29

Closed weotch closed 4 years ago

weotch commented 4 years ago

I was hoping to get some advice on how to best use webhooks to trigger a new static build at Netlify whenever content changes. I'm coming from a Contentful background where my configuration looks like this:

Screen Shot 2020-04-22 at 4 49 56 PM

I want to trigger a rebuild on any change of content, whether it's a creating a new entry, an update, a bulk change, a re-order in a list, a change of publish status, a delete, etc. The only thing I don't want to trigger the webhook for is changes to drafts, autosaves, or non-enabled entries; essentially anything that isn't ready for production.

  1. Is there a single "Sender Class" and "Event Name" that captures all of that?
  2. What should the Event Filters be set to?

I think this is useful for anyone using Craft headlessly with a static site generator.

Thanks!

brandonkelly commented 4 years ago

You would need to set this up as two separate webhooks – one for element saves, and one for deletes.

Both of them could use the craft\base\Element class, and the event names would be afterSave and afterDelete.

weotch commented 4 years ago

Thanks! And would these be all just up the middle? It's been unclear to me what the 3 statuses mean.

Screen Shot 2020-06-18 at 12 51 09 PM

brandonkelly commented 4 years ago

That’s explained here: https://github.com/craftcms/webhooks#filtering-events

The only thing I don't want to trigger the webhook for is changes to drafts, autosaves, or non-enabled entries; essentially anything that isn't ready for production.

So in your case you’d want to set the filters up like so:

An example Event Filters setting

In other words, only trigger the webhook when all of the following are true:

Note that the “Element is enabled” filter was just added in v2.3.1, so you will need to update to get access to that.

Assuming no actual element info is needed to be sent along with the webhook, you should give each of your webhooks a Debouncing Key Format of something like element, so that multiple element saves in the same request don’t result in multiple webhook requests.

weotch commented 4 years ago

Ha it really was just added, wasn't it? Thanks!!