I just requested access to the integrations documents at Google Docs. I use the domain SnkMail.com (awesome service) for such things ... Without anoth...

I think I commented on that during the alpha/beta. There's a popup for each single value. Really? I think they were experimenting with that paradigm, ...

Thanks @hendrawan.kuncoro. Yes, it makes sense that the hidden values are those that were added to the form. Going back and looking at my form model I...

To recap for anyone who is curious: My immediate drive on this is to get form data from logged-in users (Applicants), have staff review it and kick it...

RE the API and other coded access into the plugin internals... 1) As I'm writing code, I'm finding that most of my requests so far are going through t...

This message appears in the debug.log whenever some other non-related error is logged. [Forminator] ["[ADDON]","Forminator_Addon_Zapier::is_form_conne...

Still working my way through coding with the latest version. I've shared my progress in my Formination Project thread. This takes you to today's updat...

Sharing some progress with Forminator v1.2. I've moved all Forminator functionality into a new plugin which will get published at some point. In addit...

Predrag Dubajic - I believe your code would change the ID in the form, and yes, allow a query string to populate that new version of the form. But on submit the new IDs will go to the server which won't know what to do with the new "underscore" IDs. So to add on to your suggestion, either a JS onSubmit function is required to change the IDs back, or in the server, there needs to be code that changes all inbound underscore IDs to dash before further processing. BTW, I believe I already made this suggestion at some point. The positional nature of the IDs (text-1, email-2, etc) breaks code if things get moved around. But a named ID, like "teacher_name" or "sales_email_address", won't break once it's set in the form definition.