Skip to main content
Jahia Store
EN

Formidable Engine

prereleased
Download 0.5.0

Information

Module ID
formidable-engine
Group ID
org.jahia.modules
Status
prereleased
Category
Forms
Author
JSG
Developer website
http://www.jahia.com
Requires Jahia
8.2.2.0
Released
2026-10-13
Source
scm:git:git@github.com:Jahia/formidable.git

The server side of Formidable, the form builder for Jahia.

It receives and validates every submission, then runs the form's actions.

  • Secure submission handling: server-side validation of every field (constraints, allowed file types, choice values), cross-origin checks, CAPTCHA verification (Google reCAPTCHA, Cloudflare Turnstile, hCaptcha), and an option to accept submissions from signed-in users only.
  • Built-in form actions: save to the repository, email notification, email of the full submission (with the uploaded files as attachments, if you choose), and forwarding to an external endpoint. Developers add their own actions as OSGi services.
  • Field actions: a framework for checks attached to a single field, such as an email deliverability check or a customer directory lookup. They run on the server when the visitor leaves the field or submits, and again when the submission is received. A refusal shows on the field with the message the contributor wrote. No check ships with the module: developers write their own as OSGi services, each reading the address and credential of its service from its own configuration, within shared timeouts and request limits.
  • Form results in jContent: browse the submissions of each form, open a submission with its files, export to CSV or JSON over a date range, and delete. Results are private by default and readable per form through the Form results reader role.
  • Editor extensions: the conditional logic editor, the choice options editor and the other custom selectors used to build forms.

Requires jContent 3.6+.

Versions

Breaking Changes

  • Changed the module's configuration from one file to five, one per theme: captcha, uploads, choiceOptions, formActions and fieldActions, each deployed with every setting at its default.
    • Am I impacted? Only if this installation changed a setting (CAPTCHA keys, upload limits, options sources, forward targets, field action providers) through the file, the provisioning API or the Felix console. The single file karaf/etc/org.jahia.modules.formidable.cfg (PID org.jahia.modules.formidable) is no longer read.
    • What happens at the upgrade: at the first start, every setting held at a non-default value is carried into its theme's file karaf/etc/org.jahia.modules.formidable.<theme>.cfg, and the log names them (Carried over from org.jahia.modules.formidable into the theme's file). The old file gets a first line saying it is no longer read, and is never deleted.
    • What to do: open the five files after the upgrade and check your settings are there. Re-enter any setting the log reports as not carried over (Gave up carrying …). Point provisioning scripts (editConfiguration) at the theme's PID.
  • Changed options sources and forward targets from lines of one setting to one configuration file per entry. 
    • Am I impacted? Only if this installation declared options sources or forward targets.
    • What happens at the upgrade: at the first start, the existing lines become one file each in karaf/etc/, org.jahia.modules.formidable.choiceOptions.source-<id>.cfg and org.jahia.modules.formidable.formActions.target-<id>.cfg, and the log lists their ids. A development target becomes an entry marked development=true. An id is now letters, digits, dashes and underscores only: a line whose id holds a dot or a space is not converted.
    • What to do: check the new files in karaf/etc/. For a line that was not converted, declare the entry under a valid id and point the forms that stored the former id at it. Change provisioning scripts to write one entry per id (editConfiguration with the file's name without .cfg) instead of the list settings, which are no longer read.
  • Changed the allowed file types: the setting uploadAllowedMimeTypes is renamed uploadAllowedTypes, it accepts extensions, and an empty list now refuses every file.
    • Am I impacted? Only if a provisioning script sets uploadAllowedMimeTypes, or a file field accepts a type the allowed list no longer holds. An installation whose list was empty keeps accepting any file after the upgrade (the list is carried over as */*).
    • What to do: rename the setting to uploadAllowedTypes in provisioning scripts. A file field stops accepting a type removed from the list, so add that type to the list if the field still needs it.
  • Changed the thirteen fmdb:-prefixed properties of choice and date fields to unprefixed names (fmdb:options becomes options, fmdb:minBoundMode becomes minBoundMode, …).
    • Am I impacted? Only if a template set, a module or an integration reads those properties by name: in a view, a GraphQL query, a JCR-SQL2 condition, a Content Editor override or a label key. Contributors and visitors see no difference.
    • What happens at the upgrade: existing content is renamed when the engine starts, in both workspaces and with translations. jahia.log reports it: Renamed the prefixed mixin properties of N field(s). An export taken from 0.4.0 still imports; restart the engine afterwards so the imported fields are renamed too.
    • What to do: update the code that reads the prefixed names. The administration guide, "Upgrade notes", lists all thirteen.
  • Changed the buttons of a form to come with a style of their own instead of the browser's default.
    • Am I impacted? Only if your site styles the form buttons with rules that target the button class alone (.fmdb-btn). Rules written under the form (.fmdb-form .fmdb-btn) still win.
    • What to do: open a form and look at its buttons. If they no longer look like yours, scope those rules under the form, or set the --fmdb-btn-* variables the styling guide documents. Set the variables on :root, because the message shown after a submission renders beside the form.

Improvements

  • Added automatic jExperience mapping rules: a published form with mapped fields feeds the visitor profile.
    • Map a field to a visitor profile property in the form editor and publish the form. jExperience gets the rule that writes each submission into the profile, updated at every publication and removed when the form is unpublished or deleted. Nothing to configure in jExperience.
  • Added visitor profile updates on submission.
  • Added prefill of mapped fields from the visitor profile when the page opens, replacing the field's default.
  • Added a per-field choice of what follows a prefill: leave the field editable, make it read-only or hide it.
  • Added a prefill that comes back when a visitor resets a form or starts another one.
  • Added field actions: your own check of a field's value, run while the visitor types and again at submission.
  • Changed the Field actions switch of a field's editor so it closes the Field settings section.
  • Added a form actions zone to the Page Builder: see, order and add a form's actions from the page it sits on.
  • Added a visible line for hidden fields in the Page Builder, so you can select and edit them.
  • Improved the text, email and textarea field editors: Content keeps the essentials, the rest is in Field settings.
    • The Advanced settings switch is gone, and its settings sit in those groups. Four HTML attributes that have no effect in a form are no longer offered.
  • Improved the number, slider and date field editors: Content keeps the essentials, the rest is in Field settings.
    • The slider keeps its minimum and maximum in Content. The date bounds and their settings sit together under Constraints.
  • Improved the choice, file and colour field editors: Content keeps the essentials, the rest is in Field settings.
    • The options of a choice field and the accepted types of a file field stay in Content, because they define the field.
  • Improved the consent, rating, scale and switch field editors: Content keeps the essentials, the rest is in Field settings.
    • The consent keeps its statement and terms page in Content, and the rating and the scale keep the bounds that draw them.
  • Improved the form editor: the steps bar switch joins Buttons, the children block is hidden, and the validation messages carry one note.
    • Under Validation messages, one sentence says that an empty message keeps the browser's, instead of a line under each message.
    • The Logic section is renamed Conditional display, since its rules only show or hide a field. Its rules sit right under the section title.
    • On an email field, the Multiple emails switch sits in Content next to Required, as on a select or a file field.
    • The settings of a field action sit right under Configuration.
    • On the Results page, a form that lost its publication reads "Form unpublished" and a removed one "Form deleted".
  • Improved the rules editor of Conditional display: opening a field with rules, or adding a rule, no longer waits on two queries for every rule row.
  • Improved file fields: allowed types can be given as extensions, every allowed type shows its extensions and a clear name, and fields offer only the types still allowed.
  • Added the submitter's time zone to the form results and exports, shown with the other details of a submission.
  • Added the removal of a form's entry from the Results page once all its results are deleted. The entry of a form that was unpublished or deleted is flagged as such, and can be removed the same way.
  • Changed the Results page to mark a deleted or unpublished form with a coloured icon instead of a tag.
  • Added arrow-key navigation to the Results page: up and down along the forms, right and left between forms and submissions.
  • Added the settings a new version brings to your configuration files at startup, at their defaults.
  • Added a published package so a module of your own renders form fields like the built-in ones, input masks included.
    • Add @jahia/formidable-library to your module (yarn add @jahia/formidable-library) to import the help block, the validation-message attributes and the input mask instead of copying their markup.
  • Added markers so your own module can offer a form type, or a field that submits one value per choice.
    • Put the form marker on a content type of your own, and the submission pipeline, the permissions sync and the results treat it as a form. Put the choice-cardinality marker on a field that draws one input per choice, and it is read like the built-in checkbox. Neither marker needs a property, and the built-in types already carry them.
  • Added the type names of the form content model as constants your module imports, instead of copying each one.
    • A custom action, integrity check or integration names a form type or a field marker through the published API, so a typo fails the build instead of silently matching nothing. The extension guides list the classes to import.

Bug fixes

  • Fixed the success message so a slow submission no longer waits an extra half second before showing it.
  • Fixed an unanswered form field writing an empty value into the visitor profile, which blocked every later answer.
  • Fixed the visitor profile integration so it installs next to jExperience 3.4+ and jCustomer 2.x as well as 4.x.
  • Fixed the save of a field action by a translator, which failed on the behaviour and message settings.
  • Fixed the file field still listing the uploaded file after a reset, or when the visitor starts another submission.
  • Fixed date and time answers showing as raw values in the form results.
  • Fixed the Results page, which showed an error instead of the list when a form's reference could not be resolved.
  • Fixed misleading migration errors in the server log during a direct upgrade from version 0.3.

Misc

  • Improved the documentation, with one folder per reader: styling, extension, administration and architecture.
  • Improved the styling guide: every class hook and variable is documented, with a map of the rendered form.
Requires Jahia 8.2.2.0Released 2026-10-13

Breaking Changes

  • Changed source-based option settings to be required: a choice field must name the source its options mode needs

    Breaking change. You are affected if you create or import forms programmatically with a source-based options mode: the field can no longer be saved without the settings that mode needs — the source for a declared source, the root category for category options, the root node and content type for content options. The list of manually typed options is NOT required. In the editor nothing changes beyond the standard required indicators; existing forms are not modified, but the next edit of an incomplete field asks for the missing values.

  • Changed choice-field option storage to one shared format; existing forms are converted automatically at startup

    Breaking change. You are affected if you built custom views, queries or integrations that read a choice field's option list directly from its stored properties: selects, radios and checkboxes previously each stored their options under their own property, and they now all share a single one. Regular forms need no action: the conversion runs once when the new version starts, in both edit and live, and published forms keep rendering without a republish.

    One case needs attention: a form export made with version 0.3.0 or earlier and imported into an instance already running this version shows empty option lists on its choice fields until the server restarts, which re-runs the conversion. Restart after such an import, or re-save the options in the editor.

  • Changed the form rendering module's identity; upgrading from 0.3.0 or earlier requires a one-time reinstall

    Breaking change. You are affected if any version up to 0.3.0 of the form rendering module is installed: uploading the new version fails with "Module upload failed because another module formidable-elements exists."

    Earlier versions were packaged under a placeholder group id; the module is now published under the official Jahia group id, as required for distribution on the Jahia App Store. Jahia treats a module with the same name but a different group id as a different module and blocks the upload.

    To upgrade, in Administration > Server > Modules and Extensions > Modules:

    1. Upgrade formidable-engine to the new version first, with "Validate module definitions" unticked: the new version removes submission properties no version since 0.2.0 has written, so the validation rejects the upload as a major definition change. This is expected — values stored by a 0.1.x instance are left in place.
    2. Stop and uninstall the old formidable-elements. Do not tick the option to delete the module content when uninstalling — that choice erases every form and every submission stored in the repository. Left unticked, forms and submissions are fully preserved; forms simply stop rendering while the module is absent.
    3. Install the new formidable-elements, with "Validate module definitions" unticked: the new version reorganizes some field properties, so the validation rejects the upload as a major definition change. This is expected — the automatic content migrations take over for the existing content.
    4. Re-enable formidable-elements on every site that uses it: the uninstall removed it from the sites' enabled modules, and forms show a "Module error" box until it is enabled again. A server restart does not repair this; re-enabling the module does, immediately.
    5. Check that forms render again. Existing content is migrated automatically; the migrated fields may show as modified (pending publication) afterwards — nothing is actually pending, publishing them is optional and only clears the flag.

    This is a one-time procedure: later upgrades install in place as usual. The full walkthrough, with the exact messages to expect, is in docs/upgrade-notes.md.

New Features

  • Added a ready-made title to every new form action
  • Added a New content button to every step and field group in the Page Builder, so an empty one can be filled
  • Improved form authoring with colour-coded zones and icons telling steps, fields and contents apart
  • Added a translatable title to the field and action lists of a form, shown in the Page Builder
  • Added live input-mask guidance while typing in text fields
  • Added contributor-authored rich text help under form field labels
  • Improved the select option rows with clearer placeholders and hover hints
  • Added choice-field options filled live from admin-declared sources or categories
  • Improved the form preview in jContent: every step and conditional field is shown, instead of a frozen first step
  • Added choice-field options filled live from the site contents under a picked root

    The submitted value is the content path relative to the picked root, and the list is capped by a configurable limit: above it the field reports an error instead of silently truncating the options. Note that publishing the form also publishes the picked root and the contents under it; mark drafts as work in progress to keep them out.

  • Added support for array entries in datalayer visibility rules (for example dataLayer.0.event)
  • Added browser variables (such as datalayer entries) as conditional logic sources
  • Added date and datetime bounds that follow the submission day, e.g. no birth date in the future

    Upgrade impact. You are affected if your forms use minimum or maximum dates: each bound is now a choice between a fixed date and the current date, and existing fixed bounds are converted automatically when the new version starts, in both edit and live — published forms keep rendering without a republish. Follow the documented installation order (see the upgrade notes), as for every upgrade that changes content definitions.

    One case needs attention: a form export made with version 0.3.0 or earlier and imported into an instance already running this version keeps its date bounds enforced when the form is submitted, but the date pickers and the editor do not show them until the server restarts, which re-runs the conversion. Restart after such an import, or re-select the bounds in the editor.

  • Added date bounds at an offset from the submission day, e.g. age limits or booking windows
  • Added the German and Spanish translations of every form element and form action label
  • Added optional rating, scale, switch and consent fields, logic-ready and validated server-side
  • Added numeric and boolean logic operators, with rules that survive renames, copies and imports
  • Changed the editing of multi-step forms: every step is shown at once while authoring, with no step navigation
  • Added a number field with spinner, minimum/maximum/step constraints and range validation messages
  • Added a slider field with range bounds, end labels and tick marks, counted as answered on interaction
  • Hardened form submissions by rejecting values for fields proven hidden by their display conditions
  • Added URL parameters and cookies as conditions for showing or hiding a form field
  • Added a style hook on fields driven by conditional logic, so template sets can flag them, notably in edit mode
  • Added text, textarea and email fields as conditional logic sources (filled, empty, equals, contains)
  • Added conditional logic date criteria that compare against the submission day instead of a fixed date
  • Added a maintenance message on forms that store submissions while the platform is in read-only mode

    The message is editable per form and per language in the Response Messages tab, pre-filled with a translated default.

  • Added translated default success and error messages, prefilled on newly created forms
  • Added a configurable empty option label on select fields, so they start empty instead of preselecting a value

    Single-choice selects only: the option is not rendered on multiple selects. Starting empty makes the required validation of the field effective in the browser.

Bug Fixes

  • Changed failed submissions to answer with the status the failing action reported instead of a generic one
  • Hardened submissions: a form declaring no field no longer stores arbitrary posted values
  • Improved memory use when sending large form attachments by email
  • Fixed form submissions being rejected for logged-in visitors by the Jahia CSRF protection

    Affects platforms running jahia-csrf-guard 4.3 and later: authenticated visitors received an error on every form submission, while anonymous visitors were unaffected. Cross-site submissions remain rejected by the built-in origin check.

  • Improved the upgrade: sites that lost the form rendering module get it re-enabled automatically
  • Fixed the CAPTCHA checkbox sometimes not appearing when the provider script takes time to load
  • Hardened the automatic conversion of choice options so one broken field no longer blocks the others
  • Fixed conditions on an enclosing section being skipped when a field shares its section's name
  • Fixed submissions failing with a server error when a field shares its name with the section holding it
  • Fixed the contributor guide's outdated description of how form field types are structured
  • Fixed the security guide overstating the protections applied to submissions from logged-in visitors
  • Changed the custom CSS field of a form to advise styling from the site instead, and fixed two wrong hints
  • Secured the results CSV export against spreadsheet formula injection from submitted values
  • Fixed custom form styles being dropped when a rule used quotes, '>' or an attribute selector
  • Improved diagnostics: a condition whose source field was deleted is now reported in the server logs
  • Fixed the upgrade guide and developer documentation drifting from the released behavior
  • Fixed a display glitch when a form intro or message contains rich text
  • Removed the unused submission metadata definitions (IP address, user agent, username); old stored values are kept
  • Fixed a newly created fieldset offering no way to add fields from the Page Builder
  • Improved failed submissions: the form now stays on screen with its values so visitors can simply retry
  • Fixed form elements leaving a stray identity value on each translation, which made content-integrity scans fail
  • Improved the content list offered inside a form: fields are grouped together, apart from steps and blocks
  • Fixed the Page Builder create buttons of a form, which showed technical names for field, content and step types
  • Fixed removing a form from a page: deleting now removes the reference, and Go to source opens the form
  • Fixed conditions and labels being altered on native fields that reuse the migration's value-realignment path
  • Fixed submissions being rejected after a section was hidden while a field inside it had its condition met
  • Fixed forms refusing to send while a required choice field was hidden by conditional logic
  • Removed a misleading unused dependency declaration from the form modules' build files
  • Fixed fields hidden by a visibility rule staying editable: rules no longer apply while a form is being edited
  • Improved the conditional logic editor: aligned fields, searchable selectors, errors shown on the faulty rule
  • Changed rule saving so a visibility rule whose target was never chosen is removed instead of hiding the field

    Rules whose reference is filled but invalid are kept and shown in error in the editor.

  • Changed the maintenance message to replace the form: nothing can be retried while the platform is read-only
  • Fixed choice option values diverging between languages: every language now shares the default language's set

    Options are authored in the site's default language; every other language receives that list and translates only the labels. The options list is no longer required, so visiting another language never blocks saving a form field.

  • Fixed dates shown one day early in confirmation messages for visitors in timezones west of UTC
  • Fixed numeric-looking answers such as postal codes being reformatted in confirmation messages
  • Fixed a field upgraded from an earlier version ignoring every later publication on the live site
  • Fixed an upgrade issue where option lists translated before the upgrade lost their labels in other languages
  • Fixed choice options and date bounds of 0.3-era forms staying unmigrated after the upgrade
  • Fixed multi-step forms briefly showing the wrong buttons before the page finished loading
  • Fixed conditional logic ignoring all but the innermost condition when sections with conditions are nested
  • Changed the Page Builder boxes: field groups share one colour, the field list keeps the default look
  • Hardened submissions: uploads are only accepted on file fields, and only forms accept submissions
  • Fixed a harmless error logged at startup during an upgrade before all form modules were updated
  • Fixed slider values losing their localized formatting in confirmation messages
  • Fixed the upgrade guide to cover the definition warning shown when updating from older versions
  • Improved the automatic module re-enabling to run once per site, so deliberately disabling it afterwards sticks
  • Fixed access to form results: granting or revoking the reader role now takes effect after publication
  • Fixed two simultaneous first submissions splitting a form's results in two
  • Improved the results screen and exports: submission values follow the order of the fields in the form
  • Improved the reliability of the built-in results reader role titles
  • Fixed conditions showing an empty value in languages whose migrated option lists still diverge
  • Fixed conditions written before the upgrade never matching again once their option values were unified
  • Fixed accented characters showing as garbled text in the sample options source labels
  • Improved help texts and validation messages so they behave consistently across all field types
  • Fixed snapshot builds presenting themselves as the final release, which blocked installing the actual release
  • Improved the custom options-source guidance: a static localized list replaces the repository-reading example
  • Fixed hiding the steps indicator also disabling step-by-step display and validation
  • Fixed step titles disappearing everywhere when the steps navigation option is turned off
  • Fixed translated option labels being lost when a migrated choice field was first saved after the upgrade
  • Secured file type detection by upgrading an embedded third-party library flagged by vulnerability scanners
  • Improved the upgrade guide with the recovery path for modules installed in the wrong order
Requires Jahia 8.2.2.0Released 2026-09-08