The Community forums are being phased out in favor of a new Slack group.
Add your email address below to get an invitation to join the community slack group
Repeatable Section data not stored appropriately (and not suitable for API integrations)
I'm using a repeatable section on a client site to capture trip details for multiple-leg journeys. The repeatable section holds destination and date information etc.
The problem is, this information does not get output in exports or API data in a logical way for users/clients that wish to use the data OUTSIDE of WordPress. I can see why the content has been output as grouped into an array for use within the FOREACH loop for views etc as shown in the documentation, but it's completely useless for developers who wish to integrate with other systems.
My output being sent to the CRM is something like this:
One-way,One-way,One-way
Perth, Western Australia, Australia,Adelaide, South Australia, Australia,Kangaroo Island
Adelaide, South Australia, Australia,Kangaroo Island,Perth, Western Australia, Australia
2017-09-01,2017-09-09,2017-09-15
6,6,6
Have any others in the community tried similar things previously and found solutions to this issue? I see the separate fields are still stored separately in the database, so it's really frustrating that they get grouped when being output.
I'm looking at using jQuery to manipulate hidden fields based on user entries that will then get sent to the CRM, but this is going to be a fiddly process. It would be great if there was a back-end function I could setup to disable this grouping and output each repeater entry as a separate row (as I feel is most logical anyway!)
Any thoughts greatly appreciated!
August 24, 2017 at 7:55 am
In all fairness to the Formidable developers, they can't anticipate everyone's requirements when releasing a new general feature in their product. They have to put out products that are useful to the majority of users. It's not possible for them to address a requirement as specific as yours. They do the best they can.
Architecturally, repeating sections are actually sub-forms that are linked to the parent form. The foreach approach works fine with views, but for a CSV export, I would approach this requirement differently and probably use a custom export table or tables that flattens the data somewhat. It's not too difficult to write data to a custom table when the form is created. I've even helped people write Formidable form entries to MS SQL databases using ODBC connections. You can basically accomplish anything you want through Formidable's hooks.
The hook to use is frm_after_create_entry. http://community.formidableforms.com/knowledgebase/frm_after_create_entry/#kb-update-or-create-another-entry
The Update or Create Another Entry example is the closest example to what you need. The PHP $_POST array is available in this hook. You would use that to parse your entry data and write to the export table. You could also create a server-level cron job that could be used to auto batch send the data. This could be a completely hands-off operation if you wanted to take it to that level. You would need additional fields in the custom table to assure that you're only sending the data once, as well as providing a way to resend data that may have been missed. You would have a complete audit trail this way.
This sounds like a fun project to take on. I wish you success with it.
August 24, 2017 at 6:09 pm
Hi Victor, appreciate your reply, and you're right that the developers can't account for every single requirement when developing the plugin's core functionality.
However, I stick by my opinion that the repeater data is not output in a useful way. Let's look at the various ways of accessing the data:
Why is the data sent in rows, ungrouped in the notification email, then output grouped when viewing the entry in the Admin? Why have Formidable implemented various API plugins (Zapier, MailChimp etc) then not addressed how the data is sent to the APIs? Data output by all form fields should be useful to whatever is on the other end of an API connection. Above all else output should be consistent across all of these steps!
Backend workarounds aside for a second, this feels to me like incomplete or overlooked functionality, especially since the fields are all stored separately in the database - so why are they grouped in the UI? My purpose with this post was A) to see if others have faced the same issues and B) perhaps prompt the developers to address this in future releases.
Thanks for your thoughts on how to approach a solution. Unfortunately in the meantime I've already implemented a fix on the front-end to duplicate the repeater entries into hidden fields, and it's the hidden fields which are then sent to the CRM via the API, so I probably won't be playing with your suggested methods as there isn't enough time left on this job - perhaps in future though!
Still interested to hear if there are any other solutions people have found though.
Discussion closed.