[wp-trac] [WordPress Trac] #40878: Adding menus route

[WordPress Trac]

#40878: Adding menus route
-------------------------------------------------+-------------------------
 Reporter:  dingo_d                              |       Owner:
                                                 |  spacedmonkey
     Type:  task (blessed)                       |      Status:  assigned
 Priority:  high                                 |   Milestone:  5.9
Component:  REST API                             |     Version:  4.7
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-dev-  |     Focuses:  rest-api
  note                                           |
-------------------------------------------------+-------------------------

Comment (by dlh):

 I was curious whether backwards compatibility could be maintained while
 using `map_meta_cap => true` through a pattern used elsewhere in core
 whereby `map_meta_cap()` is called twice, in this case by mapping
 `edit_theme_options`.

 For the post type, the steps might be to, first, register `nav_menu_items`
 with:

 {{{
 'map_meta_cap'    => true,
 'capability_type' => 'nav_menu_item',
 'capabilities'    => array(),
 }}}

 which would leave no one with the post type capabilities, followed by
 something like (very rough):

 {{{
 add_filter(
         'map_meta_cap',
         function ( $caps, $cap, $user_id, $args ) {
                 $pt_object = get_post_type_object( 'nav_menu_item' );

                 if (
                         in_array( $cap, (array) $pt_object->cap, true )
                         || (
                                 in_array( $cap, array( 'edit_post',
 'read_post', 'delete_post' ), true )
                                 && ! empty( $args[0] )
                                 && get_post_type( $args[0] ) ===
 $pt_object->name
                         )
                 ) {
                         $caps = map_meta_cap( 'edit_theme_options',
 $user_id );
                 }

                 return $caps;
         },
         10,
         4
 );
 }}}

 to map the post type capabilities back to the mapping for
 `edit_theme_options`. In this way, if I'm following correctly, existing
 filters on `'map_meta_cap'` checking for `edit_theme_options` would still
 be applied, and if there weren't any such filters, `edit_theme_options`
 would be checked as a primitive capability. Developers would also have
 their usual access to `'map_meta_cap'` (the filter) to modify the post
 type capabilities to taste.

 The steps for the `nav_menu` taxonomy would be a little different, of
 course, but the same principle would apply.

 All that said, there's a similar discussion in #40922 for the
 `customize_changeset` post type, including a link to
 ticket:36368#comment:5, which warns against introducing primitive
 capabilities, as this approach would. #41332 tackles this issue for
 attachments.

 Lastly, one of the additional backwards compatibility concerns to note in
 passing from #40922 is that the `$cap` passed to `user_has_cap` also
 changes when `map_meta_cap => true`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/40878#comment:70>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform