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
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.
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?
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.