Dynamic Fieldset
A dynamic fieldset is a fieldset in Content Editor that displays the fields specific to a case only once the editor has selected that case in an earlier field. Within a single content type, not every field applies to every item. The form stays short when the case needs nothing more and becomes complete when the situation calls for it.
Definition and how it works
For an editorial team the benefit is concrete, with fewer irrelevant fields to scroll past and fewer gaps in the fields that matter. It also means one content type instead of several near-identical variants to maintain. For the technical team, the model is simpler to evolve.
Technically, a dynamic fieldset is the visual representation of a mixin, a set of properties added to a content type. When a given value is selected, the mixin is enabled and its fields appear. The Academy uses a real estate example, in which selecting "house" as the home type can reveal a "garden size" field. Developers declare this behavior in their module, with the mixin in the content type definition and its trigger in the choice list. Editors simply make the choice.
Academy documentation: creating dynamic forms in Content Editor
Related terms: Fieldset · Field · Content Type · Content type definition · Content Editor
Resources that cover this term
Dynamic fieldset vs fieldset: the differences
A dynamic fieldset belongs to the contribution form, the one teams fill in inside Content Editor. It should not be confused with conditional display in a public form, which is handled by Jahia Forms and faces website visitors.
| Concept | Difference |
|---|---|
| Fieldset | An ordinary fieldset is always displayed. A dynamic fieldset depends on a value chosen in another field. |
| Field | A field edits a single property. A dynamic fieldset groups several fields that appear together. |
| Conditional display in Jahia Forms | It controls what a visitor sees while filling in a website form. A dynamic fieldset controls what an editor sees while entering content. |
Dynamic fieldset in practice
A marketing team publishes its events with a single content type. If the editor selects the "Online" format, a dynamic fieldset can reveal the registration link for the streaming platform. If they select "On site", other fields can appear for the address and the room. Nobody fills in a useless field. Site listings and filters still rely on one model.
If the editor then switches from "Online" to "On site", the link already entered is deleted when the content is saved. The team should know this before going live.
Frequently asked questions
Should we create one content type per variant when some fields only apply to part of the content?
Not necessarily. When variants share most of their fields, a dynamic fieldset lets you keep one type and show the specific fields only when they are needed. Separate types remain the better option when variants have genuinely different rendering, permissions or publication cycles. The decision belongs with the developers who maintain the content model.
What happens to values already entered when an editor changes the choice that activates the fieldset?
When the content is saved, Jahia then deletes the values entered in the fields of the removed group, including their translations. The live version keeps them until the next publication. If those values feed site listings, filters or exports, tell editors that changing the choice makes them disappear.
Can an editor set up a dynamic fieldset on their own?
Developers declare the fieldset in their module (the code package installed on Jahia), with the mixin in the content type definition and its trigger in the choice list. Editors only select a value in the form. Adding a new case or new conditional fields is therefore a change to the content model and should be planned as one.