WordPress.org

Make WordPress Core

Ticket #14122: 14122.capability_type.post.diff

File 14122.capability_type.post.diff, 1.2 KB (added by nacin, 8 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