Deprecate non-standard display of title and other base fields

W don't need the GUI option, but we have the entity type setting enable_base_field_custom_preprocess_skipping we have introduced (see change record).

To remind us, the essence of the fix so far is to use a preprocess approach like this:

$skip_custom_preprocessing = $node->getEntityType()->get('enable_base_field_custom_preprocess_skipping');
if (!$skip_custom_preprocessing || !$node->getFieldDefinition('title')->isDisplayConfigurable('view')) {
  // Some custom preprocess logic than ignores configured field display.
  $variables['label'] = $variables['elements']['title'];
  unset($variables['elements']['title']);
}

The essence of this is that preprocessing is skipped only if a flag is set AND isDisplayConfigurable is set (neither of which are set by default currently).

A deprecation strategy was proposed by @plach in [#2923701-283):

1. [Introduce a] flag ... enable_base_field_custom_preprocess_skipping
2. ...introduce a check on FieldDefinitionInterface::isDisplayConfigurable() for each entity field. ...
3. Once all core entity types got this treatment, deprecate the enable_base_field_custom_preprocess_skipping flag.
4. Verify whether the current core behavior can be implemented via layout builder (+ maybe custom formatters?) and:
   if at all possible, use that instead of the custom preprocess logic when the flag is enabled; this would make core default's behavior match the current one, but would allow people to configure base field display via the UI;
   if it's not possible to conditionally enable the LB configuration, just deprecate the preprocess logic and suggest to use Layout Builder instead.
5. In D9 remove the flag and the custom preprocess logic, leave only the Layout Builder configuration as default.

Our normal deprecation strategy would be to use @trigger_error($message, E_USER_DEPRECATED) whenever custom preprocessing happens.

Any ideas on continuing work on this issue?

I found that a user:id (node author) cache tag is added to every node. However, the author display is disabled, and a small investigation led me to template_preprocess_node().

By default this function performs special preprocessing of some base fields so they are available as variables in the template. For example 'title' appears as 'label'. This preprocessing is skipped if:
a module makes the field's display configurable via the field UI by means of BaseFieldDefinition::setDisplayConfigurable() AND the additional entity type property 'enable_base_field_custom_preprocess_skipping' has been set using hook_entity_type_build().

This is unclear to me because $submitted_configurable is FALSE in my case (the date and UID fields are not displayed in the view display). As a result, the condition if (!$skip_custom_preprocessing || !$submitted_configurable) is always TRUE.

Additionally, I would separate the date and UID in this case. If only the date is needed, the author (and consequently, the user cache tags) is still added.

That comment suggests that $submitted_configurable needs to be TRUE in order for that logic to be skipped, that might be the specific problem you're seeing?

I think we need to add a 'computed' (extra) field for 'submitted', once we have that, we can deprecate adding it directly in templates.

Adding another related issue.

Yes, and this is not clear to me.

$submitted_configurable = $node->getFieldDefinition('created')->isDisplayConfigurable('view') || $node->getFieldDefinition('uid')->isDisplayConfigurable('view');

The Created On (date) and Created By (uid) fields are not configured to be displayed. However, I need to display them in order to avoid adding a related author cache tag. Is that correct?

You need to alter the field definitions to allow them to be displayed (or install the manage fields module which does this), they don't actually need to be displayed.

All of this logic is in desperate need of updating but several of the issues around it are stalled.

@adamps there is still no way to get direct funding for core development except via individual employers.

The two routes I can think of would be:

1. If there's a demonstrated need for Drupal CMS, then a company might sponsor work via the starshot contribution credits system.

2.Experience Builder must need to control where 'submitted' gets placed in an entity layout at some point, possibly before it can have a stable release, so will hit this problem soon. Likely the same for the title.

Even if not funding, those would be two potential ways to get extra reviewers.

For me personally I think that 'submitted' would be the best place to focus short term efforts rather than title (which I assume #3470497: Add a tag select list in string Formatter is blocking) because it is a bit more self-contained.

Thanks so much for working on this, having "Title", "Authored on", etc. directly available under Display would be such a great feature.

We could consider adding a new header "Funding" in the Issue Summary of important Drupal core issues such as #2353867: [META] Expose Title and other base fields in Manage Display, with a text like this?

Funding

Drupal relies on the community for resources, and the Drupal core developers working on this task are looking for funding. Please contact @developerA or @developerB for further details on timeline and budget.

The companies who sponsors the completion of this task will be listed as sponsors of this feature in the Issue Summary, as well as on drupal.org/issue-sponsors/display-title and receive eternal gratitude from the Drupal community.

It has previously been seen to work, to gently make the users aware, that this great software needs real humans to spend time building it, for example in #3247389: Plan for stable release.