register_post_type()
Создает новый тип записи или изменяет имеющийся.
Тип записи должен создаваться в момент хука-события init. Он не будет создан, если прикрепить функцию до init и может работать неправильно, если использовать после.
В качестве названия для нового типа записи нужно указывать уникальное имя, отличное от уже имеющихся таксономий, типов записей и зарезервированных WordPress публичных и частных переменных.
Важно: после создания нового типа записи. Обязательно нужно зайти на страницу Настройки → Постоянные ссылки
. Нужно это для того, чтобы правила ЧПУ были пересозданы и туда были добавлены правила нового типа записи.
С версии 4.6 был создан новый класс WP_Post_Type и весь код функции теперь обрабатывается этим классом, а эта функция стала оберткой для него.
Таксономии
Если для нового типа записи регистрируется таксономия, то всегда регистрируйте эту таксономию при регистрации типа записи, для этого используя параметр taxonomies
. Если вы этого не сделаете, тип поста и таксономии не будут опознаны как связанные при срабатывании хуков, таких как: parse_query
или pre_get_posts
. Это может привести к неожиданным последствиям и ошибкам.
Таксономии нужно регистрировать отдельно. Несмотря на то, что таксономия указывается при регистрации типа записи, регистрировать саму таксономию нужно отдельно с помощью register_taxonomy().
Сначала нужно регистрировать таксономию, а потом тип записи с которым эта таксономия связана!
// правильный порядок регистрации типа записи и её таксономии register_taxonomy( ... ); register_post_type( ... );
Эта особенность в некоторых случаях избавит вас от багов и кучи потраченного времени.
Хуки из функции
Возвращает
WP_Post_Type|WP_Error
. WP_Post_Type объект (с версии 4.6).
Шаблон для создания нового типа записи
add_action( 'init', 'register_post_types' ); function register_post_types(){ register_post_type( 'post_type_name', [ 'label' => null, 'labels' => [ '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' => '', // для родителей (у древовидных типов) 'menu_name' => '____', // название меню ], 'description' => '', 'public' => true, // 'publicly_queryable' => null, // зависит от public // 'exclude_from_search' => null, // зависит от public // 'show_ui' => null, // зависит от public // 'show_in_nav_menus' => null, // зависит от public 'show_in_menu' => null, // показывать ли в меню админки // 'show_in_admin_bar' => null, // зависит от show_in_menu 'show_in_rest' => null, // добавить в REST API. C WP 4.7 'rest_base' => null, // $post_type. C WP 4.7 'menu_position' => null, 'menu_icon' => null, //'capability_type' => 'post', //'capabilities' => 'post', // массив дополнительных прав для этого типа записи //'map_meta_cap' => null, // Ставим true чтобы включить дефолтный обработчик специальных прав 'hierarchical' => false, 'supports' => [ 'title', 'editor' ], // 'title','editor','author','thumbnail','excerpt','trackbacks','custom-fields','comments','revisions','page-attributes','post-formats' 'taxonomies' => [], 'has_archive' => false, 'rewrite' => true, 'query_var' => true, ] ); }
Использование
register_post_type( $post_type, $args );
- $post_type(строка) (обязательный)
Название типа записи (максимум 20 символов). Может содержать только строчные символы
a-z
, цифры0-9
, нижние подчёркивания_
и дефисы-
. Регулярное выражениеa-z0-9_-
(определяется работой sanitize_key).Зарезервированные названия для типов постов. Нельзя использовать следующие названия для новых типов постов, так как они используются WordPress и ваш код будет конфликтовать с текущим кодом или функциями WordPress:
post page attachment revision nav_menu_item custom_css customize_changeset action author order theme
- $args(массив)
- Массив аргументов.
По умолчанию: array() (параметры по умолчанию)
Аргументы параметра $args
- label(строка)
- Имя типа записи помеченное для перевода на другой язык.
Заметка: Без свойства label не получится сделать отдельный шаблон вывода для кастомного типа записи.
По умолчанию: $post_type - labels(массив)
Массив содержащий в себе названия ярлыков для типа записи.
Для неустановленных строк (т.е. по умолчанию), будут использованы:
- Для не древовидных типов записей - названия "постов".
- Для древовидных типов записей - названия "постоянных страниц".
В массиве можно указать следующие аргументы:
Для полного списка значений см. get_post_type_labels()
По умолчанию: если не установлено, name и singular_name примут значение аргумента label
- description(строка)
- Короткое описание этого типа записи. Значение используется в REST API. Значение можно получить с помощью функции get_the_post_type_description().
По умолчанию: '' - public(логический)
Определяет является ли тип записи публичным или нет. На основе этого параметра строятся много других, т.е. это своего рода пред-установка для следующих параметров:
-
false
- show_ui = false - не показывать пользовательский интерфейс (UI) для этого типа записей
- publicly_queryable = false - запросы относящиеся к этому типу записей не будут работать в шаблоне
- exclude_from_search = true - этот тип записей не будет учитываться при поиске по сайту
- show_in_nav_menus = false - этот тип записей будет спрятан из выбора меню навигации
- true
- show_ui = true
- publicly_queryable = true
- exclude_from_search = false
- show_in_nav_menus = true
По умолчанию: false
-
- publicly_queryable(логический)
true включит публичный просмотр записей этого типа - это значит что во фронт-энде будут работать URL запросы для этого типа записей, например:
// без ЧПУ ?post_type={post_type_key} ?{post_type_key}={single_post_slug} ?{post_type_query_var}={single_post_slug} // при включенном ЧПУ /book/my-book-name
При false записи этого типа будут недоступны во фронт-энде через обычные URL запросы и на запрос к текущему типу записи вы увидите 404 страницу.
Проверка этого параметра происходит в методе WP::parse_request() при обработке базового запроса WP.
Заметка: если параметр query_var пустой
''|null|false
, WordPress все равно попытается обработать его и отдаст 404 страницу.Заметка: если
publicly_queryable = false
иquery_var = true
, то при переходе на URL записи мы увидим главную страницу ВНИМАНИЕ с кодом ответа 200! Поэтому приpublicly_queryable = false
илиpublic = false
, нужно также указатьquery_var = false
, в этом случае при переходе на URL записи мы, как и положено, увидим 404 страницу.По умолчанию: значение параметра (public)
- exclude_from_search(логический)
Исключить ли этот тип записей из поиска по сайту. 1 (true) - да, 0 (false) - нет.
Если этот параметр установлен в
true
, то для терминов таксономий привязанных к этому типу записей, вывод работать не будет (пусть даже параметр public равен true). Т.е. этот тип постов будет полностью исключен из запросов типаquery_posts()
!По умолчанию: обратное значение аргумента public
- show_ui(логический)
Определяет нужно ли создавать логику управления типом записи из админ-панели. Нужно ли создавать UI типа записи, чтобы им можно было управлять.
Так, например, если указать true, а в show_in_menu = false. То у нас будет возможность зайти на страницу управления типом записи, т.е. движок будет понимать и обрабатывать такие запросы, но ссылки на эту страницу в меню не будет ...
По умолчанию: значение аргумента public
Показывать ли тип записи в администраторском меню и где именно показывать управление типом записи. Аргумент show_ui должен быть включен!
false
- не показывать в администраторском меню.true
- показывать как меню первого уровня.строка
- показывать как под-меню меню первого уровня, например, подменю для 'tools.php' или 'edit.php?post_type=page' для произвольных типов меню нужно указывать $menu_slug см. add_menu_page().
ЗАМЕТКА: Если используется
строка
для того, чтобы показать как подменю, какого-нибудь главного меню, создаваемого плагином, этот пункт станет первым в списке и соответственно изменит расположение пунктов меню. Для того, чтобы этого не произошло, в плагине, который создает свое меню нужно установить приоритет для события admin_menu 9 или ниже.По умолчанию: значение параметра show_ui
- show_in_admin_bar(логический)
- Сделать этот тип доступным из админ бара.
По умолчанию: null (значение show_in_menu) - Включить возможность выбирать этот тип записи в меню навигации.
По умолчанию: значение параметра public - show_in_rest(логический) (WP 4.7)
Нужно ли включать тип записи в REST API. true — добавит тип записи в маршрут
wp/v2
.Также влияет на работу блочного редактора Gutenberg: true - редактор Gutenberg включен для этого типа записи (так же должен быть включён параметр supports со значением editor), false - будет использоваться обычный редактор.
По умолчанию: false
- rest_base(строка) (WP 4.7)
- Ярлык в REST API. По умолчанию, название типа записи.
По умолчанию: $post_type - rest_controller_class(строка) (WP 4.7)
- Название класса контроллера в REST API.
По умолчанию: 'WP_REST_Posts_Controller' - rest_namespace(строка) (WP 5.9)
- Указывает префикс (пространство имен) в URL REST API маршрута.
По умолчанию: wp/v2 Позиция где должно расположится меню нового типа записи:
1
— в самом верху меню2-3
— под «Консоль»4-9
— под «Записи»10-14
— под «Медиафайлы»15-19
— под «Ссылки»20-24
— под «Страницы»25-59
— под «Комментарии» (по умолчанию, null)60-64
— под «Внешний вид»65-69
— под «Плагины»70-74
— под «Пользователи»75-79
— под «Инструменты»80-99
— под «Параметры»100+
— под разделителем после «Параметры»
По умолчанию: null
Ссылка на картинку, которая будет использоваться для этого меню.
С выходом WordPress 3.8 появился новый пакет иконок Dashicons, который входит в состав ядра WordPress. Это комплект из более 150 векторных изображений. Чтобы установит одну из иконок, напишите её название в этот параметр. Например иконка постов, называется так:
dashicons-admin-post
, а ссылокdashicons-admin-links
.Примеры:
'dashicons-admin-post' // иконка dashicons. get_template_directory_uri() .'/images/icon.png' // ссылка на картинку. 'data:image/svg+xml;base64,' . base64_encode( '<svg xmlns="http://www.w3.org/2000/svg" width="20" height="20"><path fill="black" /></svg>' ) // Прямое указание SVG иконки в base64 формате. // Готовый SVG можно взять по ссылке: https://github.com/encharm/Font-Awesome-SVG-PNG/tree/master/black/svg // Тут важно учесть два момента: // 1) для path нужно указать атрибут fill="black", чтобы WordPress мог изменять цвет иконки под выбранную тему. // 2) у svg обязательно должен быть атрибут xmlns="http://www.w3.org/2000/svg", без него иконка не будет отображаться. 'none' // добавит к элементу класс ".wp-menu-image empty", это позволит установить иконку через CSS.
По умолчанию: null - иконка как у меню постов
- capability_type(строка/массив)
Строка которая будет маркером для установки прав для этого типа записи.
Встроенные маркеры это: post и page.Можно передавать массив, где первое значение будет использоваться для единственного числа, а второе для множественного, например: array('story', 'stories'). Если передается строка, то для множественного числа просто прибавляется 's' на конце.
capability_type используется для построения списка прав, которые будут записаны в параметр 'capabilities'.
При установке нестандартного маркера (не post или page), параметр map_meta_cap можно установить в true или в false:
- Если поставить true — то WordPress автоматически сгенерирует группу прав для параметра 'capabilities' на основе введенных здесь данных. При этом указанные в параметре 'capabilities' права дополнят имеющийся список прав.
- Если установить false — то WordPress ничего генерировать не будет и вам придется самому полностью прописать все возможные права для этого типа записи в параметре 'capabilities'.
Пример: допустим мы указали тут строку
bill
что равносильноarray('bill', 'bills')
, тогда WordPress автоматически сгенерирует следующие права для параметра 'capabilities':[cap] => stdClass Object( // Meta права [edit_post] => edit_bill [read_post] => read_bill [delete_post] => delete_bill // Примитивные права, НЕ используются в map_meta_cap() [edit_posts] => edit_bills [edit_others_posts] => edit_others_bills [publish_posts] => publish_bills [read_private_posts] => read_private_bills [read] => read [delete_posts] => delete_bills [delete_private_posts] => delete_private_bills [delete_published_posts] => delete_published_bills [delete_others_posts] => delete_others_bills [edit_private_posts] => edit_private_bills [edit_published_posts] => edit_published_bills // Примитивные права, используются в map_meta_cap() [create_posts] => edit_bills )
Чтобы посмотреть какие права были созданы, загляните в глобальную переменную: $GLOBALS['wp_post_types']['bill'].
По умолчанию: "post"
- capabilities(массив)
Массив прав для этого типа записи.
Элемент массив выглядит как
ключ => значение
, где:ключ
- привычное (известное WP) название права, напримерedit_posts
.значение
- соответствующее право для поста, которое нужно указывать для проверки в current_user_can(). Пример такой проверки:current_user_can( значение ) // При обработки кода превратиться в право с которым WP умеет работать current_user_can( ключ )
По умолчанию, доступны 8 элементов массива, которые определяют права для этого типа записей (даже если map_meta_cap = false), это:
edit_post
,read_post
иdelete_post
- 3 разрешения контролирующие редактирование, прочтение и удаление конкретной записи. Это мета-права: не примитивные права, которые требуют вычислений на лету. Они не записываются в список прав каждого пользователя, а превращаются в примитивные права на лету с помощью функции map_meta_cap().edit_posts
- контролирует возможность редактировать объекты этого типа записи.create_posts
- по умолчанию тоже самое что и право edit_posts. Но его можно вручную указать в параметреcapabilities
, чтобы оно отличалось от edit_posts.delete_posts
- разрешает удалять объект этого типа записи.edit_others_posts
- контролирует возможность редактировать объекты этого типа записей, которые принадлежат другому пользователю. Если тип записи не поддерживает авторов, то поведение этого аргумента будет похоже на edit_posts.publish_posts
- контролирует публикацию объектов этого типа записи.read_private_posts
- контролирует возможность прочтения личных объектов (записей).
Заметка: примитивные права вида
*_posts
используются в движке в разных местах.Существуют еще 6 примитивных прав, которые используются в функции map_meta_cap(). Они устанавливаются автоматически, если указан параметр
map_meta_cap = true
:-
read
- разрешает просматривать объект во фронт-энде. delete_private_posts
- разрешает удалять личный объект этого типа записи.delete_published_posts
- разрешает удалять опубликованные объекты этого типа записи.delete_others_posts
- разрешает удалять записи принадлежащие другим автора. Если у записи нет автора, то поведение передается delete_posts.edit_private_posts
- разрешает редактировать личные записи.edit_published_posts
- разрешает редактировать опубликованные записи.
Заметка: Чтобы пользователь мог создавать новые записи, его роль должна кроме прочего иметь право 'edit_posts'.
Этот capabilities параметр обычно устанавливается автоматически, опираясь на 'capability_type'. Например если установить 'capability_type' и 'map_meta_cap' и посмотреть в переменную get_post_type_object( 'post_type' )->cap, то мы увидим такой объект:
[cap] => stdClass Object ( // Мета права: [edit_post] => "edit_{$capability_type}" [read_post] => "read_{$capability_type}" [delete_post] => "delete_{$capability_type}" // Примитивные права: [edit_posts] => "edit_{$capability_type}s" [create_posts] => "edit_{$capability_type}s" [delete_posts] => "delete_{$capability_type}s" [edit_others_posts] => "edit_others_{$capability_type}s" [publish_posts] => "publish_{$capability_type}s" [read_private_posts] => "read_private_{$capability_type}s" // Примитивные права используемые в map_meta_cap(): [read] => "read", [delete_private_posts] => "delete_private_{$capability_type}s" [delete_published_posts] => "delete_published_{$capability_type}s" [delete_others_posts] => "delete_others_{$capability_type}s" [edit_private_posts] => "edit_private_{$capability_type}s" [edit_published_posts] => "edit_published_{$capability_type}s" )
Пример нестандартного использования прав:
'capabilities' => array( 'delete_posts' => 'edit_theme_options', 'delete_post' => 'edit_theme_options', 'delete_published_posts' => 'edit_theme_options', 'delete_private_posts' => 'edit_theme_options', 'delete_others_posts' => 'edit_theme_options', 'edit_post' => 'edit_css', 'edit_posts' => 'edit_css', 'edit_others_posts' => 'edit_css', 'edit_published_posts' => 'edit_css', 'read_post' => 'read', 'read_private_posts' => 'read', 'publish_posts' => 'edit_theme_options', ),
По умолчанию: используется значение параметра capability_type для построения списка прав.
- map_meta_cap(логический)
Нужно ли включить дефолтный обработчик мета прав map_meta_cap().
При включении этого параметра список прав поста расширяется - в него добавляются права, которые используются в функции map_meta_cap(). Фрагмент из кода get_post_type_capabilities():
// Primitive capabilities used within map_meta_cap(): if ( $args->map_meta_cap ) { $default_capabilities_for_mapping = array( 'read' => 'read', 'delete_private_posts' => 'delete_private_' . $plural_base, 'delete_published_posts' => 'delete_published_' . $plural_base, 'delete_others_posts' => 'delete_others_' . $plural_base, 'edit_private_posts' => 'edit_private_' . $plural_base, 'edit_published_posts' => 'edit_published_' . $plural_base, ); $default_capabilities = array_merge( $default_capabilities, $default_capabilities_for_mapping ); }
А также, в глобальную переменную
global $post_type_meta_caps
добавляется мап трех полей для базовых прав: 'read_post', 'delete_post', 'edit_post'. См. _post_type_meta_capabilities(). Например, будет добавлен такой мап:[ 'read_mycpt ' => 'read_post', 'delete_mycpt ' => 'delete_post', 'edit_mycpt ' => 'edit_post', ]
Нужно это для того, чтобы когда мы вызываем, например
current_user_can( 'edit_mycpt', 123 )
. Функция map_meta_cap(), через глобальную переменную превратилаedit_mycpt
вedit_post
и вызвала сама себя с уже известным для WP именем права:default: // Handle meta capabilities for custom post types. global $post_type_meta_caps; if ( isset( $post_type_meta_caps[ $cap ] ) ) { return map_meta_cap( $post_type_meta_caps[ $cap ], $user_id, ...$args ); }
Заметка: если не установить (оставить null), то логика значения по умолчанию разветвляется:
- если в capability_type указано post или page и не указан параметр capabilities, то map_meta_cap = true по умолчанию.
-
во всех остальных случаях map_meta_cap = false по умолчанию.
// кусок из кода: WP_Post_Type::set_props // Back compat with quirky handling in version 3.0. #14122. if ( empty( $args['capabilities'] ) && null === $args['map_meta_cap'] && in_array( $args['capability_type'], array( 'post', 'page' ) ) ) { $args['map_meta_cap'] = true; } // If not set, default to false. if ( null === $args['map_meta_cap'] ) { $args['map_meta_cap'] = false; }
Заметка: при false стандартная роль "Администратор" не сможет редактировать этот тип записи. Для снятия такого ограничения придется добавить право
edit_{post_type}s
к роли администратор.Смотрите также: Добавление права пользователю налету
По умолчанию: null
- hierarchical(логический)
Будут ли записи этого типа иметь древовидную структуру (как постоянные страницы).
true - да, будут древовидными
false - нет, будут связаны с таксономией (категориями)По умолчанию: false
- supports(массив / false)
Поля/метабоксы на странице создания/редактирования типа записи.
Если в значении указать
false
, то никакие дополнительные метабоксы выведены не будут, в том числе и те которые установлены по умолчанию.title
- блок заголовка (по умолчанию).editor
- блок для ввода контента (по умолчанию).author
- блок выбора автора.thumbnail
блок выбора миниатюры записи. Нужно также включить поддержку в установке темы post-thumbnails.excerpt
- блок ввода цитаты.trackbacks
- включает поддержку трекбеков и пингов (за блоки не отвечает);custom-fields
- блок установки произвольных полей.comments
- блок комментариев (обсуждение).revisions
- блок ревизий (не отображается пока нет ревизий);-
page-attributes
- блок атрибутов страницы: выбор шаблона (он должен быть создан) и древовидная связь записей (древовидность должна быть включена отдельно 'hierarchical' => true). post-formats
– блок форматов записи, если они включены в теме.
Значение может также быть указано в виде массива, чтобы передать дополнительные параметры фитчи. Например:
[ 'title', 'editor', [ 'my_feature', [ 'field' => 'value' ] ]
Заметка: Если пользовательский тип записи использует миниатюры, не забудьте проверить, что тема также поддерживает миниатюры или используйте функцию add_theme_support().
По умолчанию: array( 'title', 'editor' )
- register_meta_box_cb(строка)
- callback функция, которая будет срабатывать при установки мета блоков для страницы создания/редактирования этого типа записи. Используйте
remove_meta_box()
иadd_meta_box()
в callback функции.
По умолчанию: null' - taxonomies(массив)
Массив зарегистрированных таксономий, которые будут связаны с этим типом записей, например:
category
илиpost_tag
.Связать таксономии с записью можно позднее через функцию register_taxonomy_for_object_type().
Таксономии нужно регистрировать с помощью функции register_taxonomy().
По умолчанию: []
- permalink_epmask(строка)
Индекс конечной точки, с которой будет ассоциирован создаваемый тип записи. Как правило этот параметр не используется. Тут можно указать след. константы или их комбинацию соединенную через & или |:
- EP_NONE
- EP_PERMALINK
- EP_ATTACHMENT
- EP_DATE
- EP_YEAR
- EP_MONTH
- EP_DAY
- EP_ROOT
- EP_COMMENTS
- EP_SEARCH
- EP_CATEGORIES
- EP_TAGS
- EP_AUTHORS
- EP_PAGES
- EP_ALL
Конечная точка - это то что добавляется в конец URL, например /trackback/. Конечные точки прикрепляются к типу записи (добавляются в правила перезаписи) с помощью функции add_rewrite_endpoint().
Этот параметр позволяет указать, какую группу конечных точек мы хотим подключить к создаваемому типу записи (к URL записи). Например, если указать 'permalink_epmask' = EP_PAGES & EP_TAGS, то наш тип записи будет иметь все дополнительные варианты URL (конечные точки), которые предусмотрены для постоянных страниц и меток.
По умолчанию permalink_epmask = EP_PERMALINK - это означает, что в URL создаваемого типа записи (в правила ЧПУ) будут добавлены конечные точки, которые добавляются к обычным записям WordPress: пагинация, страница комментов и т.д.
Если не нужно добавлять никаких конечных точек к новому типу записи, то нужно указать EP_NONE. Или наоборот, указываем EP_ALL, когда нужно добавить все конечные точки.
По умолчанию: EP_PERMALINK
- has_archive(строка/логический)
Включить поддержку страниц архивов для этого типа записей (пр. УРЛ записи выглядит так: example.com/type/post_name, тогда УРЛ архива будет такой: example.com/type.
Если указать строку, то она будет использована в ЧПУ. Например, укажем тут
typepage
и получим ссылку на архив типа записи такого вида:example.com/typepage
.Файл этого архива в теме будет иметь вид archive-type.php. Для архивов будет добавлено новое правило ЧПУ, если аргумент
rewrite
включен.По умолчанию: false
- rewrite(массив/логический)
Использовать ли ЧПУ для этого типа записи. Чтобы не использовать ЧПУ укажите false. По умолчанию: true — название типа записи используется как префикс в ссылке. Можно в массиве указать дополнительные параметры для построения ЧПУ:
-
slug(строка)
Префикс в ЧПУ (/префикс/ярлык_записи). Используйте[ 'slug' => $slug ]
, чтобы создать другой префикс.В этом параметре можно указывать плейсхолдеры типа
%category%
. Но они должны регистрироваться отдельно или их нужно создать с помощью add_rewrite_tag(), чтобы WP знал о них.
По умолчанию: название типа записи -
with_front(логический)
Нужно ли в начало вставлять общий префикс из настроек. Префикс берется из $wp_rewite->front. Например, если структура постоянных ссылок записей в настройках имеет видblog/%postname%
, то при false получим:/news/название_поста
, а при true получим:/blog/news/название_поста
.
По умолчанию: true -
feeds(логический)
Добавить ли правило ЧПУ для RSS ленты этого типа записи.
По умолчанию: значение аргумента has_archive - pages(логический)
Добавить ли правило ЧПУ для пагинации записи. Пр:/post_type/page/2
. Т.е. если указано true, то в записи можно будет использовать шоркод<!--nextpage-->
. Смотрите wp_link_pages().
По умолчанию: true
По умолчанию: true (тип записи используется как префикс)
-
- query_var(строка/логический)
Устанавливает название параметра запроса для создаваемого типа записи.
Ставим false, чтобы убрать возможность запросов.
false
- отключает параметр запроса. Запись не будет доступна по URL:/?{query_var}={post_slug}
.string
- указывает название параметра зпроса./?{query_var_string}={post_slug}
.
Заметка: если
publicly_queryable = false
иquery_var = true
, то при переходе на URL записи мы увидим главную страницу ВНИМАНИЕ с кодом ответа 200! Поэтому при отключении записи от публичного просмотра, нужно кроме выставления false для параметра public или publicly_queryable, нужно также указать false и для этого параметра -query_var = false
, в этом случае при переходе на URL записи мы, как и положено, увидим 404 страницу.Заметка: параметр добавляет указанное значение или ярлык типа записи (если указано true) в список разрешенных параметров запроса WordPress, см. add_rewrite_tag(). Потому что WordPress удаляет любые параметры запроса, о которых он не знает.
Пример: мы регаем тип записи book и указали в этом параметре строку bookname. Теперь, пройде на страницу книги по ссылке /book/harry-potter, в коде обрабатывающем эту страницу get_query_var('bookname') вернет harry-potter. А если бы мы ничего не указали в этом параметре (он был бы true), то чтобы получить harry-potter, нам нужно было бы использовать get_query_var('book').
По умолчанию: true - устанавливается аргумент
$post_type
- can_export(логический)
- Возможность экспорта этого типа записей.
По умолчанию: true - delete_with_user(логический)
true
- удалять записи этого типа принадлежащие пользователю при удалении пользователя. Если включена корзина, записи не удаляться, а поместятся в корзину.false
- при удалении пользователя его записи этого типа никак не будут обрабатываться.null
- записи удаляться или будут перемещены в корзину, если post_type_supports('author') установлена. И не обработаются, если поддержки 'author' у типа записи нет.
По умолчанию: null
- template(массив) (WP 5.0.0)
Массив блоков, которые будут использованы в качестве начального состояния для редактора.
Каждый элемент должен представлять собой массив, содержащий имя блока и необязательные атрибуты.
Подробнее здесь: https://developer.wordpress.org/block-editor/reference-guides/block-api/block-templates/
По умолчанию: array()
- template_lock(логический) (WP 5.0.0)
Должен ли шаблон блока быть заблокирован, если установлен параметр
template
.- Если установлено значение
'all'
, пользователь не может вставлять новые блоки, перемещать существующие блоки и удалять блоки. - Если установлено значение
'insert'
, пользователь может перемещать существующие блоки, но не может вставлять новые блоки и удалять блоки.
- Если установлено значение
- cap(stdClass)
Права типа записи. Устанавливается автоматически. Пример значения когда
cabability_type=post
:array( 'edit_post' => 'edit_post', 'read_post' => 'read_post', 'delete_post' => 'delete_post', 'edit_posts' => 'edit_posts', 'edit_others_posts' => 'edit_others_posts', 'delete_posts' => 'delete_posts', 'publish_posts' => 'publish_posts', 'read_private_posts' => 'read_private_posts', 'read' => 'read', 'delete_private_posts' => 'delete_private_posts', 'delete_published_posts' => 'delete_published_posts', 'delete_others_posts' => 'delete_others_posts', 'edit_private_posts' => 'edit_private_posts', 'edit_published_posts' => 'edit_published_posts', 'create_posts' => 'edit_posts', )
- _builtin(логический)
- Для внутреннего использования! True, если это встроенный/внутренний типа записи.
По умолчанию: false - _edit_link(строка)
- Для внутреннего использования! Часть URL в ссылке на редактирования этого типа записи.
По умолчанию: 'post.php?post=%d'
Примеры
#1 Добавление таксономии в ЧПУ (у записи и таксы одинаковый префикс)
Этот пример показывает как создать запись типа faq (вопросы) и разделы для неё (таксономию faqcat). При этом префикс в ЧПУ у таксономии будет такой же как у типа записи:
- У записи: example.com/faq/{категория}/{ярлык-записи}
- У таксы: example.com/faq/{категория}
Тут важно сначала регнуть таксу, а потом тип записи:
// рега типа записи add_action( 'init', 'register_faq_post_type' ); // Отфильтруем ЧПУ произвольного типа add_filter( 'post_type_link', 'faq_permalink', 1, 2 ); function register_faq_post_type() { // Раздел вопроса - faqcat register_taxonomy( 'faqcat', [ 'faq' ], [ 'label' => 'Раздел вопроса', // определяется параметром $labels->name 'labels' => array( 'name' => 'Разделы вопросов', 'singular_name' => 'Раздел вопроса', 'search_items' => 'Искать Раздел вопроса', 'all_items' => 'Все Разделы вопросов', 'parent_item' => 'Родит. раздел вопроса', 'parent_item_colon' => 'Родит. раздел вопроса:', 'edit_item' => 'Ред. Раздел вопроса', 'update_item' => 'Обновить Раздел вопроса', 'add_new_item' => 'Добавить Раздел вопроса', 'new_item_name' => 'Новый Раздел вопроса', 'menu_name' => 'Раздел вопроса', ), 'description' => 'Рубрики для раздела вопросов', // описание таксономии 'public' => true, 'show_in_nav_menus' => false, // равен аргументу public 'show_ui' => true, // равен аргументу public 'show_tagcloud' => false, // равен аргументу show_ui 'hierarchical' => true, 'rewrite' => array('slug'=>'faq', 'hierarchical'=>false, 'with_front'=>false, 'feed'=>false ), 'show_admin_column' => true, // Позволить или нет авто-создание колонки таксономии в таблице ассоциированного типа записи. (с версии 3.5) ] ); // тип записи - вопросы - faq register_post_type( 'faq', [ 'label' => 'Вопросы', 'labels' => array( 'name' => 'Вопросы', 'singular_name' => 'Вопрос', 'menu_name' => 'Архив вопросов', 'all_items' => 'Все вопросы', 'add_new' => 'Добавить вопрос', 'add_new_item' => 'Добавить новый вопрос', 'edit' => 'Редактировать', 'edit_item' => 'Редактировать вопрос', 'new_item' => 'Новый вопрос', ), 'description' => '', 'public' => true, 'publicly_queryable' => true, 'show_ui' => true, 'show_in_rest' => false, 'rest_base' => '', 'show_in_menu' => true, 'exclude_from_search' => false, 'capability_type' => 'post', 'map_meta_cap' => true, 'hierarchical' => false, 'rewrite' => array( 'slug'=>'faq/%faqcat%', 'with_front'=>false, 'pages'=>false, 'feeds'=>false, 'feed'=>false ), 'has_archive' => 'faq', 'query_var' => true, 'supports' => array( 'title', 'editor' ), 'taxonomies' => array( 'faqcat' ), ] ); } function faq_permalink( $permalink, $post ){ // выходим если это не наш тип записи: без холдера %faqcat% if( strpos( $permalink, '%faqcat%' ) === false ){ return $permalink; } // Получаем элементы таксы $terms = get_the_terms( $post, 'faqcat' ); // если есть элемент заменим холдер if( ! is_wp_error( $terms ) && !empty( $terms ) && is_object( $terms[0] ) ){ $term_slug = array_pop( $terms )->slug; } // элемента нет, а должен быть... else { $term_slug = 'no-faqcat'; } return str_replace( '%faqcat%', $term_slug, $permalink ); }
#2 Регистрация нового типа записи
Пример регистрации произвольного типа записей "book". Также в примере показано как включить сообщения при обновлении и поддержку раздела помощь.
add_action('init', 'my_custom_init'); function my_custom_init(){ register_post_type('book', array( 'labels' => array( 'name' => 'Книги', // Основное название типа записи 'singular_name' => 'Книга', // отдельное название записи типа Book 'add_new' => 'Добавить новую', 'add_new_item' => 'Добавить новую книгу', 'edit_item' => 'Редактировать книгу', 'new_item' => 'Новая книга', 'view_item' => 'Посмотреть книгу', 'search_items' => 'Найти книгу', 'not_found' => 'Книг не найдено', 'not_found_in_trash' => 'В корзине книг не найдено', 'parent_item_colon' => '', 'menu_name' => 'Книги' ), 'public' => true, 'publicly_queryable' => true, 'show_ui' => true, 'show_in_menu' => true, 'query_var' => true, 'rewrite' => true, 'capability_type' => 'post', 'has_archive' => true, 'hierarchical' => false, 'menu_position' => null, 'supports' => array('title','editor','author','thumbnail','excerpt','comments') ) ); }
Сообщения при публикации или изменении типа записи book:
// Сообщения при публикации или изменении типа записи book add_filter('post_updated_messages', 'book_updated_messages'); function book_updated_messages( $messages ) { global $post; $messages['book'] = array( 0 => '', // Не используется. Сообщения используются с индекса 1. 1 => sprintf( 'Book обновлено. <a href="%s">Посмотреть запись book</a>', esc_url( get_permalink($post->ID) ) ), 2 => 'Произвольное поле обновлено.', 3 => 'Произвольное поле удалено.', 4 => 'Запись Book обновлена.', /* %s: дата и время ревизии */ 5 => isset($_GET['revision']) ? sprintf( 'Запись Book восстановлена из ревизии %s', wp_post_revision_title( (int) $_GET['revision'], false ) ) : false, 6 => sprintf( 'Запись Book опубликована. <a href="%s">Перейти к записи book</a>', esc_url( get_permalink($post->ID) ) ), 7 => 'Запись Book сохранена.', 8 => sprintf( 'Запись Book сохранена. <a target="_blank" href="%s">Предпросмотр записи book</a>', esc_url( add_query_arg( 'preview', 'true', get_permalink($post->ID) ) ) ), 9 => sprintf( 'Запись Book запланирована на: <strong>%1$s</strong>. <a target="_blank" href="%2$s">Предпросмотр записи book</a>', // Как форматировать даты в PHP можно посмотреть тут: http://php.net/date date_i18n( __( 'M j, Y @ G:i' ), strtotime( $post->post_date ) ), esc_url( get_permalink($post->ID) ) ), 10 => sprintf( 'Черновик записи Book обновлен. <a target="_blank" href="%s">Предпросмотр записи book</a>', esc_url( add_query_arg( 'preview', 'true', get_permalink($post->ID) ) ) ), ); return $messages; }
Раздел "помощь" типа записи book:
// Раздел "помощь" типа записи book add_action( 'contextual_help', 'add_help_text', 10, 3 ); function add_help_text( $contextual_help, $screen_id, $screen ){ //$contextual_help .= print_r($screen); // используйте чтобы помочь определить параметр $screen->id if('book' == $screen->id ) { $contextual_help = ' <p>Напоминалка при редактировании записи book:</p> <ul> <li>Указать жанр, например Фантастика или История.</li> <li>Указать автора книги.</li> </ul> <p>Если нужно запланировать публикацию на будущее:</p> <ul> <li>В блоке с кнопкой "опубликовать" нажмите редактировать дату.</li> <li>Измените дату на нужную, будущую и подтвердите изменения кнопкой ниже "ОК".</li> </ul> <p><strong>За дополнительной информацией обращайтесь:</strong></p> <p><a href="/" target="_blank">Блог о WordPress</a></p> <p><a href="http://wordpress.org/support/" target="_blank">Форум поддержки</a></p> '; } elseif( 'edit-book' == $screen->id ) { $contextual_help = '<p>Это раздел помощи показанный для типа записи Book и т.д. и т.п.</p>'; } return $contextual_help; }
#3 Добавление элемента таксономии в ЧПУ
Для нового типа записи можно указать разные ЧПУ с помощью параметра rewrite
. Этот пример показывает, как добавить в ЧПУ нового типа записи таксономию.
Допустим, мы регистрируем типа записи catalog
и таксономию products
для него. Далее, нам нужно чтобы при публикации записи и выборе для нее элемента таксономии. Этот элемент добавлялся в ЧПУ и в результате ссылка на тип записи выглядела так:
http://example.com/post_type_name/taxonomy_term_name/post_name
.
Для этого нужно указать аргумент slug
в параметре rewrite
при регистрации типа записи:
'rewrite' => array( 'slug'=>'catalog/%products%', 'with_front' => false ), 'has_archive' => 'catalog', // если нужна страница архива тут указываем её ярлык а не true
Теперь нужно добавить хук, чтобы заменять %products%
при получении ссылки на запись через функцию get_permalink() и производные от нее функции:
## Отфильтруем ЧПУ произвольного типа // сам фильтр: apply_filters( 'post_type_link', $post_link, $post, $leavename, $sample ); add_filter('post_type_link', 'products_permalink', 1, 2); function products_permalink( $permalink, $post ){ // выходим если это не наш тип записи: без холдера %products% if( strpos($permalink, '%products%') === FALSE ) return $permalink; // Получаем элементы таксы $terms = get_the_terms($post, 'products'); // если есть элемент заменим холдер if( ! is_wp_error($terms) && !empty($terms) && is_object($terms[0]) ) $taxonomy_slug = $terms[0]->slug; // элемента нет, а должен быть... else $taxonomy_slug = 'no-products'; return str_replace('%products%', $taxonomy_slug, $permalink ); }
В результате ЧПУ записи будет как указано выше и ссылка будет распознаваться правилами перезаписи WordPress.
Для древовидных таксономий
Для древовидных таксономий, нужно будет собрать весь путь, сделать это поможет функция: get_term_parents_list()
// $tax_slug = get_term_parents_list( $term_id, $tax_name, array( 'separator' => '/', 'format' => 'slug', 'link' => false, 'inclusive' => true, ) );
Также важно, чтобы при реге типа записи, параметр hierarchical был false!
Заметки
Плагин для реги типа записи
Есть удобный плагин, который позволяет регистрировать новые типы записей (постов) и новые таксономии: Custom Post Type UI
Переименование заголовков типа записи
Если тип записи уже зарегистрирован, но нам нужно назвать его как-то иначе, используйте следующий код.
Этот код показывает, как переименовать стандартный тип записи "Записи" в "Статьи":
Подробнее читайте в вопросе.
—
Очень дешевые, но качественные подписчики в Инстаграме доступны по адресу https://doctorsmm.com/. Тут Вы сможете найти любое предложение персонально для Вашего аккаунта. На сайте представлено широкое разнообразие качества добавляемых страниц и скоростной режим, а также действует таргетирование аудитории по географическому признаку.
Заметки
- Global. Массив. $wp_post_types List of post types.
Список изменений
С версии 2.9.0 | Введена. |
С версии 3.0.0 | The show_ui argument is now enforced on the new post screen. |
С версии 4.4.0 | The show_ui argument is now enforced on the post type listing screen and post editing screen. |
С версии 4.6.0 | Post type object returned is now an instance of WP_Post_Type. |
С версии 4.7.0 | Introduced show_in_rest, rest_base and rest_controller_class arguments to register the post type in REST API. |
С версии 5.0.0 | The template and template_lock arguments were added. |
С версии 5.3.0 | The supports argument will now accept an array of arguments for a feature. |
С версии 5.9.0 | The rest_namespace argument was added. |