FAQ

How do I override the frontend templates?

There are 2 possible ways to override the frontend templates.

Globally extend the fluid search paths

Since EXT:form mainly uses YAML as configuration language you need to register your own additional YAML files. Let us assume you are using a sitepackage EXT:my_site_package which contains your whole frontend integration.

EXT:my_site_package/Configuration/TypoScript/setup.typoscript

First of all, register a new EXT:form configuration for the frontend via TypoScript.

plugin.tx_form {
    settings {
        yamlConfigurations {
            # register your own additional configuration
            # choose a number higher than 10 (10 is reserved)
            100 = EXT:my_site_package/Configuration/Form/CustomFormSetup.yaml
        }
    }
}
Copied!

EXT:my_site_package/Configuration/Form/CustomFormSetup.yaml

Next, define the additional fluid template search paths via YAML.

prototypes:
  standard:
    formElementsDefinition:
      Form:
        renderingOptions:
          templateRootPaths:
            20: 'EXT:my_site_package/Resources/Private/Templates/Form/Frontend/'
          partialRootPaths:
            20: 'EXT:my_site_package/Resources/Private/Partials/Form/Frontend/'
          layoutRootPaths:
            20: 'EXT:my_site_package/Resources/Private/Layouts/Form/Frontend/'
Copied!

EXT:my_site_package/ext_typoscript_setup.typoscript

Register your EXT:form configuration for the backend via TypoScript. Read the chapter about configuration concepts to learn about the recommended ways.

module.tx_form {
    settings {
        yamlConfigurations {
            100 = EXT:my_site_package/Configuration/Form/CustomFormSetup.yaml
        }
    }
}
Copied!

How do I disable multiple form submissions?

The use case is quite obvious: a user can submit a form twice by double clicking the submit button. This could cause trouble since the attached finishers are processed multiple times.

Right now, there are no plans to integrate a feature to prevent this behaviour, especially not server side. An easy solution could be the integration of a JavaScript function to stop the behaviour. TYPO3 itself does not take care of any frontend integration and does not want to ship JavaScript solutions for the frontend. Therefore, integrators have to take care and implement a solution.

As an example, check out the following JavaScript snippet. This should do the trick. It can be added to the site package of the TYPO3 installation. Please note, the selector (here myform-123) has to be adapted to the id of the corresponding form.

document.getElementById('myform-123')
    .addEventListener('submit', function(e) {
        e.target.querySelectorAll('[type="submit"]')
            .forEach(function(button) {
                button.disabled = true;
            });
    });
Copied!

How do I migrate from EXT:form v7?

The old form extension (used in TYPO3 v7, which is compatible to TYPO3 v6) was moved into an own extension called form_legacy. This extension can be found within the official TER. When upgrading to TYPO3 v8 an upgrade wizard will tell you if form_legacy is still needed.

How does the date picker (jQuery) work?

EXT:form ships a datepicker form element. To unfold its full potential you should add jquery JavaScript files and jqueryUi JavaScript and CSS files to your frontend.

Is it possible to build a frontend user registration with EXT:form?

Possible, yes. But we are not aware of an integration.

Is there some kind of export module for saved forms?

Currently, there are no plans to implement such a feature into the core. There are concerns regarding the data privacy when it comes to storing user data in your TYPO3 database permanently. The great folks of Pagemachine created an extension for this behalf.

The honeypot does not work with static site caching. What can I do?

If you want to use a static site caching - for example using the staticfilecache extension - you should disable the automatic inclusion of the honeypot. Read more here.

How do I set a default value for my form element?

Most of the form elements support setting a default value (do not mix this up with the placeholder attribute). For a text field or a textarea, this is quite trivial.

A little bit more thrilling is the handling for select and multi select form elements. Those special elements support - beside the defaultValue - a prependOptionValue setting. The defaultValue allows you to select a specific option as default. This option will be pre-selected as soon as the form is loaded. In contrast, the prependOptionValue allows you to define a string which will be shown as the first select-option. If both settings exist, the defaultValue is prioritized.

Learn more here and see the forge issue #82422.

How do I create a custom finisher for my form?

Learn how to create a custom finisher here.

If you want to make the finisher configurable in the backend UI read here.

How do I create a custom validator for my form?

Learn how to create a custom validator here.

Which folder structure do you recommend?

When shipping a custom form configuration, form definitions, differing form templates, or language files you may wonder how the perfect folder structure within your site package could look like. We recommend the following structure:

  • Custom form configuration: EXT:my_site_package/Configuration/Form/
  • Form definitions: EXT:my_site_package/Resources/Private/Forms/
  • Custom form templates:
    • Templates EXT:my_site_package/Resources/Private/Templates/Form/
    • Partials EXT:my_site_package/Resources/Private/Partials/Form/
    • Layouts EXT:my_site_package/Resources/Private/Layouts/Form/
    • Keep in mind that form comes with templates for both the frontend (this is your website) and the TYPO3 backend. Therefore, we recommend splitting the templates in subfolders called Frontend/ and Backend/.
  • Translations: EXT:my_site_package/Resources/Private/Language/Form/