Post type refers to the various structured data that is maintained in the WordPress posts table. To create a new or modify an existing post type, the register_post_type function is used.
WordPress already has some built-in post types: post, page, attachment, revision, and nav_menu_item.
Function Reference:
For a quick reference of how to use register_post_type, dig into your own WordPress directory’s wp-includes folder. Open the file post.php and find the create_initial_post_types() function. There you can check how WordPress has used register_post_type for creating the initial post types such as post, page, attachment etc. You can use them as a reference, but remember to set the '_builtin' argument to “false” (or simply leave it out, false is the default).
Using register_post_type:
To register a new post type, you will need a name and an array of parameters. The function needs to be used within a function hooked to the ‘init’ action.
add_action('init', 'w4dev_post__register_init');
function w4dev_post__register_init() {
$post_type_name = '';
$arguments = array();
register_post_type( $post_type_name, $arguments );
}
Use lowercase letters for $post_type_name when naming a post type. You can find the full arguments reference on the WordPress developer reference page.
Arguments of register_post_type function:
show_ui
Value ‘true’ for 'show_ui' will generate an admin panel to manage this post type. If you want to manage your custom post type with your own layout/option/process/functionality, then set this to ‘false’ and use the ‘_edit_link’ argument ( example of an edit link: '_edit_link' => 'post.php?post=%d', where %d will be replaced with the post id ) to direct the edit link for this post type to your own url.
show_in_rest
Setting 'show_in_rest' to true exposes the post type in the REST API. This is also what enables the block editor (Gutenberg) for your post type – without it, the post type edit screen falls back to the classic editor. If you register a post type today and wonder why it doesn’t open in the block editor, this argument is the reason.
supports
Registers support of certain features for a post type. All features are directly associated with a functional area of the edit screen, such as the editor or a meta box: 'title', editor, comments, revisions, trackbacks, author, excerpt, page-attributes, thumbnail, and custom-fields. Additionally, the revisions feature dictates whether the post type will store revisions, and the comments feature dictates whether the comments count will show on the edit screen.
rewrite
Rewrite is the url formation you want to use for this post type. Example: A post url may look like – http://SITEURL/post_type/post_name/, though generally it doesn’t happen that way, as most of the time only the post name is used. ‘rewrite’ accepts parameters as an array. Ex: ‘rewrite’ => array(‘slug’ => ‘custom_post’) will generate urls for this post type similar to 'http://SITEURL/custom_post/post_name/'.
capability_type
The string to use to build the read, edit, and delete capabilities for this post type, most likely your post type object’s name.
capabilities
Add additional capabilities or write all of them manually. There are 7 capabilities for a post object type by default. These 7 capabilities are generated by combining the singular or plural form of the given capability_type string.
Example: A capability_type ‘article’ will generate the capabilities – edit_article, read_article, delete_article, edit_articles, edit_others_articles, publish_articles, read_private_articles.
map_meta_cap
Like the 7 capabilities, map_meta_cap generates 7 more capabilities on top of those. Setting map_meta_cap to ‘false’ will skip adding the meta capabilities automatically. Meta capabilities are based on the plural form of the capability_type string.
The 7 default meta capabilities –read, delete_articles, delete_private_articles, delete_published_articles, delete_others_articles, edit_private_articles, edit_published_articles.