How to test gform_after_submission?

I’ve set up a connection from GF to Maximizer - a CRM that we’ll be sending some form data to - using the gform_after_submission hook and a couple CURL processes.

My question is, beyond actually getting the final data in Maximizer, how do I test that the process is working?

Is there an active debug that can be set up to show what’s processing? Something that will let me see the CURL responses somehow?

Thanks!

Hi Aaron. I recommend using the built-in Gravity Forms logging functionality:

To make the best use of that with your custom code, please add some logging statements, to check what your code is doing. You can find out how to do that and find some samples here:

Ok great, thanks!
That custom logging was what I was looking for.

Now a connected question - I have 3 CURL commands running in a gform_after_submission function.
If i add a log statement at the start of the function, I see it in the log file, but my log statement mid-way and at the end of my function doesn’t show up in the log file. Does that mean its not running, or do they time out?

That likely means that this portion of the code is not running. Share your code (using a code-sharing site) and post the link here, and we can take a look at the code and see if anything stands out.

If in building this API request you are doing a lot of iterations, or are building similar use cases in the future, you may want to look at how Gravity Flow’s outgoing webhook provides some improved user experience for both developer and request processing.

  • No code?
    If your CURL command is relatively straight forward you won’t have to write any code! Add the URL, field mappings and connection details into the step settings and the webhook step will handle the rest. That can even include mapping values back from the API response it receives into specific fields.

  • Low code!
    If you do have logic to add, the gravityflow_webhook_args filter lets you focus on the logic to change and let the automation handle the actual request/response processing.

  • One click to re-run test cases
    As the webhook call is now a step in the workflow, you can select to restart a step to repeat/test in contrast to potentially re-filling in all the fields and submitting a new form each time.

  • Response code mapping / error handling
    This step type lets you define what the next step in a workflow should be depending on the response type received (200/300/400/500). The dreaded “the 3rd party system we connected to had an outage or network connectivity issue and we need to figure out which entries need to be re-processed”. You could have any which fail route to a separate step assigned to your support team to investigate/resolve.

  • Multiple ways to log in any environment
    The same logging approach that @chrishajer linked you to will work in Gravity Flow as well. Plus, the timeline which displays at the bottom of each entry details page could either be customized (changing the default note via gravityflow_timeline_note_add) or add your own during code execution via
    gravity_flow()->add_timeline_note( $entry['id'], 'custom message');
    If you don’t want to turn on xdebug or full logging in a production system, but still get some details out of edge case code execution, the timeline can be a good alternate.

Cheers,
Jamie

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.