Deprecate non-standard display of title and other base fields

Created on 13 October 2020, over 4 years ago
Updated 19 February 2025, about 2 months ago

✨ [META] Expose Title and other base fields in Manage Display Active will introduce the "normal" mechanism for managing display of title and other base fields. In particular #3036862: Expose Title and other base fields in Manage Display in Drupal Core β†’ will create a GUI option to enable the normal mechanism.

This purpose of this issue is to deprecate the old specialist non-standard way. At the point of writing, we haven't even invented the new way yet so this issue is planning ahead and guessing somewhat. However it's likely that it would involve

  1. Warning in the status page if the GUI option is still set to the old specialist non-standard way.
  2. Deprecate all the specific items that will be removed in πŸ“Œ Remove outdated code relating to "Expose Title in Manage Display" Active

We can use the Twig deprecated tag to deprecate templates.

πŸ“Œ Task
Status

Active

Version

11.0 πŸ”₯

Component

entity system

Created by

πŸ‡¬πŸ‡§United Kingdom adamps

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡¦Ukraine Anna D

    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.

  • πŸ‡¬πŸ‡§United Kingdom catch

    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.

  • πŸ‡ΊπŸ‡¦Ukraine Anna D

    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?

  • πŸ‡¬πŸ‡§United Kingdom catch

    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.

  • πŸ‡¬πŸ‡§United Kingdom adamps

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

    Unfortunately yesπŸ˜ƒ. ✨ Add a tag select list in string Formatter Needs review is the likely next step, and it was moving well. But now the next step is a quite complex update hook.

    @catch is there any chance of any funding being available? It probably wouldn't take a huge number of hours to make real progress on the whole META area. Unfortunately it's often too much to do for free.

  • πŸ‡¬πŸ‡§United Kingdom catch

    @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 ✨ Add a tag select list in string Formatter Needs review is blocking) because it is a bit more self-contained.

  • πŸ‡¬πŸ‡§United Kingdom adamps

    Thanks @catch. Let's hope that someone needs this issue enough to be willing to fund it.

    The sequence of events as I understand it is described in ✨ [META] Expose Title and other base fields in Manage Display Active .

    It proposes we next work on phase B stage 1 which is covered by issue ✨ Add formatters and other mechanisms as alternative to base fields directly in entity templates Active . That will involve ✨ Add a tag select list in string Formatter Needs review as the solution for 'title', and it seems quite close to completion. The equivalent for 'submitted' is more complex, however working code does exists in "Manage Display" contrib; it doesn't have its own Core issue yet as far as I know.

  • πŸ‡©πŸ‡°Denmark ressa Copenhagen

    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 ✨ [META] Expose Title and other base fields in Manage Display Active , 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 🌱 Plan for stable release Fixed .

Production build 0.71.5 2024