Maybe someone in the community can give me some information as I tried to contact Gravity Forms support and it seems they are unable to answer, what I would think are rudimentary pre-sales questions.
We’re looking at using something like Gravity Forms for our company’s website to manage our data collection.
Our requirements are quite simple, and I will be able to do most, if not all of the scripts required for it myself, however without knowing what is possible with the plugin itself we cannot decide whether it would be suitable for our company. So, yes I know there is customization required, but I need to know whether the core of Gravity Forms supports it.
- Is it possible before a form is saved (from what I gathered, something like gform_pre_submission) to tell the plugin to not save the entry? So, from my side, I would have my conditions. If conditions are met, then save the data, else don’t save the data (and if possible return a reason).
- Is it possible after a form has been saved (gform_after_submission from what I found) to once after I have done my due diligence with the data, update the entry again. The goal of this would be that certain entries would be disbursed to endpoint APIs, or have certain verifications done on the data. Each would have a response that needs to be updated on the entry.
- Is it possible to set up custom export criteria that can update information on the form. When data is exported from the form, there would be a field that needs to be updated showing it has been exported to prevent the data from being exported again in the future. So, again probably some hook where I can override any export fields and criteria that has been set from the export function.
- Is there any issues with Gravity Forms and timeouts on scripts within hooks that take a longer period of time. Ignoring the PHP execution time which would stop a script and I am aware of.
Hope there is someone that can shed some light on my questions and thank you in advance.
Re: Q2 - This has a strong alignment to the functionality of Gravity Flow. The functionality in the outgoing webhook step in particular with support for request and response mapping would likely give you a lot of flexibility with little or no code.
Re: Q1: The filter may not be the right place (more specifically timing) to delete the entry while it is still processing. If it is possible that way, you might look to the GFAPI to delete an entry. If it is okay that the entry is temporarily saved to system, the Gravity Flow extension Form Connector with its delete an entry step would make for a guaranteed deletion (it uses a cron event to check/delete after the workflow has completed.
Q3 - Possibly gform_export_form or gform_export_field_value and then using GFAPI::update_entry_field ?
Q4 - Generally speaking no - the PHP execution time is main item to be aware of, with hosting environment playing a contributing factor there. Overall it generally is not a large concern that all hooked actions/filters and form submission code will process within fractions of seconds. With outgoing API requests depending on hosting/firewall restrictions you can hit that, but again hosting/configuration is more of the root cause there than Gravity Forms code.
Thank you for your response, I will definitely have a look at Gravity Flow when I get some time. I did manage to find someone that was willing to do some testing on some of the things for me so far, along with me reading pretty much the majority of the documentation allowing me to get an idea of what can be done. So, updates regarding my questions;
- This was pretty simple to determine if it is doable, my question may have not been direct to the function. Using custom validation on fields, conditions can be checked and set invalid thus stopping the form from submitting. It is not intended to delete information, but stop it from accepting an entry if conditions aren’t met.
- I will look into Gravity Flow to see where it can assist in this step. Endpoints are vastly different and can be (current endpoints) REST, SOAP, FTP, or email, and outside of our control on what is utilized.
- One thing I came across, which will most likely, in the end, be the solution I would take if I do go the Gravity Forms route (still some more research to do) is to just develop as a plugin, which gives the ability to a page specific for the plugin (if I read documentation right) through plugin_page(). From there it seems like utilizing GFAPI (as you mentioned) I should be able to search and update entries, along with my code to write the corresponding files. It also opens up something that was seen as optional, a dashboard with statistics, etc.
- We do have control over quite a bit of configuration which does mean I can set the execution time higher, so this does seem to be a non-problem.
Again, thank you for your response.