Problem/Motivation

As explained in the parent META issue #2353867: [META] Expose Title and other base fields in Manage Display, the node template directly includes markup for the title and submitted information. This is not compatible with enabling these base fields to be configurable via the field UI. The same is true for various other entity type base fields.

As part of the solution for fixing that, we need a mechanism to reproduce a comparable and equivalent appearance. Plus we need this mechanism to be very easy to enable/configure without adding any extra dependencies. There are two cases that together can solve all core entity types looking pretty close to how they do already (excluding the aggregator module due to #3267458: Deprecate aggregator module in Drupal 9.4).

  1. Title: with configurable tag and option to link to the entity. Used on many entities.
  2. "Submitted": based on the "Author" formatter with additions. There is an optional user picture, and a wrapping sentence "Submitted by UUU on DDD", which includes the creation date. Used on node, comment, and could also apply to media.

Proposed resolution

There are many possible ways to solve this (see below under remaining tasks for other possibilities). For this issue, we need something simple, generating close to equivalent markup, and without forcing extra dependencies (such as Layout Builder). This unblocks the path forward for #3036862: Expose Title and other base fields in Manage Display in Drupal Core and #3176673: Deprecate non-standard display of title and other base fields - we can only deprecate the old way once we have created a new equivalent.

Custom formatters seem like the right answer.

  • They can be enabled/configured quickly in the UI.
  • It's possible to use them as the default in baseFieldDefinitions(), entity_form_display.*.yml, or custom hooks.
  • If a site doesn't want to use them, they don't get in the way.
  • They support powerful customisation with templates and hooks.
  • The code is simple and already written/tested in the contributed module Manage Display.

Copy the Title and Submitted formatters into core. Not much needs changing except to add tests.

Remaining tasks

We can cover some more advanced and sophisticated options for "Submitted" in follow-on issues. People can add many other possibilities in contrib modules. The [italic bracketed text] explains why each one wasn't chosen for this issue.

  1. Create a custom Layout Builder block. [Forces use of Layout Builder]
  2. Use hook_entity_extra_field_info(). [See below]
  3. Create a general mechanism for combining fields?? [Longer-term initiative that will take time]

The extra field option could work, but when examined in detail, it seems less suitable for "Submitted". It could be a good option in a Contrib module.

  • Extra fields don't currently allow settings (in particular to configure the user picture).
  • The extra field would combine/wrap the output of the underlying fields (uid and created). It works best if they don't have configurable display - which would not be acceptable for Core. (Reasons are: the extra field relies on the underlying fields having specific display settings; having the extra field and the separate fields in Manage Display is confusing.)

Comments

AdamPS created an issue. See original summary.

pancho’s picture

pancho
Location UTC+2 🇪🇺 EU
commented

Just to make sure nothing gets lost.

In #2923701-283: Mechanism to disable preprocessing of node base fields so they can be configured via the field UI, @plach proposed A: Layout builder

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.

In #287, @AdamPS proposed B: manage_display

The contrib module manage_display contains formatters that exactly replicate the current core behavior without the need for layout builder. There are new custom formatters for "title" and "submitted". I hope that these can eventually become part of core.

In #289, @plach answered re manage_display

Not sure about the "Submitted by XXX on YYY" output TBH. The fact that it involves two fields makes me think that a custom formatter might not be the right choice, as formatters are designed to handle a single field.

In #292, myself answered re Layout builder:

I'm not overly confident this is a good idea. Last time I tested it, Layout Builder was far away from being stable enough to be enabled on default or worse: (more or less) forced on site-builders.

and re manage_display:

True, but as plach said, formatters on their own can't handle multiple fields. manage_display uses a custom preprocessor, too.

and instead proposed C: config extra fields:

In this case, this would mean adding a super-super-basic "Display Suite" (also a bit like "Field Group") kind-of API and UI to Core that allows creating configurable extra fields to combine two or more real fields into one, possibly using field tokens. This would be sooo awesome, and would by the way allow for properly replacing (not just deprecating) current custom 'submitted' preprocessing without forcing Layout builder on anyone.

In #293, @AdamPS replied:

LB can implement something beautifully styled with a custom block however nothing here is forcing anyone to use LB; contrib modules can implement something a bit hacky (yes I will admit to that) but that works well in the short term; there might be other ideas using calculated fields or hook_entity_extra_field_info() or yes even inventing entirely new mechanisms.

In the end, I guess, whatever gets most traction and is doable within due time (ahead of D8 LTS) should be the way to go.

pancho’s picture

pancho
Location UTC+2 🇪🇺 EU
commented
Title: Add formatters and other mechansisms as alternative to title and submitted directly in node template » Add formatters and other mechanisms as alternative to title and submitted directly in node template
Related issues: +#2953656: No ability to control "extra fields" with Layout Builder

Following #2953656: No ability to control "extra fields" with Layout Builder, layout builder can cope with extra fields now, so a one-off extra field would be among the easiest solutions.

However, what I was thinking about is a way to create and edit extra fields in the UI (Core case would be: to combine two fields into one with some extra text). My idea was that they would live in a particular form resp. view mode, just as fieldgroups do.

Let's figure out if that's doable in a very lightweight yet flexible way.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

adamps’s picture

adamps commented
Title: Add formatters and other mechanisms as alternative to title and submitted directly in node template » Add formatters and other mechanisms as alternative to base fields directly in entity templates
Issue summary: View changes

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

aaronmchale’s picture

aaronmchale
Primary language English
Location Edinburgh, Scotland
commented

I like the idea of a "submitted" computed field, or even just a new field type for "submitted", something that other entity types can easily reuse.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

catch’s picture

catch
he/him
Primary language English
commented

hook_entity_extra_field_info()/computed seems like it might be a decent option, and could be used for any entity that both has published and author fields via respective interfaces? Does that get us a layout builder block 'for free', not sure how layout builder handles extra fields..

Another issue is the author picture on comments which is also in preprocess.

aaronmchale’s picture

aaronmchale
Primary language English
Location Edinburgh, Scotland
commented

Does that get us a layout builder block 'for free', not sure how layout builder handles extra fields..

I think it does, LB seems to expose all of the available fields if I remember correctly.

adamps’s picture

adamps commented
Issue summary: View changes

There are very many possibilities. Some almost work already in Core (Layout Builder?); some are available in contrib modules (Manage Display); some are more likely a longer term initiative (general mechanism for combining fields?). This issue could easily get stuck in an enthusiastic debate about the merits of each one - so how can we avoid that?

Well we could look at this issue as the minimum simple outcome that would allow the initiative #2353867: [META] Expose Title and other base fields in Manage Display to move forward. People can add more sophisticated mechanisms in other issues, or in contrib.

My feeling is that the answer is the two custom formatters: title and submitted. I've updated the IS in that direction. Please can people take a look and make comments?

geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented

Thanks @AdamPS for elaborating that.
+1 for dont-use-extra-fields. They are a very odd child, they don't even have labels builtin.
The reasoning in the IS makes perfectly sense to me, and unless we get a better contra-reasoning, i fully support the proposed approach.

catch’s picture

catch
he/him
Primary language English
commented

The only issue with the submitted formatter for uid is that while it applies to the uid field, it's pulling information from other fields it has to assume exist. I installed manage_display to try things out and this caught me out for a second (was looking for an 'extra field').

However, we can make it available only on entity types that have those fields (in core it'd be nodes and eventually comments too), it's much less weird than the hard-coded preprocessing + template variable.

So I think overall it's a big net UX and API improvement, even if we might want to open follow-ups to add another mechanism later. We definitely shouldn't postpone it on some kind of 'combine fields' system.

adamps’s picture

adamps commented

Thank you both for the comments.

in core it'd be nodes and eventually comments too

It should work on Core node, comment and media (not even "eventually" - it should work right now).

However, we can make it available only on entity types that have those fields

If the created field is not present then the formatter still works, it just misses out the "on " part.

I am currently planning to make two enhancements to the code in SubmittedFormatter:

  1. Use an entity key 'created' instead of a hard-coded field name 'created' (which fortunately works for the 3 core entities, but might not be true always).
  2. Allow the admin to choose a date format, rather than inheriting the setting of the 'created' field (which might be hidden or not display configurable).

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

catch’s picture

catch
he/him
Primary language English
commented
Issue tags: +Field UX
adamps’s picture

adamps commented
Issue summary: View changes

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.