WebHooks Module

[jrestall]

Hi,

I've created a WebHooks module, are you interested in this being part of the core project? It works really well alongside the GraphQL/decoupled CMS functionality.

It allows users to trigger functionality on external sites (e.g. Netlify, Discord, Twilio, MailGun etc) when events occur within the CMS. I've tried to make the events extensible so that we could add more in the future.

Here's some screenshots to give you an idea of the functionality:

Appreciate any feedback on the code/functionality.

[giannik]

Cool stuff!!

[Jetski5822]

Yes!

…

Sent from my iPhone

On 4 Sep 2018, at 07:50, yiannis kyriazidis ***@***.***> wrote: Cool stuff!! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[agriffard]

@jrestall Do you want to make a demo during the Orchard weekly meeting? Today at 12:00 PST .

[jrestall]

Thanks @giannik and @Jetski5822!
I appreciate the offer @agriffard, I'd be happy to demo the module at the meeting, 7am NZT will work well for me before work.

I've fixed the failing Linux unit test.

There's one item I'd like to fix if anyone can help. I can't reference HttpClientHandler.DangerousAcceptAnyServerCertificateValidator from my module. Is it because it's not in the netstandard2.0 spec or some other reason?

// TODO: Why won't DangerousAcceptAnyServerCertificateValidator resolve - Need for Linux/MACOS support.  
//ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator

[sebastienros]

That really nice, and I would have thought someone would have said it before me, but why not make them Workflow activities instead? We could trigger them in many more ways than just content events, and it could also integrate with other external webhooks. You wouldn't lose anything, and just have less code to maintain IMO.

[giannik]

From a marketing standpoint I think adding out of the box Web Hooks will make Orchard more appealing , even though you can do this and more complex scenarios in workflows.

…

On Tue, Sep 4, 2018 at 7:31 PM Sébastien Ros ***@***.***> wrote: That really nice, and I would have thought someone would have said it before me, but why not make them Workflow activities instead? We could trigger them in many more ways than just content events, and it could also integrate with other external webhooks. You wouldn't lose anything, and just have less code to maintain IMO. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2323 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABcltS_3fmmzwq_-stuhZk-nBbe2LH24ks5uXqr6gaJpZM4WYYrK> .

[jrestall]

Hi @sebastienros,

Thanks for the feedback here and on the call, I agree integrating webhooks with workflow would be very powerful and help reduce code duplication, especially around defining, selecting and triggering events.

I considered it originally but wanted to prioritize the user experience of the module by having a really simple and clean UI for adding webhooks. I envision a headless CMS recipe for Orchard in the future and want a core feature such as webhooks to be as easy as possible to configure, so no creating workflows or connecting activities for the common use case.

I agree whilst the UX is good, it would be really nice to have workflows drive the triggering and activities. I only want the best to go into Orchard as a core module so perhaps we put this on NuGet for others to use until enhancements such as below are made?

• Create a 'Send Webhook' Workflow Task. Inherit the 'HTTP Request' Task?
• Modify Create Webhook page to reuse the 'Send Webhook' task and reuse the events selection dialog from the workflow module. Triggers section changes to list the start activities in the workflow. Have it create the workflow automatically.
• Change Webhook Index page to list webhook workflow types
• Change Webhook Edit page to have an advanced link to the full workflow editor.

Unfortunately I can't commit to working on these enhancements right now. My focus is switching to GraphQL parts/fields support as it's needed for my headless work and the webhook module meets my immediate needs of publishing a static site to Netlify on content changes. If I get time I can look at implementing the enhancements or others can contribute.

[sebastienros]

Please make it a module in the gallery in the meantime. And please give us a demo of how you are building the site with Netlify when you are done. We need a blog post showing this off.

It doesn't look like the editor is actually much different than the default HTTP Request workflow task, or is it? What is missing in the task compared to your screen?

My idea is that we could pretty easily create a scaffolded workflow type from such a screen, but we maybe miss some metadata and services in the workflow to filter them out so they are not directly visible in the workflow screens (or under a specific mode with permissions).

The same way I like the content event matrix, which itself could too be a custom task.

Someone should definitely reuse your UI and improve on the current tasks as a first step. I really like the attention to details, and the effort you put in the user experience.

[jrestall]

Thanks @sebastienros , I'll definitely demo the ReactJS/Headless Orchard/GraphQL/GatsbyJS/Netlify setup if it all comes together.

Yea the editor is basically the same expect for the liquid variables available within it (Webhook, EventName, ContentItem). There's also the help text above fields and hint text under each field that is specific to helping with the Webhooks inputs and examples. It would be nice to support that without duplicating everything else HTTP Request task does.

Closing this pull request now, thanks everyone for your inputs.

[Skrypt]

Moved to jrestall/modules/webhooks