Field Label Visibility (an intuitive approach to editing node forms)
This module allows site builders to customize how field labels appear on node forms, directly from the manage form display settings. It provides options to hide labels, use custom text, add styling like bold or alignment, and apply inline wrapper tags, all without writing code.
You build content types in Field UI, and sooner or later a form label gets in the way: a name editors read differently from visitors, a label that only repeats the group it sits in, a heading that should stand out. Field Label Visibility puts those controls where you already are, in the gear panel of each widget on Manage form display, for the content types you choose. No theme override, no hook_form_alter(), no PHP.
It is complete on its own: no account, no key, no external request. Tick a content type and every widget of that type gains the controls. Your public pages stay as they are: the module acts on node add and edit forms only.
What you get
- Hide the label. The
<label>element is not emitted, on every value of the field. It takes precedence: when checked, the other controls fold away. - Custom label text. Replaces the field label on the form, up to 255 characters, on every value of a multi-value field.
- Singular or plural. Turn on Singular / Plural and write
Comment|Comments; core's plural rules for the active language pick the form from the number of values the field holds. If either side is empty, the text is shown as written. - An inline wrapper tag.
<span>,<small>or<mark>inside the native label. The list is short on purpose: these are phrasing content and do not change the accessible name; headings or<p>are not valid inside a label and are not offered. - CSS classes and an id. Validated when you save the widget and checked again before rendering.
- Alignment and bold, italic, underline. A small toolbar of native radios and checkboxes, styled with the icons Drupal core's CKEditor 5 module ships, at home in Claro and Gin. Each choice becomes a utility class; no inline style is ever written.
- A summary on the form display table. Label hidden, Label: Comments, Tag: span, Format: Bold / Italic, at a glance.
- Configuration that travels and leaves cleanly. Exported configuration with typed schema; uninstalling strips the settings from every form display.
How it works
Three modes, all on the form widget. In default mode the custom text becomes the field title and the id, classes and format classes are merged into the native <label for="…">, so the link with the input stays intact. In wrapper mode the text is escaped and wrapped in the chosen tag inside that label, which carries the attributes. In hide mode the label is removed from the DOM: the input then has no accessible name, so keep it for fields whose surrounding markup already explains them. One limit to know first: the module is scoped to the node entity type; media, taxonomy, user and other entity forms are not altered.
Use cases
- An editorial team that wants form labels in its own words, without the theme knowing about it.
- A field whose label repeats the group it sits in, where the label is only noise.
- A themer who wants a class, or a bold centred heading, on one label without a preprocess function.
Getting started
- Grant Administer Field Label Visibility to the roles that configure content types; the permission is marked restricted.
- Go to Administration » Configuration » User interface » Field Label Visibility (
/admin/config/user-interface/field-label-visibility), tick the content types and save. - Open Structure » Content types » [type] » Manage form display, click the gear beside a widget, set the label options and save.
Requirements
- Drupal 10.3 or newer, including Drupal 11, and the PHP version that release of core requires. Every hook this module declares as an attribute also has a procedural bridge, which is what keeps the older branch working rather than silently doing nothing.
- The core Field and Node modules. No contributed module, library or external service.
composer require drupal/field_label_visibility, then enable the module.
Privacy and security
- Stores configuration only: the enabled content types in
field_label_visibility.settingsand third-party settings on each widget of the form display. No content, no personal data, no HTTP request, no credentials. - The settings page needs Administer Field Label Visibility; the widget options sit behind core's own form display permission.
- Values are validated on save and sanitised again at render time: tag allowlist, class tokens through
Html::cleanCssIdentifier(), id dropped unless valid, alignment from a fixed list, label text treated as text. A kernel test runs script, attribute-breakout, image andjavascript:payloads through every field. - Uninstalling removes the module's third-party settings from every form display.
Similar projects and how this one differs
- Entity Form/Display Field Label gives a field a different label per form or display mode; no hiding, wrapper tag, classes, id, alignment or plural forms.
- Change labels rewrites several widget strings (label, "Add another item", buttons); it works on the text, not on the label markup.
- Form display field alter overrides label, help text or required per form display; it does not change how the label element is rendered.
- Hide Field Label hides widget labels, one of the options here; at the time of writing it has no supported release.
- Field Label does a comparable job on Manage display, the view side, and states that it does not support form displays. This module is its form-side counterpart.
Development
Parts of this module were written with the assistance of AI-based coding tools, as required by the policy on the use of AI when contributing to Drupal. All the code has been read, corrected, tested and is maintained by the human maintainer listed below, who takes full responsibility for it.
Maintainers
Maintained by pedroromán. Issues, ideas and contributions are welcome in the issue queue.
Depends on
Dependencies of the latest stable release
- field Drupal core
- node Drupal core
Required by
Tracked projects that depend on this one
No tracked projects depend on this one yet.