Profile contains options that don't apply to users with "subscriber" role

[jivany]

For a user with the "subscriber" role, the Profile page contains three options under the "Personal Options" heading:

• Visual Editor
• Admin Color Scheme
• Keyboard Shortcuts

"Visual Editor" does not apply to a subscriber as they cannot write posts. This option does not need to be presented to a subscriber.

"Admin Color Scheme" is redundant as the two options presented to the subscriber are the same (both the "bold" and "subtle" colour options are the same).

"Keyboard Shortcuts" does not apply to a subscriber as they are not able to moderate comments.

Observed in Version 2.7-almost-rc-9965

[jivany]

Whoops. "Admin Color Scheme" behaves the same way for a user with "admin" role (both the "bold" and "subtle" colour options are the same). I'm not sure if this is by design or not.

[kpdesign]

I also would like to see the Personal Options section hidden on the Profile page if the user is assigned to the Subscriber role. There is nothing there that is applicable to a subscriber, and it can be confusing to some users.

[janeforshort]

The admin color scheme palettes just hadn't been updated yet. If someone can see the admin tool at all, they should have the ability to change their color palette selection if they want to.

[kpdesign]

I agree Jane about the color palette, but the Visual Editor and Keyboard Shortcuts have no functionality for a user at the Subscriber level, and really should not be displayed on the Profile page to anyone who is assigned that role. Is it possible to get that change worked in to 2.8?

[janeforshort]

If someone will write a patch to remove visual editor and keyboard shortcuts from subscriber role profile, would be nice to have, so users wouldn't wonder what they're for.

[janeforshort]

Punting due to feature freeze. Reconsider with next release.

[westi]

Patch broken by change to just use the IS_PROFILE_PAGE in [11359], once fixed works a treat.

[westi]

(In [11447]) Hide options from users when they don't make any sense for them. Fixes #8433 props Denis-de-Bernardy.

[wnorris]

the capabilities 'edit_post' and 'edit_page' expect to be passed a specific post ID. If absent you get notices like:
Notice: Trying to get property of non-object in .../wp-includes/capabilities.php on line 822

The correct capabilities to use are 'edit_posts' and 'edit_pages' (plural). Patch attached.

[ryan]

The all_post_types filter used in other places. We should drop the filter here since posts and pages (with the "s") aren't post types.

[ryan]

Quick, untested patch.

[Denis-de-Bernardy]

Replying to ryan:

The all_post_types filter used in other places. We should drop the filter here since posts and pages (with the "s") aren't post types.

Where? I had checked before adding it. :-)

[Denis-de-Bernardy]

Just for info, the reason I had used post and page, rather than posts and pages, was that these filters worked too (I must confess I hadn't checked for the notice), and that made sense to filter that thingy so as to allow plugins to add custom post types if needed.

[ryan]

Actually, it's hierarchical_post_types I was remembering. Regardless, these aren't post types.

[ryan]

How about leaving the filter off for now and adding some generic post type registration in 2.9? There are several places where that would be handy.

[Denis-de-Bernardy]

third patch is up with a slightly different approach.

[Denis-de-Bernardy]

Replying to ryan:

How about leaving the filter off for now and adding some generic post type registration in 2.9? There are several places where that would be handy.

Works too, if you don't want it around immediately. In that case, we'd commit 8433.2.diff, and get meet up IRC in early 2.9 to work out where we want them, and ensure we've consistent filter names across the board.

[Denis-de-Bernardy]

Sheesh, it's getting late over here. I can barely write english anymore, and I'm still coding. :D

[ryan]

(In [11477]) Fix notice. Props wnorris. fixes #8433

[ryan]

Went with the most conservative fix for 2.8.