Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The UI text on admin/structure/types/manage/listing/fields/field_subheading/field-settings is going to really overwhelm the average user so I want to tidy this up.
Comment | File | Size | Author |
---|---|---|---|
#15 | field_ui_no_descriptions-614294-15.patch | 3.61 KB | yched |
#13 | field_ui_no_descriptions-614294-10.patch | 2.5 KB | Bojhan |
#10 | field_ui_no_descriptions-614294-10.patch | 2.47 KB | yched |
#6 | afterFieldDesc.png | 10.02 KB | lisarex |
#6 | uifielddesc_614294_6.patch | 1.21 KB | lisarex |
Comments
Comment #1
lisarex CreditAttribution: lisarex commentedadded tags
Comment #2
lisarex CreditAttribution: lisarex commentedComment #3
yched CreditAttribution: yched commentedThat one is actually for field_ui, Lisa ;-)
Comment #4
yched CreditAttribution: yched commentedAnd I think this is in fact a duplicate of #563998: Field UI: no way to set the translatable property.
[edit: hmm, maybe I was too quick, it depends on exactly which UI text you want to improve. If that's the one about translatable field, then #563998: Field UI: no way to set the translatable property is the issue]
Comment #5
lisarex CreditAttribution: lisarex commentedThanks yched.
I updated the title. I will only tackle the text that appears at the top of the page, e.g. 'Boolean: This field stores simple on/off or yes/no options.' and my personal favorite 'Text: This field stores varchar text in the database.' ;)
This will likely need to be several patches but I'll just start with this one!
After screenshot attached, before screenshot is in the main issue.
Comment #6
lisarex CreditAttribution: lisarex commentedOK, following some discussion in IRC, Bojhan & I think these descriptions are not useful where they currently appear, *after* someone has created a field. If someone is unclear about the type of field they are creating, they should check in Documentation, since there is no good place to describe Boolean, Float, the 3 list types, etc in this interface.
This patch removes the 'description' from Text, Long text and Long text and summary (currently visible at admin/structure/types/manage/article/fields/body/ and admin/structure/types/manage/article/fields/body/field-settings)
Note that the field label and colon are still present and serve as a reminder of what type of field it is... I think they could do w/ a bit more styling though (position it evenly vertically within whitespace would be good!)
Now we find out if the descriptions are used elsewhere in core....
Comment #7
yched CreditAttribution: yched commentedreporting/developping what I said on IRC:
+1 for removing this. The place where this info currently shows up makes no sense. You should see those help texts *before* you create the field, they're here to help you pick a field type...
Problem is, we didn't really find a good place to display it :-/. It's information you need to see when picking a field type. But the field type picker being a select, there's no obvious place for this info.
Possibly a JS-updated string "somewhere" on the 'Manage Fields' screen when you select a field type. Browers don't react on 'hover' on select options.
Or maybe a 'more informations on field types' link opening a popup. This would stay in line with #87994: Quit clobbering people's work when they click the filter tips link / #609094: Popups for the "More Help" links if they get in.
This being said, big -1 to removing the 'description' strings in hook_field_info() themselves. We want to keep those for now (and possibly adjust them when we know where they'll end up). We just want to *not* display them at the top of field edit forms. This happens in field_ui.admin.inc, field_ui_field_edit_form() and field_ui_field_settings_form().
Comment #8
yched CreditAttribution: yched commentedThus, CNW.
+ kind of related: #622614: Consider reducing the number of field types
Comment #9
Bojhan CreditAttribution: Bojhan commented@yched Do you have a patch to not display them? I agree we might not have to actually remove the text, but more guidance for us (who are not awsome php programmers) to achieve this - might be helpful.
Comment #10
yched CreditAttribution: yched commentedHere's a patch.
Comment #12
sundrupal_set_title() does check_plain() by default now.
This review is powered by Dreditor.
Comment #13
Bojhan CreditAttribution: Bojhan commentedFixed tha_suns comment, lets hope that makes a greeny test
Comment #15
yched CreditAttribution: yched commentedNeed to fix the test accordingly.
Comment #16
sunComment #17
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks!