Introducing the Node Base Field Display Manager for Drupal

Why I Created Node Base Field Display Manager

The Problem

One of Drupal's long-standing design decisions is that base fields like title, created, and uid don't appear in the Fields UI under "Manage display" by default. While this enforces certain architectural principles about entities, I've always found it confusing and overly restrictive.

The thinking behind this appears to be:

All entities must have a label (the entity's identifying field)
For nodes, that label is called title
The title is important enough that it should be handled separately from custom fields

This creates a divide between "core" fields and "custom" fields that I find arbitrary and frustrating.

The Inconsistency

Beyond the philosophical debate about special-casing the title, there's a practical inconsistency that creates cognitive burden for developers:

Base Fields vs. Custom Fields

Base fields (defined in Node::baseFieldDefinitions()):

// Accessing base fields - no field_ prefix
$title = $node->title->value;           // or $node->getTitle()
$created = $node->created->value;       // or $node->getCreatedTime()
$author_id = $node->uid->target_id;     // or $node->getOwnerId()

// In Twig templates
{{ node.title.value }}
{{ node.created.value }}
{{ node.uid.entity.name.value }}

Custom fields (created via Field UI):

// Accessing custom fields - note the field_ prefix
$first_name = $node->field_first_name->value;
$last_name = $node->field_last_name->value;
$email = $node->field_email->value;

// In Twig templates
{{ node.field_first_name.value }}
{{ node.field_last_name.value }}
{{ content.field_first_name }}

The Real-World Impact

This creates several problems:

1. Inconsistent naming conventions: Developers must remember which fields are "special" and handle them differently in code and templates.

2. Hidden from Field UI: Base fields like title, created, and uid don't appear in "Manage display" by default, even though they're rendered on every page.

3. No formatter control: You can't apply different formatters to the title in different view modes, limit its length, or add custom classes without custom preprocessing.

4. Can't reorder or hide: Want the title below the body? Want to hide it on teasers? You need custom template overrides instead of using the drag-and-drop UI like every other field.

Code Comparison: The Inconsistency in Practice

Here's how the same operation differs between base fields and custom fields:

Hiding a Field in Manage Display

Custom field (field_first_name):

✅ Go to /admin/structure/types/manage/article/display
✅ Drag "First name" to "Disabled"
✅ Field is hidden

Base field (title) - WITHOUT this module:

❌ Field doesn't appear in Manage Display at all
❌ To hide it, you must either:
   - Override node.html.twig template
   - Use hook_preprocess_node() to unset variables
   - Install a contrib module

Base field (title) - WITH this module:

✅ Go to /admin/structure/types/manage/article/display
✅ Drag "Title" to "Disabled"  
✅ Field is hidden (assuming your theme uses {{ content }})

What This Module Does

Node Base Field Display Manager uses hook_entity_base_field_info_alter() to call setDisplayConfigurable('view', TRUE) on base fields:

function my_module_entity_base_field_info_alter(&$fields, EntityTypeInterface $entity_type) {
  if ($entity_type->id() == 'node') {
    $fields['title']->setDisplayConfigurable('view', TRUE);
    $fields['created']->setDisplayConfigurable('view', TRUE);
    // ... etc
  }
}

From the Drupal API documentation:

"By default, Field UI only shows fields that are attached to the entity through the field API... However entity fields can be made configurable in field UI by defining them as FieldConfigInterface instances."

This module makes base fields configurable without converting them to full field config entities, using the lighter-weight setDisplayConfigurable() API.

Important Note: Theme Compatibility

For the Field UI settings to actually control rendering, your theme's node.html.twig should render via {{ content }} rather than explicitly using {{ title }}, {{ date }}, etc.

Modern themes (Olivero, Claro, most custom themes) already do this.

Older themes may need the enable_base_field_custom_preprocess_skipping flag added to the theme's .info.yml file, or a template override to use {{ content }} instead of separate variables.

See the module README for details on theme configuration.

Why This Matters

What I want is simple:

Consistent treatment of all node fields, whether base or custom
Complete control over displays without arbitrary assumptions
Ability to use the Fields UI for all fields, not just custom ones
Reorder, hide, or format the title using the same drag-and-drop interface as every other field

Node Base Field Display Manager exists for developers who share this frustration. If you've ever been confused by the inconsistency between title and field_first_name, or felt constrained by Drupal's special handling of base fields, this module treats them like any other field in your content type.

Technical Details

The setDisplayConfigurable() API has been available since Drupal 8.0, and is documented as the recommended approach for making base fields appear in Field UI. This is different from making fields "configurable" (which creates field config entities), and is specifically designed for this use case.

There is a long-term intention in the Drupal community to make more base fields display-configurable by default (see issue #2353867), but until then, developers need to explicitly enable this functionality.