Form manager ¶
What does it do? ¶
can be accessed by opening the backend module ‘Forms’.
It allows the editor to administer all of the existing forms stored on the
accessible filemounts. The central element of the
table view which…
- lists all forms
- allows users to create, edit, duplicate, and delete forms
- names the storage folder
- gives a broad overview on which pages the listed forms are used in.
The creation and duplication of forms is supported by a so-called
. The wizard guides the editor through the process and offers a
variety of settings depending on the form configuration. Those settings
include choosing filemounts, prototypes, and start templates.
Start templates ¶
This is a very nifty feature. When creating a new form, the
allows the backend editor to select a so-called
. Such a
template is a predefined
without the property
which is normally used as a foundation of a new form.
As an integrator, you can specify as many
as you desire
for a given
. After you have defined such a template, follow
these easy steps to use your defined
as a foundation:
- create a new form by clicking on the appropriate button
- enter the ‘Form name’ and click the checkbox ‘Advanced settings’
during the next steps you can select a
, you have to define a
in order to
enable the editor to choose one. Additionally, the same
can be used for several
. To do so, make sure the included
form elements of the template are defined in the corresponding
For example, imagine your integrator has
a prototype called ‘routing’ which contains a custom form element with the
‘locationPicker’. The element is only
defined for this prototype. The integrator has created a
which carries the ‘locationPicker’ form element. A backend editor could now
select and use this
, including the custom form element,
as long as the
is set to ‘routing’. If the integrator also
adds this custom form element to another
, the process would
crash. The custom form element is only known by the
The following code block shows the minimal configuration of a
. You need at least the root form element (‘Form’) and a ‘Page’.
type: 'Form' identifier: 'blankForm' label: '[Blank Form]' renderables: - type: 'Page' identifier: 'page-1' label: 'Page'
As mentioned previously, the form wizard within the
a list of all existing,
. As soon as the backend editor creates a form with the
help of such a template, a new
is generated based on the
one of the selected
enriched by the property
defining the chosen
of the root form element (‘Form’) is automatically set
based on the entered “Form name”. Additionally, this name is used for the
property `` label`` of the ‘Form’ element. Finally, the
loaded and displays the newly created form.
Translation of the form manager ¶
All option values which reside below the following configuration keys can be translated:
TYPO3: CMS: Form: formManager:
The translation files of the
are loaded as follows:
TYPO3: CMS: Form: formManager: translationFiles: # custom translation file 20: 'EXT:my_site_package/Resources/Private/Language/Form/Database.xlf'
The process searches for each option value within all of the defined translation files. If a translation is found, the translated option value will be used in preference.
Imagine, the following is defined for an option value:
... label: 'formManager.selectablePrototypesConfiguration.standard.label' ...
First of all, the process searches for the translation key
within the file
and after it inside the file
(loaded by default). If nothing is found, the option value will be