[UX] Add human name to fields list at admin/reports/fields

[jenlampton]

I often struggle finding the field I need on the fields list, because over time the machine name sometimes strays from the human readable label. I think we should add a column to the field list to include the human-readable label.

Here's an example of a site that's been upgraded from Drupal 6:

---

PR by @klonos: backdrop/backdrop#2324
PR by @opi: backdrop/backdrop#2528 (based on klonos' 2324 with table sorting)

[klonos]

When the same field is reused across multiple content types (bundles in general), it might have different labels. So a single label per field instance is not applicable in all cases. I have filed a PR that does the following:

• Splits the "(module: xyz)" to a column of its own (better readability, and we could allow sorting in the future)
• Adds the priority-low class to the new "Module" column, so that it is hidden on tablet (leaving the class of the "Field type" column as priority-medium so that it is hidden only on mobile).
• Renders the items in the "Used in" column as a list.
• Appends "(field label: xyz)" at the end of the bundle name/link

Here's what it looks like:

[klonos]

...while working on this ticket, I have noticed the following:

• It is possible to enable sorting in the columns of a table rendered via theme_table(), but only if the table is a product of db query. I have filed a feature request to allow sorting for all tables: [DX] Allow sorting in all tables rendered via 'theme_table()' #3317

• The "Used in Views" tab only lists the comment_body field used in the "Recent comments" view. Filed a separate ticket for that: Reports: Fields: "Used in views" list is not listing fields in system/administration views #3318

[olafgrabienski]

When the same field is reused across multiple content types (bundles in general), it might have different labels. So a single label per field instance is not applicable in all cases.

Good point!

• Appends "(field label: xyz)" at the end of the bundle name/link

I like the solution but I'm not sure if the prefix "field label" is necessary. To be less verbose, I'd suggest to drop it or to write just "label". Let's compare:

body | Text (long with summary) | Text | Layout Node (field label: Teaser)

body | Text (long with summary) | Text | Layout Node (label: Teaser)

body | Text (long with summary) | Text | Layout Node (Teaser)

[klonos]

Thanks for the review @olafgrabienski 👍

...yeah, I also initially thought to use just label:, but having that next to the content type label seemed confusing from a new Drupal/Backdrop user point of view (implies that the label is for the content type). No prefix at all is even worse if you ask me.

Having said that, I am OK to changing this to whatever works best, but lets wait for more feedback before changing anything.

[klonos]

...another idea is to have the entries in that column use a more "human" language. I have updated the PR:

• "Used in" column renamed to "Used as"
• entries use the format [field name] in [bundle] ("Teaser in Layout node" for example)
• [field name] is rendered in italics and is now a link to the configure form of that field in the respective bundle.
• the previous version of the PR was not using t() for the "field label:" string, so it would not have been possible to translate it. I now have used t() properly.

Here's how it looks:

Feel free to give it another spin @olafgrabienski 😉

[olafgrabienski]

entries use the format [field name] in [bundle]

Great idea, I like it! (Also the other suggestions.) I've had a quick look at the sandbox site, looks good!

[opi]

Nice ! I wonder about the use of italic, but looks good otherwise 👍

[klonos]

Thanks for the review guys 👍

@opi if you check the comment I have left in my PR, you will see that I am referring to a condition that checks for $admin_path, which was there before my PR. This either renders the field/bundle names as links, or as plain text (I am not sure what is the use case when this can happen). Now when mentioning names of things in help text or elsewhere using t(), we are usually rendering them by using a % placeholder instead if @, which makes them render in italics. We do this in /admin/structure/views for example, in the "View info" column where we render the various display names in italics. Also in various messages in the form of "The [thingy_name] [thingy] has been saved", like this for example:

Anyway, I am not adamant about it; we can remove the italics.

PS: I am working on updating the PR to allow all columns besides the "Used as" one as sortable (90% there). Please keep the reviews of the current PR coming, if there is anything that you thing I should change.

[klonos]

I have given the table sorting another go, but cannot get it to work. I have pushed my code in the PR, which does render the column headers as (seemingly) sortable, but the actual sorting is not happening. Can I please get a second pair of eyes to figure out what I might be doing wrong?

I have looked in the documentation and comments available at https://api.drupal.org/api/drupal/includes%21theme.inc/function/theme_table/7.x and also related sources in the internetz, like https://drupal.stackexchange.com/questions/14889/can-tablesort-be-used-without-a-query but cannot figure out what I'm missing.

[jenlampton]

Doesn't table sorting use database sorting? If these aren't in the database anymore (these are all config files now, right?), tablesort won't work here.

[opi]

@klonos here's a PR with table sorting : backdrop/backdrop#2528

[klonos]

Thanks @opi ...RTBC 👍

PS: I did leave a small comment re a tiny coding standard fix (missing period at the end of a comment), but that should not stop this from RTBC 😉

[opi]

PS: Commited in my browser, thanks to Github awesome UI !

[klonos]

thanks to Github awesome UI !

Yeah, I really love that too @opi 😄

This is truly RTBC now.

[klonos]

...if #3620 gets accepted, we should revise the PR here to use that 😉

[quicksketch]

Merged backdrop/backdrop#2528 into 1.x and 1.12.x. Thanks @klonos and @opi! I wasn't sure about the tablesort usage, it did seem a little out of ordinary but it worked well in practice in my testing.