creationx/cixformconditions

Conditional visibility for TYPO3 form framework elements (show/hide a field or text depending on another field's value).

Maintainers

Package info

github.com/creationx/cixformconditions

Type:typo3-cms-extension

pkg:composer/creationx/cixformconditions

Transparency log

Statistics

Installs: 0

Dependents: 0

Suggesters: 0

Stars: 0

Open Issues: 0

Security

Advisories: 0

Aikido package health analysis

dev-main 2026-07-01 11:39 UTC

Requires

Replaces

  • typo3-ter/cixformconditions: dev-main

GPL-2.0-or-later 93fa93d03f7e55efb4d730e94a0089116bc5bf37

Published on Packagist.org on 2026-07-01 11:39 UTC

This package is auto-updated.

Last update: 2026-07-01 11:39:17 UTC

README

Conditional visibility for TYPO3 form framework elements. Bedingte Sichtbarkeit fĂŒr Elemente des TYPO3 Form Frameworks.

TYPO3 12 LTS TYPO3 13 LTS License: GPL-2.0-or-later

🌐 English · Deutsch

English

Show or hide a form element – an input field or a static text – depending on the value of another field in the same form. The frontend reacts live while the user fills the form, and the server-side validation is kept consistent.

What it does

For any supported form element you can configure, directly in the backend form editor:

  • Steuerfeld (controlling field) – the identifier of the field this element depends on, e.g. singleselect-1.
  • Wert (value) – the value that field must equal (==) for this element to be shown.

At runtime:

  • Frontend (live): conditional-visibility.js shows/hides the element as the controlling field changes. While hidden, the required attribute is removed so the browser cannot block submission of a hidden field.
  • Server-side: an event listener adds a form variant that removes the element's validators whenever the controlling field does not hold the expected value, so a hidden required field can never block form submission.
  • No-JS fallback: without JavaScript every element stays visible; its required constraint is only enforced while the condition is met.

How it works

Concern Implementation
Editor fields Configuration/Form/FormSetup.yaml (Inspector-TextEditor per element type)
Data attributes in markup Overridden Field/Field.html, StaticText.html, ContentElement.html
Live show/hide Resources/Public/JavaScript/conditional-visibility.js
Server-side validation Classes/EventListener/AddConditionalVisibility.php (Creationx\Cixformconditions; variant on AfterFormDefinitionLoadedEvent)
Editor + FE config + JS registration ext_localconf.php (module.tx_form + plugin.tx_form + page.includeJSFooter via addTypoScriptSetup, global – no site set / site TypoScript required)

The condition is stored non-destructively as properties.conditionalVisibility on the element; the variant is derived at runtime and never written to the YAML.

Installation / integration

The extension is fully autonomous – it needs no site set and no site TypoScript.

  1. composer require creationx/cixformconditions (or add a path repository under extensions/ and require :@dev).
  2. Everything is registered globally in ext_localconf.php via addTypoScriptSetup(): the backend editor config (module.tx_form), the frontend config (plugin.tx_form) and the frontend JavaScript (page.includeJSFooter).
  3. Flush all caches (the form configuration and TypoScript are cached). The inspector fields and the frontend script only take effect after a cache flush.

Supported element types

Text, Textarea, Email, Telephone, Url, Number, Date, SingleSelect, MultiSelect, RadioButton, Checkbox, MultiCheckbox, StaticText, ContentElement.

Current limitations (MVP)

  • Only the == operator (equals). Multiple accepted values can be given as a comma-separated list (equals-any); other operators are a later step.
  • The controlling field is entered as an identifier; a dropdown of sibling fields is planned for phase 2.
  • Chained conditions (A controls B controls C) are not an explicit target yet.
  • Containers (e.g. GridRow) are not handled directly; put the condition on the individual elements inside the row.
  • Template overrides target the default version1 frontend template variant.

Requirements

  • TYPO3 12.4 LTS or 13.4 LTS
  • typo3/cms-form

License

Released under the GPL-2.0-or-later license.

Deutsch

Blende ein Formularelement – ein Eingabefeld oder einen statischen Text – abhĂ€ngig vom Wert eines anderen Feldes im selben Formular ein oder aus. Das Frontend reagiert live, wĂ€hrend der Nutzer das Formular ausfĂŒllt, und die serverseitige Validierung bleibt konsistent.

Was es macht

FĂŒr jedes unterstĂŒtzte Formularelement konfigurierst du direkt im Backend- Formulareditor:

  • Steuerfeld – der Identifier des Feldes, von dem dieses Element abhĂ€ngt, z. B. singleselect-1.
  • Wert – der Wert, den das Steuerfeld haben muss (==), damit dieses Element angezeigt wird.

Zur Laufzeit:

  • Frontend (live): conditional-visibility.js blendet das Element ein/aus, sobald sich das Steuerfeld Ă€ndert. Solange es ausgeblendet ist, wird das required-Attribut entfernt, damit der Browser das Absenden nicht wegen eines versteckten Feldes blockiert.
  • Serverseitig: Ein Event-Listener fĂŒgt eine Formular-Variante hinzu, die die Validatoren des Elements entfernt, sobald das Steuerfeld nicht den erwarteten Wert hat. So kann ein verstecktes Pflichtfeld das Absenden nie blockieren.
  • Fallback ohne JS: Ohne JavaScript bleibt jedes Element sichtbar; die required-Vorgabe greift nur, solange die Bedingung erfĂŒllt ist.

Wie es funktioniert

Bereich Umsetzung
Editor-Felder Configuration/Form/FormSetup.yaml (Inspector-TextEditor je Elementtyp)
Data-Attribute im Markup Überschriebene Field/Field.html, StaticText.html, ContentElement.html
Live Ein-/Ausblenden Resources/Public/JavaScript/conditional-visibility.js
Serverseitige Validierung Classes/EventListener/AddConditionalVisibility.php (Creationx\Cixformconditions; Variante ĂŒber AfterFormDefinitionLoadedEvent)
Editor- + FE-Konfig + JS-Registrierung ext_localconf.php (module.tx_form + plugin.tx_form + page.includeJSFooter via addTypoScriptSetup, global – kein Site Set / Site-TypoScript nötig)

Die Bedingung wird verlustfrei als properties.conditionalVisibility am Element gespeichert; die Variante wird zur Laufzeit abgeleitet und nie in die YAML geschrieben.

Installation / Einbindung

Die Extension ist vollstĂ€ndig autonom – sie benötigt weder ein Site Set noch Site-TypoScript.

  1. composer require creationx/cixformconditions (oder ein Path-Repository unter extensions/ einrichten und :@dev requiren).
  2. Alles wird global in ext_localconf.php ĂŒber addTypoScriptSetup() registriert: die Backend-Editor-Konfiguration (module.tx_form), die Frontend-Konfiguration (plugin.tx_form) und das Frontend-JavaScript (page.includeJSFooter).
  3. Alle Caches leeren (Formularkonfiguration und TypoScript werden gecacht). Die Inspector-Felder und das Frontend-Skript greifen erst nach einem Cache-Flush.

UnterstĂŒtzte Elementtypen

Text, Textarea, Email, Telephone, Url, Number, Date, SingleSelect, MultiSelect, RadioButton, Checkbox, MultiCheckbox, StaticText, ContentElement.

Aktuelle EinschrÀnkungen (MVP)

  • Nur der Operator == (gleich). Mehrere zulĂ€ssige Werte können als kommagetrennte Liste angegeben werden (equals-any); weitere Operatoren folgen spĂ€ter.
  • Das Steuerfeld wird als Identifier eingegeben; ein Dropdown der Geschwister- Felder ist fĂŒr Phase 2 geplant.
  • Verkettete Bedingungen (A steuert B steuert C) sind noch kein explizites Ziel.
  • Container (z. B. GridRow) werden nicht direkt behandelt; setze die Bedingung an die einzelnen Elemente innerhalb der Zeile.
  • Template-Overrides zielen auf die Standard-Frontend-Template-Variante version1.

Voraussetzungen

  • TYPO3 12.4 LTS oder 13.4 LTS
  • typo3/cms-form

Lizenz

Veröffentlicht unter der Lizenz GPL-2.0-or-later.