Revamp descriptions of items in handler listings

Here's a first go at a couple of these descriptions for the 'Add fields' listing to give an idea of what we're aiming to do here:

---

## Current:

Content: Add comment link
Display the standard add comment link used on regular nodes, which will only display if the viewing user has access to add a comment.

Content: All taxonomy terms
Display all taxonomy terms associated with a node from specified vocabularies.

Content: Author uid
The user authoring the content. If you need more fields than the uid add the content: author relationship

Content: Body
Appears in: node:page, node:article.

Content: Comment count
The number of comments a node has.

Content: Comment status
Whether comments are enabled or disabled on the node.

---

## Rewrite

Add comment link
Display the standard add comment link used on content.

All taxonomy terms
Display all terms assigned to a piece of content.

Author uid
The user authoring the content.

Body
Used in the Page, X, Y and Article content types.

Comment count
The number of comments to a piece of content.

Comment status
Whether comments are enabled or disabled.

Patching these in seems to be a good novice task.

I'd be happy to have a go at this. I have a few questions though:

@yoroy Do you really mean that it's better to leave the word denoting the filter category off the item name, e.g. "Content: "? It seems to me that we need that to distinguish between items with the same name in different categories, right? E.g. "Content: Title" and "Content revision: Title".

Also, for the Body item description - "Used in the Page, X, Y and Article content types." - do you suggest including a list of every content type that has a body? I know it does that at the moment but may be far too verbose with a lot of content types?

@Bojhan Would you suggest creating subtasks for this? Split by category - Content, Content Revision, Comment, Global etc?

I've included a patch with yoroy's suggestions - more to check that I've understood correctly than because I think it contains enough to be useful at the moment.

Thanks all!

Ah - it looks as though listing every content type a field appears on is well established functionality, so I guess that answers my question regarding the Body item description.

+++ b/core/modules/comment/comment.views.incundefined
@@ -525,7 +525,7 @@ function comment_views_data_alter(&$data) {
-      'help' => t('Display the standard add comment link used on regular nodes, which will only display if the viewing user has access to add a comment.'),

Oh yes, noone cares about that detail.

+++ b/core/modules/node/node.views.incundefined
@@ -384,7 +384,7 @@ function node_views_data() {
-    'help' => t('The user authoring the content. If you need more fields than the uid add the content: author relationship'),

The question is why this information is not helpful for the user? Many people struggle with that, so why not give them a hint here.

+++ b/core/modules/taxonomy/taxonomy.views.incundefined
@@ -372,7 +372,7 @@ function taxonomy_views_data_alter(&$data) {
+      'help' => t('Display all terms assigned to a piece of content.'),

Great improvement!

Thanks eddie_c! Patch looks good to me so far.

As for splitting, Content is by far the biggest category, and since this is such a simple patch it might be easier to keep it as one issue for now?

Per #1832862: Make views add field scannable proposes to split category into it's own column (yay) hence why yoroy wrote the item names without the category in front.

'The user authoring the content. If you need more fields than the uid add the content: author relationship'

How about something like 'The user that wrote the content. 'author relationship' provides additional fields'

That's fine for me!

The first technical hurdle is probably to make descriptions optional in the first place. Views now sets a default "this item has no description lalalalaa" description for every handler in views_fetch_fields().

The attached patch prevents the default Error: missing help message from being shown as handler help.

#12: 1832858_00.patch queued for re-testing.

But then we probably need some testing.

Would be cool to have #1962234: [Change notice] Move views_fetch_fields into an autoloadable class in first, as it touches exactly the same code. Once it's ported writing tests would be potentially better to do.

Well, bring people to the other issue, but this issue also just have a really old patch, which will not apply at all,
need tests, for some reasons etc. Well, let's work on both at the same time.

NW as per #14.

add link to related parent issue

...parent issues now have a dedicated metadata section ;)

I went through the add field ui. I was hesitant to change some of the ones that were defined as descriptions instead of help, cause that text may show up somewhere else.
Note that removing descriptions may no longer be necessary, because of the table layout introduced in the parent issue. That may make it even more necessary to have short help text, to fit into a smaller space in the table column.
Didn't go through the remaining UI screens other than Add Field. Felt like I should get some feedback before investing more time into this.

i have rerolled the patch in #20 it was an automerge

working on this on drupaldevdays

I rerolled the patch from #21

Made a new patch that also check if there is any description before trying to add it to the description field.

Re-roll patch from #29

Another reroll

queued for re-testing

Would be cool to have #1962234: [Change notice] Move views_fetch_fields into an autoloadable class in first, as it touches exactly the same code. Once it's ported writing tests would be potentially better to do.

Issue 1962234 Committed b15e921 and pushed to 8.x. But is Active: pending change record

Does this impact how the patch 1832858-31.patchis re-rolled??

Re-rolling and slightly refactoring patch from #32.

Just a quick scan of the current changes

1. +++ b/core/modules/comment/comment.views.inc
   @@ -35,7 +35,7 @@ function comment_views_data_alter(&$data) {
   +          'help' => t('Display comment link if user has permission.', $args),
   

   this no longer has args, so the $args can be removed

2. +++ b/core/modules/comment/src/CommentViewsData.php
   @@ -265,7 +265,7 @@ public function getViewsData() {
   +      'help' => $this->t('Datetime when posted.'),
   

   Datetime is too technical a term for help text I would say, I kinda like the original text here.

3. +++ b/core/modules/comment/src/CommentViewsData.php
   @@ -279,7 +279,7 @@ public function getViewsData() {
          'title' => $this->t("Last comment author"),
   -      'help' => $this->t('The name of the author of the last posted comment.'),
   +      'help' => $this->t('Author name.'),
   

   Mew. The title is pretty bad, but with the bad title I feel the more verbose help is needed

4. +++ b/core/modules/comment/src/CommentViewsData.php
   @@ -309,7 +309,7 @@ public function getViewsData() {
   +      'help' => $this->t('Most recent comment or entity update.'),
   

   Shouldn't we try to stay away from the term 'enitity'? Also might be nice to mention if this is a date or a 'date and time' (don't know what it is).

5. +++ b/core/modules/comment/src/CommentViewsData.php
   @@ -339,7 +339,7 @@ public function getViewsData() {
          'title' => $this->t('Last comment uid'),
   -      'help' => $this->t('The User ID of the author of the last comment of an entity.'),
   +      'help' => $this->t('User ID.'),
   

   wouldn't it be better to not use 'uid' in user facing text? So maybe update the title?

I'm pretty sure there are more things we can fix here. The first list was made a while back, so might be good if somebody looked through this again to see if we can update some more.

Also, not sure about the 'needs tests' here, I don't think we want to add tests that test the correct help text. As long as we have coverage that setting the 'help' key in views data displays the message (pretty sure we do), we are fine I think.

Thanks for the unexpected quick response @Lendude. A new patch is attached with the following changes.

1. Removed $args
2. Changed to: 'Date and time when the last comment was posted.'
3. Changed to: 'Name of the author of the last comment.'
4. Changed to: 'Most recent comment.'
5. Changed to: 'The User ID of the author of the last comment.'

About 5, I don't think this is user-facing text. We are dealing with Help texts here, right? These are for admins and editors. So I think we're good.

I agree that there are «more things we can fix here». I'm open to suggestions, where should I look? What can I do about «not sure about the 'needs tests' here», can you expand?

#47 patch is also working fine for drupal 9.1

Goot to move to RTBC

Rerolled for 9.5

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Patch #54 is working fine for Drupal version 10.1.x

It does not apply with git apply, which is what the bot uses to check.

Was previously tagged for tests which still need to happen.