WordPress.org

Codex

Interested in functions, hooks, classes, or methods? Check out the new WordPress Code Reference!

Function Reference/get post type capabilities

Description

Builds an object with all post type capabilities out of a post type object. Post type capabilities use the 'capability_type' argument as a base, if the capability is not set in the 'capabilities' argument array or if the 'capabilities' argument is not supplied. The capability_type argument can optionally be registered as an array, with the first value being singular and the second plural, e.g. array('story, 'stories') Otherwise, an 's' will be added to the value for the plural form. After registration, capability_type will always be a string of the singular value.

Usage

<?php get_post_type_capabilities$args ?>

Parameters

$args
(array or string) (required) The desired capability type (e.g. 'post'). Set ['capability_type'] to an array to allow for alternative plurals when using this argument as a base to construct the capabilities, e.g. array('story', 'stories'). Set ['map_meta_cap'] to true to obtain those capabilities as well.
Default: None

By default, seven keys are accepted as part of the capabilities array:

  • edit_post, read_post, and delete_post are meta capabilities, which are then generally mapped to corresponding primitive capabilities depending on the context, which would be the post being edited/read/deleted and the user or role being checked. Thus these capabilities would generally not be granted directly to users or roles.
  • edit_posts - Controls whether objects of this post type can be edited.
  • edit_others_posts - Controls whether objects of this type owned by other users can be edited. If the post type does not support an author, then this will behave like edit_posts.
  • publish_posts - Controls publishing objects of this post type.
  • read_private_posts - Controls whether private objects can be read.

These four primitive capabilities are checked in core in various locations.

There are also seven other primitive capabilities which are not referenced directly in core, except in map_meta_cap(), which takes the three aforementioned meta capabilities and translates them into one or more primitive capabilities that must then be checked against the user or role, depending on the context.

  • read - Controls whether objects of this post type can be read.
  • delete_posts - Controls whether objects of this post type can be deleted.
  • delete_private_posts - Controls whether private objects can be deleted.
  • delete_published_posts - Controls whether published objects can be deleted.
  • delete_others_posts - Controls whether objects owned by other users can be can be deleted. If the post type does not support an author, then this will behave like delete_posts.
  • edit_private_posts - Controls whether private objects can be edited.
  • edit_published_posts - Controls whether published objects can be edited.

These additional capabilities are only used in map_meta_cap(). Thus, they are only assigned by default if the post type is registered with the 'map_meta_cap' argument set to true (default is false).

Return

(object) 
Object with all capabilities as member variables

Change Log

Source File

get_post_type_capabilities() is located in wp-includes/post.php.

Related

Post Types: register_post_type(), add_post_type_support(), remove_post_type_support(), post_type_supports(), post_type_exists(), set_post_type(), get_post_type(), get_post_types(), get_post_type_object(), get_post_type_capabilities(), get_post_type_labels(), is_post_type_hierarchical(), is_post_type_archive(), post_type_archive_title()

See also index of Function Reference and index of Template Tags.
This page is marked as incomplete. You can help Codex by expanding it.