Delay entry creation

So, the flow I’m trying to accomplish is:

User updates form (this is done via Gravity View)
The entry is processed with all the normal validations
The entry is NOT updated yet
User is redirected to checkout with adjusted price
User pays
Upon payment completion, the entry is now saved and updated

So far, I can accomplish everything except what is in bold. Right, now, I’m able to hook in and redirect the user after they update their entry, pass the price difference to WooCommerce, and then trigger an action on payment completion.

I’m having trouble telling gravity forms to NOT save the entry on submission and then figuring out a way to pass that updated entry object to the last step after payment has completed.

I thought about using the gform_form_tag filter to add a custom handler to the form… but I’m unsure how to handle that data, temporarily store it, and then pass it to the end function. That route seems a little too much for what I’m wanting, especially with the $entry object so nicely provided in so many hooks.

Any suggestions would be greatly appreciated.

So, I’m trying another approach now. I’m trying to maybe roll back the update, immediately after the gform_post_update_entry hook fires… However, the $original_entry and the $entry object that I am logging are identical…

I do have Gravity Forms Entry Revisions add-on… is this causing some weird conflict?

Have you looked at how Gravity Flow could help you in this? The idea that different steps happen in a prescribed order after form submission is the core of what it’s build for. That includes making edits, Woo Commerce and payments, or updating fields in an existing entry.

How many fields are subject to the changes before payment?
Could you have “duplicate” fields for each in the form and use a preferred method to copy the values:

  • gform_after_submission
  • Set the default value in duplicate fields based on the “original” field merge tags
  • Flow’s Form Connector Update Fields
  • Gravity Wiz CopyCat

Then expose the appropriate fields to View / Flow / other for method to edit. That would allow you to use the appropriate hook/event to copy back into the “original” fields for the final entry save following payment.

In Gravity Flow’s case, it reads like it could be a no-code required pattern, but gravityflow_step_complete may also be one to look at for low-code to trigger changes. It’s kind of the step equivalent of gform_after_submission or gform_post_update_entry in the case of its’ User Input step type.


1 Like

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