Webhooks are inherently complicated to set up - even more so in BricksForge than competing solutions. Ideally, native support for JetEngine CCT via native actions and hooks would lead to an influx of sales. It wouldn’t be wasted time by the developer.
It's interesting that Webhooks are perceived as complicated. In reality, the Webhook action in Bricksforge Pro Forms is intentionally kept as simple and lean as possible – just a few fields, and you're good to go. In most cases, it really takes less than a minute to set up.
Of course, depending on the external system you're trying to connect to, the complexity can lie in understanding the API you're working with – not necessarily in Bricksforge itself. That's something worth keeping in mind 😉
Regarding JetEngine CCTs: a native action could indeed provide a more streamlined experience for those specific use cases. We'll definitely keep an eye on that. Currently, there is just a lot of higher priority stuff to do :)
Once you’ve used tools that set the standard for web hooks and http requests like n8n/make etc, anything less from a user facing workflow perspective is inconvenient and/or potentially unsafe. BricksForge has always appealed to me for its polish but ProForms and the actions are imo the least polished features of BricksForge. Building headers and auth in the Bricks editor? Sure, the simplest implementation of web hooks I’ve ever seen. But I wouldn’t call it the easiest or most secure approach when dealing with client sites connecting to third party tools. I know you’ve got a lot on but seeing a reply to this before acknowledgement of reported bugs affecting production sites is disheartening. If it’s money you need to expand your team, any native integration with JetEngine will land you a tonne of Crocoblock customers who are dying to get away from JetFormBuilder.
I understand you. But you still have to consider that we are still in a Bricks environment and that elements like Pro Forms are bound to their native controls. Bricks does not allow developers to create their own controls. Therefore, there is no way to create polished n8n like workflows inside Bricks. We want to remain as native as possible.
Nevertheless, there are plans to integrate Pro Forms-related actions into the Node Editor. That would at least make this part a little more attractive to use
I would like to clarify, I wasn’t referencing the node-like aspect of n8n/make, I was referring to the standardized approach with field names, presented in a logical order, with guard rails and credential management. I think all of those things are possible without going down the path of building them into the node editor.
I come from an ECM background so I know the potential the node designer could bring to market. I know it is tempting. But content management is key, and JetEngine CCT and Query Builder are letting people build fully fledged SaaS apps using Wordpress without any of the CPT overhead.
The funny thing is, JetFormBuilder makes it incredibly difficult to build anything that looks half decent. There’s also no workflow engine behind it, so you can’t perform chained events without writing PHP.
You understanding of form design and feature set are incredible. The upload field alone proves that you actually care about the end-user experience.
Tie that with real CRUD like JetEngine CCT (or hint hint, BricksForge CCT) and BricksForge Query Builder… and now I don’t need JetEngine at all.