I will try to keep this as short as I can but there are a lot of moving parts here.
I am using Gravity Forms to make a very complex form, the form is about 45 pages long but is broken up into separate forms that pass data between using Easy Passthrough. This was done because we were facing performance issues when we had one large mega form.
The form is an insurance form and each page is an individual carrier, using Gravity Flow, after each page of the form is submitted, the data is mapped into a master form. This form is not front facing and is just used to pull data from using Gravity View and Gravity PDF to reference.
The master form has a field in it with a calculation, the calculation is adding up the total of each insurance carrier to then give you a master total. This is pulled out to be displayed in a Gravity View for the user to see, as well as pulled out to dynamically generate a PDF to view.
The problem is that because the master form is not front facing, the sum calculation has nothing to trigger it. Initially, I was using this code snippet to trigger the sum on the master form. However, this triggered every single calculated field and caused very slow load times between pages.
My next idea was to use the gform_after_submission filter to run a database query just on the master form to trigger the calculation needed. I want it to run the MySQL query through the $wpdb global variable. Here is the code snippet I am trying to use, given to me by Gravity Flow.
However, when I run this nothing happens. Not even the debug logging. Does anybody know what is happening or have any alternative fixes? Thank you!
Are you using the Form Connector extension of Gravity Flow to map the data from page/carrier form into master form? If so, have you thought or tried one of the following?
Using gravityflowformconnector_update_entry within your current built step. It has access to both entries involved in the mapping, so you could add the calculation into code here to refresh it with latest data.
Creating a custom step type that each page/carrier entry performs. Depending on what settings you define and how your calculation was defined (GVMath?), you may be able to keep it into the step settings(DB) to reduce amount of custom code required.
Did you encounter similar performance issues if the fields for each “page” were either the subset for display/edit via a User Input Step or keeping the same split with the Form Submission Step?
The GFCommon::calculate function lets you generate an updated calculation based on providing the form, field, entry which has newest values. So an example snippet based on the suggested gravityflowformconnector_update_entry filter would be: