Admin Bar options cannot be removed from the user profile page

[sorich87]

When the admin bar is hidden via code, the options are still shown on the user profile page and they do nothing. This is confusing for the users. We need a filter to remove them.

See attached screenshot.

[nacin]

We at first had a bunch of filters that allowed them to be individually or collectively hidden. It made it overly complex.

But instead of a filter to remove it, let's just use a filter to add it. Patch attached.

[GaryJ]

Much nicer solution.

To be picky, the first two _e() references in 16004.diff need some whitespace love for consistency.

[nacin]

(In [17161]) Move the admin bar profile preferences to a hook. fixes #16004.

[westi]

I'm not a big fan of this change.

We really need a solid api for this and the same for option pages which make it easier to remove/add things from settings/user settings pages.

[nacin]

This change doesn't prevent a user from sending the variables through a POST request.

Ideally edit_user() should be modified to inspect has_action( 'personal_options', '_admin_bar_preferences' ) and if false, then pull the settings from get_userdata(). That feels ugly though.

[duck_]

Replying to nacin:

This change doesn't prevent a user from sending the variables through a POST request.

Ideally edit_user() should be modified to inspect has_action( 'personal_options', '_admin_bar_preferences' ) and if false, then pull the settings from get_userdata(). That feels ugly though.

See the original patch on #15829 for something similar with apply_filters before we got rid of those.

[westi]

I think we should revert [17161] and move on to addressing this better in 3.2 with a proper api for the page.

I don't want to have to maintain this method as back compat.

Someone can disable changing of the options using css to hide and hooks on the metadata updates for now.

[nacin]

+1 on a revert. Let's put an ID on the table row though.

[nacin]

(In [17234]) Revert _admin_bar_preferences() and add a class to the table row to allow it to be hidden. Forcing the use of CSS at least attempts to ensure that the developer will recognize that the saving aspect isn't handled. Handle this in the future across all settings screens. Reverts [17161]. fixes #16004.

[nacin]

(In [17235]) Err, oops. Put the class on the table row. props yoast, see [17234], see #16004.

[kpdesign]

Thanks for adding the class to that table row. Being able to hide it via CSS is a plus.

Would it also be possible to add a class to the personal options h3 heading and table as well (i.e., personal-options) to allow the entire personal options section to be hidden via CSS? I currently use javascript to hide the whole section in my plugin, but using a CSS solution would be preferred.

[westi]

Replying to kpdesign:

Thanks for adding the class to that table row. Being able to hide it via CSS is a plus.

Would it also be possible to add a class to the personal options h3 heading and table as well (i.e., personal-options) to allow the entire personal options section to be hidden via CSS? I currently use javascript to hide the whole section in my plugin, but using a CSS solution would be preferred.

This sounds like a good idea - please open a new ticket for it