register_post_type() — регистрация типа поста

Регистрирует тип поста. В случае успеха возвращает его объект WP_Post_Type, в случае неудачи – объект WP_Error.

register_post_type( $post_type, $args = array() )

Использование

Функцию нужно использовать внутри хука, причём этот хук должен срабатывать после хука after_setup_theme и перед admin_init. Идеальным вариантом является init.

add_action( 'init', 'true_register_cpt' );
 
function true_register_cpt() {
 
	$args = array(
		'labels' => array(
			'menu_name' => 'Авиабилеты'
		),
		'public' => true,
		'menu_icon' => 'dashicons-airplane'
	);
	register_post_type( 'misha_aviatickets', $args );
}

Я специально добавил префикс с названием типа записи misha_aviatickets, чтобы обратить ваше внимание не некоторые моменты, а именно:

После этого вставляем код вы знаете куда и получаем:

Параметры массива $args

label

(строка) Название вашего типа записи, которое отобразится в админке. Обычно множественное число. Если не указан, то используется значение labels[ 'name' ]

labels

(массив) Ярлыки для отображения в админке.

Тут конечно много всего, поэтому давайте рассмотрим пример на авиабилетах, с которыми мы уже начали работать:

$args = array(
	'labels' => array(
		'name'                     => 'Авиабилеты', // основное название во множественном числе
		'singular_name'            => 'Авиабилет', // название единичной записи
		'add_new'                  => 'Добавить авиабилет',
		'add_new_item'             => 'Добавить новый авиабилет', // на странице добавления записи
		'edit_item'                => 'Изменить авиабилет',
		'new_item'                 => 'Новый авиабилет',
		'view_item'                => 'Просмотр авиабилета', // текст кнопки просмотра записи на сайте (если поддерживается типом)
		'search_items'             => 'Найти авиабилет',
		'not_found'                => 'Авиабилетов не найдено',
		'not_found_in_trash'       => 'В корзине нет авиабилетов',
		'parent_item_colon'        => 'Родительский авиабилет', // только для древовидных типов постов
		'all_items'                => 'Все авиабилеты', // По умолчанию: menu_name
		'archives'                 => 'Архивы авиабилетов', // По умолчанию: all_items
		'menu_name'                => 'Авиабилеты', // Название в меню. По умолчанию: name.
		'name_admin_bar'           => 'Авиабилет', // Название в админ баре при наведении на "Добавить". По умолчанию: singular_name.
		'view_items'               => 'Просмотр авиабилетов', // Текст ссылки перехода на архивы типа записй в админ баре. WordPress 4.7+
		'attributes'               => 'Свойства авиабилета', // Название для метабокса атрибутов записи. WordPress 4.7+
 
		// лейблы загрузчика медиафайлов
		'insert_into_item'         => 'Вставить в авиабилет',
		'uploaded_to_this_item'    => 'Загружено для этого авиабилета',
		'featured_image'           => 'Изображение авиабилета',
		'set_featured_image'       => 'Установить изображение авиабилета',
		'remove_featured_image'    => 'Удалить изображение авиабилета',
		'use_featured_image'       => 'Использовать как изображение авиабилета',
 
		// Gutenberg, WordPress 5.0+
		'item_updated'             => 'Авиабилет обновлён.',
		'item_published'           => 'Авиабилет добавлен.',
		'item_published_privately' => 'Авиабилет добавлен приватно.',
		'item_reverted_to_draft'   => 'Авиабилет сохранён как черновик.',
		'item_scheduled'           => 'Публикация авиабилета запланирована.',
	)
);

Добавляем этот массив $label и, мы получаем:

description

(строка) Описание типа записи. Используется в REST API.

public

(логическое) Этот параметр автоматически задаёт значения по умолчанию для некоторых других параметров. По умолчанию false.

Иными словами:

$args = array(
	'public' => true,
	// 'show_ui' => true,
	// 'publicly_queryable' => true,
	// 'exclude_from_search' => false,
	// 'show_in_nav_menus' => true,
);

Подробнее о параметрах – ниже.

publicly_queryable

(логическое) нужно ли элементы данного типа записей сделать доступными на сайте. Подробнее про то, как это работает тут. По умолчанию равен значению аргумента public.

exclude_from_search

(логическое)

• true — исключить записи данного типа из результатов поиска на сайте,
• false — не исключать.

По умолчанию: противоположные значения параметра public.

По умолчанию: противоположные значения параметра public.

show_in_nav_menus

(логическое) нужно ли элементы данного типа записей сделать доступными для добавления в меню сайта. По умолчанию: значение аргумента public.

show_ui

(логическое) нужно ли добавлять стандартный интерфейс в админке для редактирования и добавления записей данного типа. По умолчанию: значение аргумента public.

show_in_menu

(логическое|строка) нужно ли добавлять пункты в меню админки.

• true — пункты в меню будут добавлены (это видно на предыдущем скриншоте),
• false — хоть интерфейс для типов постов и будет доступен по прямой ссылке в админке, в меню он не появится,
• ссылку на страницу управления нашим типом поста мы можем добавить как вложенную для другого элемента меню верхнего уровня — для этого нужно будет указать его ID (являющийся атрибутом href нужной нам ссылки), например tools.php или edit.php?post_type=page;

По умолчанию: значение аргумента show_ui.

show_in_admin_bar

(логическое) нужно ли добавлять ссылку на создание новой записи данного типа в админ панель. По умолчанию: значение аргумента show_in_menu.

show_in_rest

(логическое) Влияет на то, что данный тип записей будет включен в REST API, а следовательно и на то, будет ли поддерживаться редактор Gutenberg этим типом записей или нет.

Допустим наши авиабилеты не должны поддерживать Gutenberg и редактироваться в классическом редакторе, тогда:

add_action( 'init', 'true_register_cpt' );
 
function true_register_cpt() {
 
	$args = array(
		'labels' => array(
			'menu_name' => 'Авиабилеты'
		),
		'menu_icon' => 'dashicons-airplane',
		'show_in_rest' => false
	);
	register_post_type( 'misha_aviatickets', $args );
}

menu_position

(логическое) Порядок расположения в меню в админке.

menu_icon

(строка) Иконка в меню в админке. Можно задать несколькими способами. По умолчанию – иконка обычных записей.

Во-первых, вы можете указать URL иконки, например get_stylesheet_directory_uri() . '/icon.png'. Изображение должно быть 16х16.

Во-вторых, можно передать SVG-иконку, зашифровав её в base64, типа:

'menu_icon' => 'data:image/svg+xml;base64,' . base64_encode( '<svg width="20" height="20"><path fill="black" /></svg>'),

В-третьих, в WordPress 3.8 появился встроенный пакет иконок Dashicons — вы можете использовать любую из этих иконок, просто указав её название в качестве значения параметра, например dashicons-cart.

В-четвёртых, можно передать значение параметра равным none, тогда WordPress добавит CSS-класс к элементу меню .wp-menu-image empty и вы сможете задать иконку через CSS.

hierarchical

(логическое) Должен ли данный тип постов иметь иерархию (как Страницы) или нет (как Записи). По умолчанию: false.

has_archive

(логическое|строка) Должен ли данный тип записи страницу архивов, где будут выводиться все записи этого типа. Про то, какой PHP-шаблон темы будет использоваться для страницы архивов, читайте здесь. Может принимать значения:

• true/false (по умолчанию). Если передать логическое значение true, то в качестве URL страницы архива будет использоваться название типа записи, например для нашего примера это misha.blog/misha_aviatickets
• Если вы укажете тут строку, например avia, то это тоже включит архивы для этого типа записи и URL будет misha.blog/avia.

rewrite

(массив|логическое) устанавливает правила для постоянных ссылок в URL. Если в качестве значения данного параметра указать false, то правила для постоянных ссылок создаваться не будут. Передайте true, тогда в качестве ярлыка в URL будет использоваться название типа записи misha.blog/misha_aviatickets/ticket.html.

slug

(строка) ярлык, используемый для записей данного типа (по умолчанию — название типа поста)

with_front

(логическое) нужно ли добавлять в постоянные ссылки значение $wp_rewite->front (по умолчанию — true)

feeds

(логическое) нужно ли создавать RSS ленту для данного типа поста (по умолчанию — значение параметра has_archive)

pages

(логическое) нужно ли разрешить постраничную навигацию в постах регистрируемого типа, используя тег <!--nextpage--> (по умолчанию — true)

slug

(строка) ярлык, используемый для записей данного типа (по умолчанию — название типа поста)

with_front

(логическое) нужно ли добавлять в постоянные ссылки значение $wp_rewite->front (по умолчанию — true)

feeds

(логическое) нужно ли создавать RSS ленту для данного типа поста (по умолчанию — значение параметра has_archive)

pages

(логическое) нужно ли разрешить постраничную навигацию в постах регистрируемого типа, используя тег <!--nextpage--> (по умолчанию — true)

query_var

(логическое) Устанавливаем значение $_GET-параметра.

delete_with_user

(логическое) при удалении пользователя на блоге, нужно ли автоматически удалять все записи данного типа, которые он опубликовал.
По умолчанию: false.

supports

(массив) Какой функционал должен поддерживаться данным типом записи. Можно также добавить функцией add_post_type_support().

• title — поле для ввода заголовка поста
• editor — текстовый редактор
• excerpt — метабокс «Цитата»
• author — метабокс «Автор»
• thumbnail — метабокс «Миниатюра записи» (кроме того, ваша тема должна их поддерживать)
• comments — метабокс «Комментарии» (если указано, то разрешены комментарии к постам регистрируемого типа)
• trackbacks — метабокс «Отправить обратные ссылки»
• custom-fields — метабокс «Произвольные поля» (также добавляет поддержку произвольных полей в сайдбарах Gutenberg)
• revisions — метабокс «Редакции» (если указано, то в базе данных будут создаваться редакции постов данного типа)
• page-attributes — метабокс «Атрибуты страницы» с возможностью выбора родительского эоемента и установления порядка menu_order
• post-formats — метабокс «Формат», про форматы постов читайте подробнее здесь.

taxonomies

(массив) массив зарегистрированных таксономий, например category или post_tag, которые будут использоваться для данного типа записей. Присвоить таксономии можно также при помощи функции register_taxonomy_for_object_type(), а зарегистрировать функцией register_taxonomy().

can_export

(логический) Будут ли экспортироваться записи данного типа через Инструменты > Экспорт. По умолчанию: true – да.

capability_type

(строка|массив) Этот параметр нужен только для того, чтобы сгенерировать права для параметра capabilities автоматически. По умолчанию права генерируется такие же, как я для обычных записей, но мы можем задать произвольные права для типа записи, для этого например можем передать в качестве значения параметра либо 'aviaticket' либо array( 'aviaticket', 'aviatickets' ).

capabilities

(массив) Как я уже упоминал, вы можете не указывать этот параметр, если хотите, чтобы права сгенерировались автоматически на основе параметра capability_type. Если же хотите их указать сами, то вэлкам, начнём с этих 7 ключей:

• edit_post, read_post и delete_post – это мета-права. Что это значит? Мета-права обычно прикрепляются уже к действию с конкретным объектом, например то, что пользователь может редактировать определённый пост (edit_post). Но мета-права привязаны к соответствующим примитивным правам, например edit_posts – пользователь может редактировать любые посты.
• edit_posts – могут ли редактироваться посты данного типа.
• edit_others_posts – могут ли посты данного типа редактироваться пользователем, который их не создавал. Если в параметре supports отсутствует поддержка author, то это примитивное право начинает работать как edit_posts.
• publish_posts – есть ли права на публикацию постов.
• read_private_posts – есть ли права на чтение приватных постов

Есть также ещё 8 примитивных прав, которые вам придётся размечать вручную, если только у вас не установлен $map_meta_cap в значении true (по умолчанию false).

• read
• delete_posts – удаление постов,
• delete_private_posts – удаление личных постов,
• delete_published_posts – удаление опубликованных постов
• delete_others_posts – удаление постов, созданных другими пользователями. Если в параметре supports отсутствует поддержка author, то это примитивное право начинает работать как delete_posts
• edit_private_posts – редактирование личных постов,
• edit_published_posts – редактирование опубликованных постов,
• create_posts – создание постов.

Погнали сделаем что-нибудь!

add_action( 'init', function() {
	$args = array(
		'capability_type' => 'avia',
		'map_meta_cap' => true,
		'public' => true
	);
	register_post_type( 'aviaticket', $args );
} );

После чего попробуем распечать получившиеся права print_r( $GLOBALS[ 'wp_post_types' ][ 'aviaticket' ]->cap и получим:

stdClass Object
(
    [edit_post] => edit_avia
    [read_post] => read_avia
    [delete_post] => delete_avia
    [edit_posts] => edit_avias
    [edit_others_posts] => edit_others_avias
    [delete_posts] => delete_avias
    [publish_posts] => publish_avias
    [read_private_posts] => read_private_avias
    [read] => read
    [delete_private_posts] => delete_private_avias
    [delete_published_posts] => delete_published_avias
    [delete_others_posts] => delete_others_avias
    [edit_private_posts] => edit_private_avias
    [edit_published_posts] => edit_published_avias
    [create_posts] => edit_avias
)

Теперь можем добавить некоторые из этих прав администратору например:

$admins = get_role( 'administrator' );
$admins->add_cap( 'edit_published_avias' );

map_meta_cap

(логический) Разрешить WordPress самому разметить мета-права? По умолчанию нет – false, если $capabilities задан и не равен post или page.