Field Label Visibility (an intuitive approach to editing node forms)

Introduction

Field Label Visibility lets site builders customize, per widget, how a field label element is rendered on a node form, directly from Manage form display. No custom code, no theme overrides, no hook_form_alter(): every option is exposed as a UI control on the widget settings panel.

Unlike the display management tools, this module focuses on form widget labeling rather than front-end entity views.

Features

For each enabled widget, the module provides:

• Hide label — removes the label element entirely from the rendered DOM (not just visually hidden).
• Custom label text, with an optional Singular / Plural mode. When it is enabled, the label is written as Singular|Plural and Drupal core decides which form to show through the plural rules of the active language, using the number of items the field currently holds. Languages whose plural rules define more than two forms are handled by core, not by the module.
• Inline format toolbar with alignment radios (left, center, right) and three formatting toggles (bold, italic, underline), CKEditor-style. Every one of them is rendered as a CSS class shipped by the module; the module never writes inline styles.
• Optional inline wrapper tag applied inside the native label: span, small or mark. These are the only phrasing-content tags valid as label children per the WHATWG specification.
• CSS classes and id textfields, validated when the widget settings are saved.

How it works

The module operates in three modes, all targeting the native Drupal label for="…":

• Default (no wrapper tag). The configured id and CSS classes flow to the native label through Drupal's form-element preprocess pipeline.
• Wrapper (span, small, mark). The label text is wrapped in the chosen tag; the surrounding label for="…" stays in place.
• Hide. #title_display is set to 'none', which tells Drupal core not to render the label at all.

Configuration

1. Navigate to Administration » Configuration » User interface » Field Label Visibility (/admin/config/user-interface/field-label-visibility).
2. Select the content types where the per-widget controls should appear.
3. Save the configuration.
4. Open Structure » Content types » [type] » Manage form display, click the gear icon next to any field widget, and configure the options.

The settings page requires the Administer Field Label Visibility permission, which is restricted by default.

Security and accessibility

CSS classes and the id are validated when the widget settings are saved: a class token is rejected when Drupal\Component\Utility\Html::cleanCssIdentifier() does not return it unchanged, and an id is rejected when it does not start with a letter or is not a valid CSS identifier.

The values are checked again before being rendered:

• The wrapper tag is restricted to an allowlist (span, small, mark).
• CSS class tokens are filtered with Html::cleanCssIdentifier().
• The id is discarded when it is not a valid CSS identifier.
• Alignment is restricted to left, center and right.
• The label text is escaped before being injected.

The module never breaks the accessible name of the input: in every mode the original label for="…" is either preserved (with custom text and/or attributes) or completely removed from the DOM.

Differences with similar projects

• Field UI (Drupal core) — reorders fields and selects widgets on Manage form display, but offers no per-widget control over how the field label itself is rendered.
• Field Group — groups several fields under a shared wrapper; it does not act on the label of an individual field widget.
• Field Formatter Class — adds CSS classes to display formatters, that is, to the front-end rendering of an entity, not to entity forms.
• Display Suite — works on the entity render pipeline through layouts and view modes; it does not expose label controls on the form display.
• hook_form_alter() or a custom preprocess — reaches the same result, but requires writing and maintaining PHP in a custom module.

Field Label Visibility makes the same outcome reachable for site builders directly from the UI.

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.