WordPress.org

Make WordPress Core

Ticket #14122: 14122.capability_type.post.diff

File 14122.capability_type.post.diff, 1.2 KB (added by nacin, 3 years ago)

map_meta_cap becomes true if capability_type = post and no capabilities were specified. This allows capability_type = post (and nothing else) to work exactly as it did in 3.0, so I'm leaning towards commit on this one.

  • wp-includes/post.php

     
    883883        // Args prefixed with an underscore are reserved for internal use. 
    884884        $defaults = array( 
    885885                'labels' => array(), 'description' => '', 'publicly_queryable' => null, 'exclude_from_search' => null, 
    886                 'capability_type' => 'post', 'capabilities' => array(), 'map_meta_cap' => false, 
     886                'capability_type' => 'post', 'capabilities' => array(), 'map_meta_cap' => null, 
    887887                '_builtin' => false, '_edit_link' => 'post.php?post=%d', 'hierarchical' => false, 
    888888                'public' => false, 'rewrite' => true, 'has_archive' => false, 'query_var' => true, 
    889889                'supports' => array(), 'register_meta_box_cb' => null, 
     
    916916        if ( null === $args->exclude_from_search ) 
    917917                $args->exclude_from_search = !$args->public; 
    918918 
     919        // Back compat with quirky handling in version 3.0. #14122 
     920        if ( 'post' == $args->capability_type && null === $args->map_meta_cap && empty( $args->capabilities ) ) 
     921                $args->map_meta_cap = true; 
     922 
     923        if ( null === $args->map_meta_cap ) 
     924                $args->map_meta_cap = false; 
     925 
    919926        $args->cap = get_post_type_capabilities( $args ); 
    920927        unset($args->capabilities); 
    921928