Introduce customize capability for accessing Customizer

Description

Currently, access to the Customizer is restricted to users who can edit_theme_options. Settings also get registered with a default capability of edit_theme_options. However, settings do allow plugins to supply a different capability. Nevertheless, edit_theme_options is usually synonymous with users who are Administrators, and so if a plugin wanted to register a setting (with an edit_posts capability) for a user with a lesser role (e.g. Editors) to be able able to edit in the Customizer, the plugin would be prevented from doing so unless it granted edit_theme_options to Editors as well. This is undesirable.

Therefore, it is suggested that a new customize capability be split out from edit_theme_options. By default it can be added only to the Administrator role, but if a plugin wants to register a setting for another role to be able to edit, they may then have the option of giving the customize capability to users with that role as well.

I agree that there should be a capability for accessing the theme customizer, but I don't agree on the naming you propose. In my opinion, customize_theme would be better-suited for this. With customize, it's unclear what's being targeted, it could be anything. One could argue that naming it access_theme_customizer, use_theme_customizer or even theme_customizer would be even better, as it implies even more that it's about the theme customizer and not just about "customizing" a theme (which could mean anything).

I agree that there should be a capability for accessing the theme customizer, but I don't agree on the naming you propose. In my opinion, customize_theme would be better-suited for this. With customize, it's unclear what's being targeted, it could be anything. One could argue that naming it access_theme_customizer, use_theme_customizer or even theme_customizer would be even better, as it implies even more that it's about the theme customizer and not just about "customizing" a theme (which could mean anything).

One of the purposes behind having something other than edit_theme_options for the customizer is to avoid making the assumption that everything in the customizer is theme-related. While that is largely the case now in core, several plugins introduce customizer controls that are not theme-related, and some of these may be brought into core in the future. customize would allow access to the Customizer itself, but individual sections and controls would still have distinct capabilities assigned to them for granular control over access.

Basically, we'd like to shift away from the term Theme Customizer and toward just Customizer for the thing and Customize for the action. Even now, anything that's stored as an option rather than a theme_mod has implications beyond the current theme, and plugins should consider using the customizer in place of custom settings pages if their options are mostly visual.

I agree that there should be a capability for accessing the theme customizer, but I don't agree on the naming you propose. In my opinion, customize_theme would be better-suited for this. With customize, it's unclear what's being targeted, it could be anything. One could argue that naming it access_theme_customizer, use_theme_customizer or even theme_customizer would be even better, as it implies even more that it's about the theme customizer and not just about "customizing" a theme (which could mean anything).

+1 @celloexpressions

Also, the term “Theme Customizer” is nowhere to be found in Core for the Customizer API. There are a few instances of the term appearing in code comments or in translatable strings appearing in the UI, but for the underlying Customizer API the namespace is just “customize”, so this seems the most logical name for an associated capability.

Given the current work and future plans for the Customizer, I think we should try to get this in sooner rather than later. The fact that customize could be anything is kind of the point here; the Customizer can be used for pretty much anything in WordPress if you try hard enough, and within the Customizer access to different panels, sections, and settings can be managed at a high level of detail. Decoupling the customizer from edit_theme_options is an important first step to making better use of the Customizer, for both theme-related and theme-independent options. I doubt the capability parameters in the Customizer API have been used much at all because everything is restricted to such a high capability currently.

Moving to 4.0 for now, as this is conceptually pretty critical for the long-term goals in improving the Customization experience (see also an upcoming make/core post from @westonruter). If lead devs/committers have issues with this we can push it back.

In lieu of making this a new primitive capability, what if it were a meta capability mapped to 'edit_theme_options'?

This would allow for things like this:

current_user_can( 'customize', 'theme', $stylesheet )

current_user_can( 'customize', 'post', $post_id )

At the moment, we should go with 'customize' with no additional arguments, I'm just showing the potential future usage.

For now, 'customize' only refers to themes, so it would map to 'edit_theme_options'. In the future, though, it might be used for a particular post. (At least in plugins for the foreseeable future.)

I'd rather not add a new capability here as capabilities are not a great experience (custom roles don't get them automatically), and "customize" isn't very primitive — customizing *what* is the question, and to answer that question, we already have it in the form of edit_theme_options, edit_posts, etc.

Only show Customize link in admin menu and admin bar if can edit_theme_options (and customize).

Add cap checks for edit_theme_options and customizeto other links to the Customizer. Needed because customize cap may be removed from users who normally can access it (those who can edit_theme_options).

Plugins will need to explicitly add links to the Customizer in the admin menu, in the admin bar, and elsewhere when users are explicitly granted the customize cap.