Add a tag select list in string Formatter

Added title formatter as mentioned in proposed solution , this 'll add title formatter for plain type field for manage display , working on test coverage part in which cover if title formatter selected for field type , then it linked to title or not.on the basis of selected config.

Added title formatter as mentioned in proposed solution & added test coverage as well for title formatter, apart form nothing seems to be left.

PLease review, moving NR

Saw this one early, left some comments.

Thank for reviewing, working on it

Addressed the feedback, left one comment on MR. PLease review, moving NR.

Responded to comment

Will also need change record.

Thanks for reviewing. working on the feedback.

Nice to work on issues in the Modernization effort. Thanks!

This is changing the UI so adding Usability tag. As a new form this should have a Usability review as well, so adding that tag. And screenshots available from the issue summary.

Tried to address feedback, Added: validation constrains, change records, screenshots in IS.

MR is mergeable, however there is validation config warning that shows this is 'field.formatter.settings.title', added which is correct , so it seems it is just message not any error message displaying here. PLease review, moving NR.

Code wise don't see anything but leave in review for usability

Could a site builder end up creating a situation where they set the sub title to use h2 and then the hierarchy no longer matches between teaser and page views?

- Page
- h1: Node Title via page-title
- h2: Sub title
- Teaser
- h1: Page title
- h2: Node title
- h2: Sub title

Could a site builder end up creating a situation where they set the sub title to use h2 and then the hierarchy no longer matches between teaser and page views?

- Page
- h1: Node Title via page-title
- h2: Sub title
- Teaser
- h1: Page title
- h2: Node title
- h2: Sub title or h3: Sub title (whatever selected in tag of title formatter in specific form mode like here teaser, 'll render on FE)

Yes I have verified it is possible, correct me if I 'm missing anything.

I am not able to reproduce issue , not getting Title dropdown

Steps to followed
1. Added Plain text filed in Article.
2. Configured in manage display , not getting title Drop down in Format column fort "Title".
3. Adding screenshot for reference.

+1 for adding this feature, so it would make easier to land the parent issue.
Left suggestion also to add H6 -level element.

I assume #18 was missing a cache clearance.

h6 tag by mistaken missed added back, Please review moving NR

Usability review

We discussed this issue at #3472580: Drupal Usability Meeting 2024-09-13. That issue has a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @AaronMcHale, @benjifisher, @rkoller, @shaal, @simohell, @worldlinemine, and @zetagraph.

We like the idea of giving site builders more flexibility in how plain-text fields are displayed. Once the parent issue is done, it will be much easier for site builders to create a consistent heading hierarchy, which will be a big a11y improvement.

Our main recommendation is that we improve the existing (default) formatter for plain-text fields instead of adding a new one. That is, add the select list of tags to the existing formatter. I read the comments on this issue and on the parent issue, and I did not see any discussion of this option. Is there any reason to have a separate formatter?

For backwards compatibility, we will have to add an option (for example, - none -) and make that the default.

A minor advantage of improving the existing formatter is that we do not have to decide how to name (or label) the new one. Naming things is hard, and it is generally best to name things after what they do. The proposed label in this issue is "Title", which is how you expect to use it rather than a description of what it does.

Our other recommendations are

1. Use "Display as" as the label for the select list.
2. Remove the description field (help text). In general, we try to make our labels clear enough that we do not need help text.
3. In the summary description, use "Displayed as …". This will be more consistent with the existing text "Linked to the Content".

Once this issue is implemented, people are likely to ask for additional options: <p> and <code> and so on. This seems like a good idea for a follow-up issue: either a hook that modules can implement or some global configuration that site builders can choose in order to change the list of available tags.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

Thanks for reviewing it, I agree , we can simply enhance the existing formatter rather than introducing new one. In proposed solution section written

Create a TitleFormatter

so I thought need to create new one.

I believe along with one mentioned feedback need upgrade path as well , as we are enhancing existing formatter, feel free to add anything that needs to be taken care along with these changes.

I would not mind being able to select a tag for the plain text formatter to do this. But what about setting a class, or settings for field/wrapper elements? I am thinking of the Fences module.

@poojah_sharma:

If the default "none" option is represented in the database as no entry (as opposed to an entry of "none") then I am not sure we need an upgrade path. At least, if "upgrade path" means an update (or post-update) function.

In proposed solution section written ... so I thought need to create new one.

Any issue on d.o is a cooperative effort. We often think of better solutions before an issue is fixed, so do not assume that the current proposed resolution is the final one. If you have a better idea, then suggest it. Since we are changing the resolution, we should update that section of the issue summary. I am adding the tag for that. I probably should have done that with my previous comment.

@mortona2k:

I am also a fan of the Fences module, and we looked at it during the usability meeting. But let's not expand the scope of this issue to include everything that Fences provides. The current scope is enough to advance the parent issue. If you want all the features of Fences, then install it, and if you think that should be part of core then open a new issue to discuss it.

In fact, once the parent issue is fixed, you should be able to install the Fences module and then add CSS classes to your node titles (and not just nodes).

@benjifisher, I missed the point, like better solution is to add same tag in existing formatter instead of creating new one, thanks for the feedback, 'll try to keep address these points as well.

Try to addressed the requested changes , update issue summary as well. as we have used '-None- as by default so when I try save entity from "manage form" page then is no any error encountered , I guess no need to add upgrade path as well.

PLease review, moving NR.

Added test coverage in existing kernel test instead of creating new functional test considering performance perspective.

Please review, moving NR.

Resolving conflicts, verifying functionality

Resolved MR conflicts, functionality seems working fine.

Please review , moving NR.

Hi,
Changes has been verified in the issue fork branch. working has expected to the branch.
Before Branch:

After: Branch:

But the patch 9341.patch is failing in the Drupal 11.x branch. Please find the screenshot for the more understanding.

I think all threads should be resolved now.

Issue credits, including those from UX meeting
Crediting @manibharathi ezhimalai ravi for manual testing

This is a great feature. We need to add an upgrade path.

This should take the form of a post update hook that makes use of the config entity updater.

There should also be a test that asserts the value isn't set before running update, and then checking it is set.

There's a good example of a similar update hook (also for entity view displays) here https://git.drupalcode.org/project/drupal/-/merge_requests/10002/diffs#2...

This MR also contains a good example of an upgrade path test - https://git.drupalcode.org/project/drupal/-/merge_requests/10002/diffs#2...

Unfortunately it doesn't look like there are any instances of this formatter in use in the standard profile, so that means you will have to create a new database dump/fixture file. \Drupal\Tests\views\Functional\Update\EntityArgumentUpdateTest in core has an example of how to add additional test fixtures to the default standard dump.

The docs have more information on how you can do that - https://www.drupal.org/docs/drupal-apis/update-api/writing-automated-upd...

@larowlan, Thanks for reviewing , working on it

I fixed a typo and changed the resolution from being a question to a statement in the proposed resolution that made it difficult for me to understand without reading the code.