Introduce discrete capability for managing widgets

[westonruter]

As with management of nav menus (#29213), managing widgets 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_widgets just for managing widgets, one that is inherited for anyone who has edit_theme_options by default. This was done for Customizer access in #28605 with the introduction of a customize capability.

Originally brought up in #14386.
The same is proposed for menus in #29213.

[westonruter]

​https://github.com/xwp/wordpress-develop/pull/64 (builds on patch for #29213)

[westonruter]

In 31020.diff​:

• Incorporate latest patch from #29213
• Add manage_widgets cap, use instead of edit_theme_options where needed:
  • Ajax request to save a widget
  • Accessing the Widgets admin page
  • Showing the link to the widgets admin page in the admin menu
  • Showing Customizer panel, sections, and controls for Widgets and their settings.
  • Admin bar link to Widgets
• Update wp_welcome_panel to show widgets & menus links if has caps
• Show 3.9 pointer for Widget Customizer if user can manage_widgets
• Also block access to nav-menus.php if user cannot manage_widgets and the theme does not support menus

here is a sample plugin which grants access to manage_menus for a user who can edit_posts:

<?php
function allow_users_who_can_edit_posts_to_manage_widgets( $caps, $cap, $user_id ) {
        $required_cap = 'edit_posts';
        if ( 'manage_widgets' === $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_manage_widgets', 10, 3 );

[westonruter]

​https://github.com/xwp/wordpress-develop/commit/41e573994cbed8fcb3a34bf81ad277beadf0142c

[westonruter]

In 31020.1.diff​: Use manage_widgets cap in wp_ajax_widgets_order request

[westonruter]

@ocean90: From the “sub-cap” discussions, e.g. current_user_can( 'edit_theme_options', 'widgets' ), would this not entail that the user has to have edit_theme_options as a prerequisite? As with the customize cap we introduced, which by default maps to edit_theme_options, the intention is that the capability could be granted to users who don't have any sort of edit_theme_options capability.

Also, I didn't see a ticket created for this sub-caps idea.

[DrewAPicture]

Citing ​discussion in Slack with @westonruter and later, @ocean90, punting this to a future release along with #29213.

[swissspidy]

@westonruter Are you planning to look at #29213 at the same time?

[westonruter]

@swissspidy yes, I suppose so :)

[westonruter]

The capability needs to be used in WP_Customize_Widgets::__constructor() instead of edit_theme_options.

[flixos90]

All of these are part of a larger goal.