As explained in the issue exporting all data is unfortunately not as easy as it looks.

You cannot simply use the first log entry to retrieve the export columns since the log can contain entries of various different forms with completely different fields. So you'd be left with traversing all log entries to make sure to add all possible columns to the export. This would be overkill given that there can be thousands or millions of entries.

So for now explicitly configuring all known columns manually is the only option ATM. Do you have another idea? Otherwise I'm afraid I won't be able to accept the proposed change like this.

@mbrodala
Hi, As mentioned in this comment it would be the use-case that an author will first select a special form or page and then make the export.

As a solution we can change the code, so it will export all available fields from the current filter. That's the only solution we know at the moment.

OK I understand. But in this case we will also need some UI adjustments to make it clear to editors what will happen on export.

OK I understand. But in this case we will also need some UI adjustments to make it clear to editors what will happen on export.

What do you mean exactly? Do you want an extra text under the list which say "All columns of selected forms will be exported" or do you want something else?
Example:

@PhilippKuhlmay Sorry for the late response: we'd actually need two separate actions here, e.g. using a 2nd export button which is only clickable if entries have been filtered by a single form. That button needs the same target format selection (CSV/XLSX currently).

But that by itself will be confusing and rather unclear so it needs a better UI/UX concept.

Also we need to take into account that form definitions are not immutable. It's perfectly fine to add, remove or change fields in a form definition over time. This would mean that even log entries from the same form could have different fields. Thus we'd have the same problem as with exporting all entries of all forms.

Also we need to take into account that form definitions are not immutable. It's perfectly fine to add, remove or change fields in a form definition over time. This would mean that even log entries from the same form could have different fields. Thus we'd have the same problem as with exporting all entries of all forms.

what about adding a hash over the full configuration (or all fields + finishers) and do some basic versioning with it?

Hi, adding my 2 cents here ;-)

The usecase of mostly all of our customer is:

• editor creates a form and adds it to a page
• the form will live some days/weeks, and the form definition may change during its life
• editor should be able to export the form data corresponding to the actual form definition (the one that exists at the moment of the form)
• editor never asks to export all form data at the same time
• editor do not wan't to configure the export through Typoscript itself (he actually asks the agency to do it)

So, having something like that would fit perfectly the usecase:

• filter a specific form definition in the export module
• the export module reads the form definition for the defined field/labels and build the file from it
• if a defined field is not found in the form data: blank value / if a form data does not exists anymore in the form definition: not exported (not relevant anymore)
  If reading the form definition at the time of the export is not possible, having the possibility to override the export settings per form identifier would fit.

@dogawaf Would you like to propose your workflow as separate PR?

I now use https://extensions.typo3.org/extension/form_to_database which does everything I need.