Utkarsh
Member
Is there any reason that the gform_post_submission hook is only fired in GFFormDisplay::process_form, if there's a redirect in the form?
I wanted to get the lead and form details (like the post_submission hook provides) as early in the request as possible to do some processing that requires modifying response headers.
The only reason is backward compatibility. The submission processing logic was initially developed late in the process, so the gform_post_submission hook was also fired late in the page life-cycle. After we moved the submission processing logic early in the life-cycle (mainly to be able to do real redirects), we had lots of users already using that hook and we wanted to affect as few of them as possible. So we made the choice of moving the gform_post_submission hook only if "needed" (i.e. if the confirmation was configured as a redirect). I do agree with you that the result is a hook that is not consistent, which is less than ideal.
What I think we will need to do is create a new hook that fires consistently after submission in the GFFormDisplay::process_form() function and eventually phase out gform_post_submission.
Do you have any thoughts on this? I am opened to suggestions.
Utkarsh
Member
Ah, backwards compatibility is surely a pain.
I managed to solve my issue by hooking into the pre_submission hook, as I only needed to verify if the form was valid, and redirect based on that (I had thought pre_submission was fired before validation), but it would have been very hacky to try and get the lead data at that point.
If you need to maintain backwards compatibility, I'm with you that there should be another hook that is fired consistently, and the current one should be deprecated.
