frigid
Forum Replies Created
-
Our preliminary tests confirm the fix is effective with version 1.29.0. Thank you for your attentiveness to our concerns, and for your persistence in bringing this matter to a satisfactory closure.
Your great product just got better!!
Thank you for volunteering that update Zafer! It is welcome news, even with the caveat. Will keep fingers crossed that in short order this one will finally be put to rest.
FYI, issue still present in version 1.28.0 – no response required for now though, unless you have an ETA for a fix or require further information from our end.
I have conducted further testing with the latest Forminator version (1.27.0), and the problem seems to be with the name field. Namely, when a name field is in “multiple” mode and hidden, and the multiple sub-fields are empty, a single empty field is exported even though the headers reflect each of the multiple sub-fields. This causes subsequent data fields to be misaligned with respect to the headers.
Example, where first data row is a model with all fields non-empty, second data row is observed (incorrect) behavior with empty name fields, and third data row is expected (correct) behavior with empty name fields:
ID Name - First Name Name - Last Name Hobby 1 John Smith Coding 2 Coding 3 CodingA workaround might be to use multiple name fields in “single” mode rather than a single name field in “multiple” mode, but, since data should always correctly align with the headers, this is still a bug.
You would not mark a bill as having been paid before it has been paid. Likewise, it is poor form to mark an issue as resolved before it is resolved. I would be happy to update this thread myself once I’ve confirmed resolution. However, until then, this issue should properly remain in “not resolved” status.
Thank you for the response Nithin, as well as the additional information. I am encouraged to hear the developers are still aware of the issue and will be looking at a remedy shortly. In the meantime, I have reverted the status of this issue to “not resolved” so that it accurately reflects the current state.
- This reply was modified 2 years, 9 months ago by frigid.
Plugin version 1.24.1, released today, includes a whopping 62 listed fixes. I can confirm a fix for this issue is not one of them, but thank you for keeping it on the update roadmap.
No worries Nebu John – (except for this issue, of course) we really like this plugin and are thankful for all the work your team puts in to make it so useful!
Confirming this remains unresolved in the latest version, 1.23.3, per end-user testing. Will continue to wait patiently. Thank you for keeping it on the update roadmap.
Thank you Adam @wpmudev-support8 – the update is appreciated. Happy to be able to provide feedback that can help your team improve their product, and glad to hear a fix is in the pipeline…we’ll keep an eye out for the fix in upcoming releases.
Hi Nebu John (@wpmudevsupport14) / WPMU Dev Support,
It’s been a few weeks, so I thought I’d check in. Any updates?
Thank you,
Frigid
Hi Adam @wpmudev-support8,
Thank you for your reply. You note that “those calculation fields are never blank if they are visible”. However, they are generally not visible.
One of the first fields on the form lets the user select how many people (from 1 to 5) they wish to include in the registration. Fields for additional people are hidden. So for instance, if # of people = 1, then the fields for Person 2 to Person 5 are hidden. For each person, a subset of their fields are required if that person is included, so, for example, those fields for Person 2 would be visible (and required) only if # of people > 1.
I did try the trick of calculation-2 = select-2 * 1, and also tried calculation-2 = select-2 * 1 + 0, but the export still seems to omit this field, though, like I mentioned previously, in v1.18.2 this field exports as ‘0’ under the example conditions described above.
Thank you for the prompt reply Zafer @wpmudevsupport15!
The export is available here for a limited time. The issue seems to be with calculated fields {calculation-2} thru {calculation-5}. As I mentioned above, when the inputs for these calculations are blank, the fields appear not to export at all (not even as blank/empty), whereas in v1.18.2, they export as ‘0’.
Update: The issue seems to be with calculated fields, which, if their dependent data fields were empty, would export as “0”, but now apparently don’t export at all.