WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#31021 closed enhancement (wontfix)

Introduce discrete capability for managing custom background and header

Reported by: westonruter Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Customize Keywords: has-patch dev-feedback 2nd-opinion
Focuses: administration Cc:

Description

As with Customizer (#28605), management of nav menus (#29213), and managing widgets (#31020), the management of the Custom Header and Custom Background currently requires edit_theme_options capability, a capability associated with administrators which grants the power to make many wide sweeping changes. There should be a discrete capability manage_custom_header and manage_custom_background which is inherited for anyone who has edit_theme_options by default.

Attachments (1)

31021.diff (23.6 KB) - added by westonruter 6 years ago.
https://github.com/xwp/wordpress-develop/pull/65

Download all attachments as: .zip

Change History (8)

#1 @westonruter
6 years ago

  • Keywords has-patch dev-feedback added; needs-patch removed

In 31021.diff

  • Build on patches for #29213 and #31020
  • Add manage_custom_background and manage_custom_header caps which by default are assigned to those who can edit_theme_options.
  • Use new caps for Ajax requests
  • Use new caps for accessing theme admin pages
  • Use new caps for admin bar links
  • Supply empty string as capability for Customizer sections related to custom header/background so that the capabilities of their controls will bubble up to activate/deactivate the section.

The change specifically for this ticket in isolation from the patches form the other tickets is https://github.com/xwp/wordpress-develop/commit/e7e2c67e5d1aa4bdfd04f8b37ab36ac68d4c10e5

#2 @celloexpressions
6 years ago

This seems unnecessary to me - headers and backgrounds fall fairly closely under theme options, so I don't know that controlling them by an additional capability makes sense. I don't know why someone would have access to either of those but not any other theme options, for example.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


6 years ago

#4 @celloexpressions
5 years ago

  • Keywords 2nd-opinion added

Also with custom logos now, I don't think distinct capabilities for every smaller core theme options feature is a sustainable approach, or particularly useful. Does anyone else have an opinion?

This ticket was mentioned in Slack in #core by sergey. View the logs.


5 years ago

#6 @greenshady
5 years ago

I can't think of a reason to split off with custom caps for headers and backgrounds. These are theme options. I can't recall any particular instance where a user has needed to allow these to be customized but not allow access to other theme options.

#7 @celloexpressions
5 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Going to close for now as it should also be possible to change the capability on the associated settings and controls in the customizer directly if there is a rare situation where these need to be decoupled from edit_theme_options, but in terms of core background and header images are pretty directly considered theme options, as opposed to menus and widgets being more significant standalone features. With minimal activity here, let's focus on trying to get menus and widgets their own capabilities before re-evaluating whether there's a core need for this.

Note: See TracTickets for help on using tickets.