Follow up for
#967566: Several important Core User settings need to implement hook_field_extra_fields() β
Problem/Motivation
(copied from
#967566-155: Several important Core User settings need to implement hook_field_extra_fields() β
could use clarification where needed)
some of the extra fields only appear conditionally. However:
1) The entire definition and appearance of extra fields is pretty poor right now in the first place: A seemingly random description Γ la "Contact module form element." appears in a table column that has the label/heading "Field type". One should ask why the actual field type isn't "Fieldset" or "Details" or "Fieldgroup". The textual description that appears for extra fields is a user interface bug in the first place, if you'd ask me.
2) All other (real) fields are bound to field access constraints, too. They do not denote that in the UI either. Thus, I don't see why extra fields should try to explain that either. Doing so would only increase the problem of those descriptions, since i) real fields do not have a description at all, ii) some (but not all!) of the extra field descriptions would be a huge wall of text, and iii) there's very limited space available to begin with.
Proposed resolution
Clarify that some fields may not necessarily appear in Field UI overview
Remaining tasks
- Clarify context/problem/proposal
- ...
User interface changes
(new or changed features/functionality in the user interface, modules added or removed, changes to URL paths, changes to user interface text)
API changes
(API changes/additions that would affect module, install profile, and theme developers, including examples of before/after code if appropriate)