WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#16004 closed defect (bug) (fixed)

Admin Bar options cannot be removed from the user profile page

Reported by: sorich87 Owned by: nacin
Milestone: 3.1 Priority: normal
Severity: normal Version: 3.1
Component: Administration Keywords: has-patch revert commit
Focuses: Cc:

Description

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.

Attachments (2)

Selection_032.png (49.0 KB) - added by sorich87 3 years ago.
16004.diff (2.6 KB) - added by nacin 3 years ago.

Download all attachments as: .zip

Change History (14)

sorich873 years ago

comment:1 nacin3 years ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to 3.1
  • Owner set to nacin
  • Status changed from new to accepted

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.

nacin3 years ago

comment:2 GaryJ3 years ago

Much nicer solution.

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

Version 0, edited 3 years ago by GaryJ (next)

comment:3 nacin3 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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

comment:4 westi3 years ago

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.

comment:5 follow-up: nacin3 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:6 in reply to: ↑ 5 duck_3 years ago

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.

comment:7 westi3 years ago

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.

comment:8 nacin3 years ago

  • Keywords revert commit added

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

comment:9 nacin3 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

(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.

comment:10 nacin3 years ago

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

comment:11 follow-up: kpdesign3 years ago

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.

comment:12 in reply to: ↑ 11 westi3 years ago

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

Note: See TracTickets for help on using tickets.