More support to customize user profile edit page

[pampfelimetten]

Right now I can edit the contact methods via the user_contactmethods filter, but I can not modify or remove the Personal Options or the Name Options.
I want to keep the interface as simple as possible for my users, and I don't think that they need to edit this settings at all.
If wp wants to be a cms, it should give me control over this aspect as well.
At least, give me custom css-ids, so I can remove it via css!

[pampfelimetten]

After wds-brad2 suggested to write a css based patch, here it is.
I'm no expert with the backend-styles, so please give me a hint, if I have used a wrong naming scheme.

Code works fine for me, with the following test-css you can hide and unhide every single option:

#form-table-personal-options-title,
#form-table-personal-options-admin-color-scheme,
#form-table-personal-options-visual-editor,
#form-table-personal-options-keyboard-shortcuts,
#form-table-name-title,
#form-table-name-user-login,
#form-table-name-first-name,
#form-table-name-last-name,
#form-table-name-nickname,
#form-table-name-display-name,
#form-table-contact-info-title,
#form-table-contact-info-email,
#form-table-contact-info-url,
#form-table-about-yourself-title,
#form-table-about-yourself-description
{
	display:none !important;
}

With the following test-css you can hide each section:

#form-table-personal-options,
#form-table-name,
#form-table-contact-info,
#form-table-about-yourself,
#form-table-caps
{
	display:none !important;
}

The password table row already got an ID, so I didn't touch it.

Feedback very welcome!

[nacin]

CSS isn't really the way to go here. I think we should abstract it out with filters and default actions, similar to contact methods and the idea in #6837.

[pampfelimetten]

Thanks for the Info, thats what I thought at the beginning as well, but I think this is beyond my skills. Anybody else wants to look into this?

[pampfelimetten]

First Cut, missing only the about yourself section

[pampfelimetten]

please ignore the 12295.002* diff files.
In the 12295.003.diff I abstracted it with filters and functions, you can now enable and disable every field (expect for the last "about-yourself" section, i ran out of time for that).
One open question though: I skipped the class "code" for url field (why is it there anyway?)

And: How to add the disabled function for username? Should I make every function like the "personal options" section, with multidimensional arrays?

Please give me feedback!

[pampfelimetten]

Updated to latest trunk

[pampfelimetten]

Updated to latest trunk

[pampfelimetten]

Update to latest trunk

[JohnONolan]

Updated patch to latest trunk + more IDs

[JohnONolan]

I think this is pretty comprehensive now - only sense-check question I had was, is changing #password to #profile-about-password a problem? I don't think any JS hooks into it, can't find any core CSS targeting it.

[JohnONolan]

One more thing that should be accounted for:

Sometimes plugins add fields to user profiles (eg. After The Deadline and WordPress SEO) - these should be wrapped with divs with unique IDs based on the plugin name so that they can be styled differently or hidden depending on requirements. At present they cannot be targeted in any way at all other than some very unstable :nth-child hackery, which is a small but not insignificant problem.

[pampfelimetten]

Hi John, thanks for updating the patch, I just tested against the latest trunk and it works fine. It would be great if we could get it in 3.4 early!

[Viruthagiri]

Sorry. I'm new to core trac. Can i use this patch? Or should i wait until 3.4 release?

[JohnONolan]

Feedback? 3.5 Early?

[SergeyBiryukov]

Related: #20563

[JohnONolan]

Will literally have sex with the first core dev willing to take a look at my now-10-month-old-super-simple-yet-amazing-patch.

[Japh]

Refreshed

[Japh]

Refreshed @JohnONolan's last patch.

[DrewAPicture]

12295.3.diff​ takes @japh's refresh and:

• Adds requisite spacing to introduced code
• Removes some unnecessary semicolons following closing braces
• Adds phpdoc additions such as the version in @since's and an @param for $user_can_edit on _wp_get_user_personal_options().

[JustinSainton]

• Basic pass at data sanity
• Restores proper toolbar/admin bar language
• Some additional coding standards formatting

[SergeyBiryukov]

#22973 was marked as a duplicate.

[helen]

#7730 was marked as a duplicate.

[SergeyBiryukov]

#16181 was marked as a duplicate.

[ericlewis]

in 12295.5.diff​:

• Move $user_can_edit into _wp_get_user_personal_options to avoid spaghetti code; also removes necessity of a parameter for _wp_get_user_personal_options()
• In _wp_get_user_personal_options(), move global definitions to beginning of function
• In _wp_get_user_personal_options(), using an element with the key of 'action' will trigger that action in the field table cell. The explicit call to do_action for 'admin_color_scheme_picker' was being used, this still allows for this while opening up for extendability
• Fix escaping 'scope' attribute of table headers, add scope element for comment_shortcuts (to avoid PHP notice)
• Remove user_label_add_required() and associated filter - this wasn't in the scope of this ticket.
• Modify _wp_get_user_namefields() to return a multidimensional array; restores disabled attr to username field

[ericlewis]

In 12295.6.diff​:

• The original patch changes the Show Toolbar setting output that's in trunk currently, reverts to this.
• In _wp_get_user_namefields(), add a 'description' key to the namefield array elements, which outputs in a span after the input.

[toscho]

At a first glance I didn't see it: How do we remove the textarea for Biographical Info only now?

[ericlewis]

Replying to toscho:

At a first glance I didn't see it: How do we remove the textarea for Biographical Info only now?

The entire About section has a wrapper div#profile-about, which can be hidden with CSS. The table row for the Biographical info has the unique ID profile-about-description, also can be hidden with CSS.

Ideally, we'd give the same filter-ability treatment for this section. I'd guess because of the uniqueness of the textarea output it wasn't given its own _wp_get_user_aboutfields() in an earlier diff. Should we do that?

[toscho]

It is a ​common request and the current code doesn’t offer an elegant hook. So I think this is the best opportunity to introduce a specific hook.

[ericlewis]

Replying to toscho:

It is a ​common request and the current code doesn’t offer an elegant hook. So I think this is the best opportunity to introduce a specific hook.

The request you linked to is a user asking how to hide it - which can be done with the CSS selectors I mentioned. Whether we should add filterability to the About section to give the ability to add more fields there is what I was asking.

[ericlewis]

In .6, I forgot to change a checked to $echo = false. .7 fixes this

[JohnONolan]

lol.

[ramiy]

Related: #24952

[SergeyBiryukov]

#25383 was marked as a duplicate.

[flabadab]

Using metaboxes would allow for complete customization

[ericlewis]

Replying to flabadab:

Using metaboxes would allow for complete customization

I'm thinking the same thing.

A User is not a post type, but it is a data object in WordPress. We already apply a post-like editing interface for comments, which are also a data object that's not technically a post. I don't see a reason why we couldn't apply the interface to Users. More unified UI.

[Stagger Lee]

I would like to se metaboxes as in Posts/Pages. With 2 columns.
Just those few lines of code in CSS make huge difference in profile screen:

.profile-php #your-profile .form-table {
  background: #fff;
  border-collapse:inherit;
  padding: 20px;
}
  .profile-php #your-profile h3 {
  background: none repeat scroll 0 0 #f1ebd3;
  color: #000;
  padding: 10px 15px;
}

[jvcdk]

I have a similar need / wish and have created a patch against version 5.3.2. Please find it attached.

The approach I have taken is to add a filter (user_profile_active_fields) that a dev can hook in to and customize which fields are shown.

I have uploaded 2 files:

• A patch in git format-patch format (with commit message).
• A "simple" standard diff (since you are using svn)

I am unsure which format serves you best. The files are named 0001-Users-Add-filter-to-hide-fields-from-user-page.diff and .patch.

I believe it is ready for merge, but of course needs a review and test (by other people than just me :-D ). One note:

In the API documentation, I left the @since fields as TBD as I do not know with which version this will be accepted.

[jvcdk]

Patch in "simple" format

[jvcdk]

Patch in git format

[SergeyBiryukov]

#56053 was marked as a duplicate.