WordPress.org

Make WordPress Core

Opened 9 months ago

Closed 8 months ago

#28605 closed enhancement (fixed)

Introduce customize capability for accessing Customizer

Reported by: westonruter Owned by: ocean90
Milestone: 4.0 Priority: normal
Severity: normal Version: 3.4
Component: Customize Keywords: has-patch commit
Focuses: Cc:

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.

Attachments (6)

28605.diff (9.1 KB) - added by westonruter 9 months ago.
Introduce customize capability for access to Customizer. Commit: https://github.com/x-team/wordpress-develop/commit/c4058b5c36ed60a784dd53ce1059e65b4f3e51bd Part of PR: https://github.com/x-team/wordpress-develop/pull/20
28605.1.diff (10.5 KB) - added by westonruter 8 months ago.
Replace use of primitive cap with meta cap. PR amended: https://github.com/x-team/wordpress-develop/pull/20
28605.2.diff (10.5 KB) - added by westonruter 8 months ago.
Refresh patch. PR amended: https://github.com/x-team/wordpress-develop/pull/20
28605.3.diff (15.7 KB) - added by westonruter 8 months ago.
PR amended: https://github.com/x-team/wordpress-develop/pull/20
28605.4.diff (12.1 KB) - added by ocean90 8 months ago.
Remove whitespace fixes, show help only when edit_theme_options && customize
28605.5.diff (13.7 KB) - added by ocean90 8 months ago.

Download all attachments as: .zip

Change History (22)

comment:1 @westonruter9 months ago

  • Keywords has-patch added

Initial patch in 28605.diff.

comment:2 follow-ups: @engelen9 months ago

  • Keywords 2nd-opinion added

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

comment:3 in reply to: ↑ 2 @celloexpressions9 months ago

Replying to engelen:

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.

comment:4 in reply to: ↑ 2 @westonruter9 months ago

Replying to engelen:

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.

comment:5 @celloexpressions8 months ago

  • Keywords 2nd-opinion removed
  • Milestone changed from Awaiting Review to 4.0

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.

comment:6 @nacin8 months ago

  • Keywords 2nd-opinion added
  • Type changed from feature request to enhancement

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.

comment:7 @ircbot8 months ago

This ticket was mentioned in IRC in #wordpress-dev by helen. View the logs.

@westonruter8 months ago

Replace use of primitive cap with meta cap. PR amended: https://github.com/x-team/wordpress-develop/pull/20

comment:8 @westonruter8 months ago

In 28605.1.diff:

  • Undo addition of primitive customize cap.
  • Add customize to map_meta_cap. Props nacin.
  • Add missed cap replacement of edit_theme_options => customize.
  • Run wp_customize_support_script() if can customize not edit_theme_options.
  • Promote Customize admin menu to top level if user cannot appearance cap.
  • Direct non-edit_theme_options users from customize to Dashboard if no return param available.

As for how plugins can allow users to access the Customizer now, say for any user who can edit_posts, a filter can be added for map_meta_cap:

function allow_users_who_can_edit_posts_to_customize( $caps, $cap, $user_id ) {
        $required_cap = 'edit_posts';
        if ( 'customize' === $cap && user_can( $user_id, $required_cap ) ) {
                $caps = array( $required_cap );
        }
        return $caps;
}
add_filter( 'map_meta_cap', 'allow_users_who_can_edit_posts_to_customize', 10, 3 );

Or via the user_has_cap filter:

function allow_users_who_can_edit_posts_to_customize( $allcaps, $caps, $args ) {
        if ( ! empty( $allcaps['edit_posts'] ) && ! empty( $args ) && 'customize' === $args[0] ) {
                $allcaps = array_merge( $allcaps, array_fill_keys( $caps, true ) );
        }
        return $allcaps;
}
add_filter( 'user_has_cap', 'allow_users_who_can_edit_posts_to_customize', 10, 3 );

comment:9 @ircbot8 months ago

This ticket was mentioned in IRC in #wordpress-dev by westonruter. View the logs.

comment:10 @ircbot8 months ago

This ticket was mentioned in IRC in #wordpress-dev by westonruter. View the logs.

comment:11 @westonruter8 months ago

  • Keywords 2nd-opinion removed

28605.2.diff resolves conflicts with #28817 and #25457

comment:12 @ocean908 months ago

Discussion about "Promote Customize admin menu to top level if user cannot appearance cap" on IRC. Should be left out for now. Same for Admin Bar.

comment:13 @westonruter8 months ago

In 28605.3.diff:

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

Last edited 8 months ago by westonruter (previous) (diff)

@ocean908 months ago

Remove whitespace fixes, show help only when edit_theme_options && customize

comment:14 @ircbot8 months ago

This ticket was mentioned in IRC in #wordpress-dev by ocean90. View the logs.

comment:15 @nacin8 months ago

  • Keywords commit added

.4.diff looks good.

@ocean908 months ago

comment:16 @ocean908 months ago

  • Owner set to ocean90
  • Resolution set to fixed
  • Status changed from new to closed

In 29170:

Customizer: Add meta capability customize which is mapped to edit_theme_options.

You can now allow users to access the Customizer, say for any user who can edit_posts, via map_meta_cap or user_has_cap filter. See ticket for examples.

props westonruter, nacin.
fixes #28605.

Note: See TracTickets for help on using tickets.