Task #89761


Epic #89759: Performance improvements in Forms module

Optimize form listing

Added by Mathias Brodala over 4 years ago. Updated over 3 years ago.

Should have
Form Framework
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Sprint Focus:


Currently forms are retrieved as follows in exactly this order:

  1. Traverse all configured storage folders
  2. Collect all *.yaml files in a folder
  3. Read the full content of each *.yaml file
  4. Determine if the content looks like a form definition
  5. Skip anything which does not end with .form.yaml

There is clearly room to improve on each step and especially the order could be changed to have simple filters (like for .form.yaml) executed early using custom FAL filters.

Actions #1

Updated by Sybille Peters over 3 years ago

Is it really necessary to have the forms anywhere in the configured storages? Or is it possible to have them in a dedicated place?

Also, does 1. mean the storage is searched? Not just sys_file?

Should you even have files that can be connected to content elements and are scanned and referenced by FAL and forms in one place?

Scanning the entire storage seems a bit much.

I have not used form for a while, but the first time I used it, there were also performance problems with upgrade wizards because the wizard would can the entire storage.

There are a number of open issues related to large sites (in general, not specific to form). Some of these do not turn up as problems in a typical small installation. But they can start to make TYPO3 unusable when you get to a certain point of number of files, dirs, pages etc. (e.g. see pagetree performance, see #52374, #88873 etc.)

My wish is that the possible performance impact is considered early and the patches are already tested keeping these scenarios in mind.

Maybe this is too much to ask.

But then I think a limit should be defined of max number of pages, files, dirs etc for TYPO3.


Also available in: Atom PDF