A number of core user settings are missing support for hook_field_extra_fields() to make fields easily (re)order on the Manage Fields tab. This creates unnecessary work for site developer who will have to manually patch or create custom code to fix this.
Adjust "hook_field_extra_fields" for each core module that may add something to user form (eg: Overlay, Locale, Contact, and the User module)
Patch written, tested, and committed to 8.x, however, chunk of code missing between earlier working patch (#63) and committed patch (#87) so committed patch may be incomplete.
For sites that don't use it, the "Personalize blocks" fieldset will never appear on any user's account pages, but now it will appear on the "Manage Fields" screen for all Drupal sites that use the block module. As a result, we will be asking users to rearrange fields in relation to it even though it doesn't exist.
Is it possible/practical to change the description ['description' => t('Block module form element.'),] to explain that this element will not be present on all user account pages, and do the same for other elements from the patch in #63 that are not always expected to appear?
Backport to Drupal 7.
Determine what code is missing (as per #71).
User interface changes
This patch makes it possible to reorder the settings form for Picture, Signature, Overlay, Contact and Blocks. With fieldgroup module installed it could be possible to customize user account edit page.
Original report by DocuAnt
A number of core user settings are missing support for hook_field_extra_fields() to make them easily organized on the Manage Fields tab. This makes them appear randomly as soon as any reorganizing is made. It also prevents them from being put in for example tabs using the Field Group contrib module.
In short, it severely blocks the intended use of the Manage Fields tab to be able to organize as theme user profile editing and view without the need of custom coding.
The form fields the patch in #33 enables this for is:
- picture (user picture upload)
Practically any site built with Drupal will use at least one of the above form fields. Thus, creating a lot of extra, unnecessary work for site developer having to manually patch or create custom code to fix this.