How to add a custom post type in WordPress

Furkan Zerman
Stingy Developer
Published in
6 min readAug 2, 2020
How to create custom post types in wordpress

WordPress is the best friend of web developers. It is the best known true. If you are a front-end developer, you can create your website without attempting with middlewares or routers. Moreover, you can customize your website by using free or premium plugins. Plugins help you so much but they may be dangerous in some situations. For example, plugins might have a security bug and hackers can access your website by using it. As a result, customizing your website with your codes is the best.

In this article, I will explain how to add a custom post type in WordPress. If you are ready, let’s get started.

We will use register_post_type() function for adding a custom post type. This function takes two parameters. They are name of post type and some args.

Parameters

$post_type

(string) (Required) Post type key. Must not exceed 20 characters and may only contain lowercase alphanumeric characters, dashes, and underscores. See sanitize_key().

$args

(array|string) (Optional) Array or string of arguments for registering a post type.

‘label’
(string) Name of the post type shown in the menu. Usually plural. Default is value of $labels[‘name’].

‘labels’
(array) An array of labels for this post type. If not set, post labels are inherited for non-hierarchical types and page labels for hierarchical ones. See get_post_type_labels() for a full list of supported labels.

‘description’
(string) A short descriptive summary of what the post type is.

‘public’
(bool) Whether a post type is intended for use publicly either via the admin interface or by front-end users. While the default settings of $exclude_from_search, $publicly_queryable, $show_ui, and $show_in_nav_menus are inherited from public, each does not rely on this relationship and controls a very specific intention. Default false.

‘hierarchical’
(bool) Whether the post type is hierarchical (e.g. page). Default false.

‘exclude_from_search’
(bool) Whether to exclude posts with this post type from front end search results. Default is the opposite value of $public.

‘publicly_queryable’
(bool) Whether queries can be performed on the front end for the post type as part of parse_request(). Endpoints would include:

?post_type={post_type_key}

?{post_type_key}={single_post_slug}

?{post_type_query_var}={single_post_slug} If not set, the default is inherited from $public.

‘show_ui’
(bool) Whether to generate and allow a UI for managing this post type in the admin. Default is value of $public.

‘show_in_menu’
(bool|string) Where to show the post type in the admin menu. To work, $show_ui must be true. If true, the post type is shown in its own top level menu. If false, no menu is shown. If a string of an existing top level menu (eg. ‘tools.php’ or ‘edit.php?post_type=page’), the post type will be placed as a sub-menu of that. Default is value of $show_ui.

‘show_in_nav_menus’
(bool) Makes this post type available for selection in navigation menus. Default is value of $public.

‘show_in_admin_bar’
(bool) Makes this post type available via the admin bar. Default is value of $show_in_menu.

‘show_in_rest’
(bool) Whether to include the post type in the REST API. Set this to true for the post type to be available in the block editor.

‘rest_base’
(string) To change the base url of REST API route. Default is $post_type.

‘rest_controller_class’
(string) REST API Controller class name. Default is ‘WP_REST_Posts_Controller’.

‘menu_position’
(int) The position in the menu order the post type should appear. To work, $show_in_menu must be true. Default null (at the bottom).

‘menu_icon’
(string) The url to the icon to be used for this menu. Pass a base64-encoded SVG using a data URI, which will be colored to match the color scheme — this should begin with ‘data:image/svg+xml;base64,’. Pass the name of a Dashicons helper class to use a font icon, e.g. ‘dashicons-chart-pie’. Pass ‘none’ to leave div.wp-menu-image empty so an icon can be added via CSS. Defaults to use the posts icon.

‘capability_type’
(string) The string to use to build the read, edit, and delete capabilities. May be passed as an array to allow for alternative plurals when using this argument as a base to construct the capabilities, e.g. array(‘story’, ‘stories’). Default ‘post’.

‘capabilities’
(array) Array of capabilities for this post type. $capability_type is used as a base to construct capabilities by default. See get_post_type_capabilities().

‘map_meta_cap’
(bool) Whether to use the internal default meta capability handling. Default false.

‘supports’
(array) Core feature(s) the post type supports. Serves as an alias for calling add_post_type_support() directly. Core features include ‘title’, ‘editor’, ‘comments’, ‘revisions’, ‘trackbacks’, ‘author’, ‘excerpt’, ‘page-attributes’, ‘thumbnail’, ‘custom-fields’, and ‘post-formats’. 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. A feature can also be specified as an array of arguments to provide additional information about supporting that feature. Example: array( 'my_feature', array( 'field' => 'value' ) ). Default is an array containing 'title' and 'editor'.

‘register_meta_box_cb’
(callable) Provide a callback function that sets up the meta boxes for the edit form. Do remove_meta_box() and add_meta_box() calls in the callback. Default null.

‘taxonomies’
(array) An array of taxonomy identifiers that will be registered for the post type. Taxonomies can be registered later with register_taxonomy() or register_taxonomy_for_object_type().

‘has_archive’
(bool|string) Whether there should be post type archives, or if a string, the archive slug to use. Will generate the proper rewrite rules if $rewrite is enabled. Default false.

‘rewrite’
(bool|array) Triggers the handling of rewrites for this post type. To prevent rewrite, set to false. Defaults to true, using $post_type as slug. To specify rewrite rules, an array can be passed with any of these keys:

‘slug’
(string) Customize the permastruct slug. Defaults to $post_type key.

‘with_front’
(bool) Whether the permastruct should be prepended with WP_Rewrite::$front. Default true.

‘feeds’
(bool) Whether the feed permastruct should be built for this post type. Default is value of $has_archive.

‘pages’
(bool) Whether the permastruct should provide for pagination. Default true.

‘ep_mask’
(const) Endpoint mask to assign. If not specified and permalink_epmask is set, inherits from $permalink_epmask. If not specified and permalink_epmask is not set, defaults to EP_PERMALINK.

‘query_var’
(string|bool) Sets the query_var key for this post type. Defaults to $post_type key. If false, a post type cannot be loaded at ?{query_var}={post_slug}. If specified as a string, the query ?{query_var_string}={post_slug} will be valid.

‘can_export’
(bool) Whether to allow this post type to be exported. Default true.

‘delete_with_user’
(bool) Whether to delete posts of this type when deleting a user. If true, posts of this type belonging to the user will be moved to Trash when then user is deleted. If false, posts of this type belonging to the user will *not* be trashed or deleted. If not set (the default), posts are trashed if post_type_supports(‘author’). Otherwise posts are not trashed or deleted. Default null.

‘_builtin’
(bool) FOR INTERNAL USE ONLY! True if this post type is a native or “built-in” post_type. Default false.

‘_edit_link’
(string) FOR INTERNAL USE ONLY! URL segment to use for edit link of this post type. Default ‘post.php?post=%d’.

Default value: array()

Source : register_post_type developer page

Basic Usage

Firstly, we have to create a function for our custom post type. Then, we explain our UI labels for it. We should write our theme name instead of ‘theme’.

$labels = array(
‘name’ => _x( ‘Projects’, ‘Post Type General Name’, ‘theme’ ),
‘singular_name’ => _x( ‘Project’, ‘Post Type Singular Name’, ‘theme’ ),
‘menu_name’ => __( ‘Projects’, ‘theme’ ),
‘parent_item_colon’ => __( ‘Parent Project’, ‘theme’ ),
‘all_items’ => __( ‘All Projects’, ‘theme ),
‘view_item’ => __( ‘View Project’, ‘theme’ ),
‘add_new_item’ => __( ‘Add New Project’, ‘theme’ ),
‘add_new’ => __( ‘Add New’, ‘theme’ ),
‘edit_item’ => __( ‘Edit Project’, ‘theme’ ),
‘update_item’ => __( ‘Update Project’, ‘theme’ ),
‘search_items’ => __( ‘Search Project’, ‘theme’ ),
‘not_found’ => __( ‘Not Found’, ‘theme ),
‘not_found_in_trash’ => __( ‘Not found in Trash’, ‘theme’ ),
);

Set other options for Custom Post Type.

// Set other options for Custom Post Type

$args = array(
‘label’ => __( ‘projects’, ‘theme’ ),
‘description’ => __( ‘Projects in Code-Forever’, ‘theme’ ),
‘labels’ => $labels,
// Features this CPT supports in Post Editor
‘supports’ => array( ‘title’, ‘editor’, ‘excerpt’, ‘author’, ‘thumbnail’, ‘comments’, ‘revisions’, ‘custom-fields’, ),
// You can associate this CPT with a taxonomy or custom taxonomy.
‘taxonomies’ => array( ‘genres’ ),
/* A hierarchical CPT is like Pages and can have
* Parent and child items. A non-hierarchical CPT
* is like Posts.
*/
‘hierarchical’ => false,
‘public’ => true,
‘show_ui’ => true,
‘show_in_menu’ => true,
‘show_in_nav_menus’ => true,
‘show_in_admin_bar’ => true,
‘menu_position’ => 5,
‘can_export’ => true,
‘has_archive’ => true,
‘exclude_from_search’ => false,
‘publicly_queryable’ => true,
‘capability_type’ => ‘post’,
‘show_in_rest’ => true,

);

After all configurations, we will register our custom post type.

// Registering your Custom Post Type
register_post_type( ‘projects’, $args );

After completing our function, we will add our custom pot type by using add_action() function.

add_action( ‘init’, ‘post_type_project’, 0 );

That’s all. Congratulations! You added your custom post type. If you want to read more articles about programming or join a open-source project, please visit Code-Forever. See you next week.

--

--