Самая важная часть любого веб-сайта на WordPress — контент. В WordPress по умолчанию определены различные типы контента и таксономий, но нередко вам требуется определить собственные типы контента для построения именно того сайта, который вам нужен.

За последние несколько лет WordPress представил несколько весьма продвинутых и простых в использовании инструментов для работы со всеми типами произвольного контента. Это помогло ему развиться в полноценную систему управления контентом, способную поддерживать абсолютно любые типы сайтов, вне зависимости от содержимого.

Стандартные типы записей WordPress

В WordPress по умолчанию (если вы не ставили никаких тем и плагинов) уже есть несколько типов постов:

Post Записи (Post Type: ‘post’)
Page Страницы (Post Type: ‘page’)
Attachment Вложения (Post Type: ‘attachment’)
Revision Редакции (Post Type: ‘revision’)
Navigation Menu Навигационное меню (Post Type: ‘nav_menu_item’)
Custom CSS (Post Type: ‘custom_css’)
Changesets (Post Type: ‘customize_changeset’)

Абсолютно все типы записей в WordPress хранятся в одной таблице: wp_posts. Метаданные о постах, например, данные из метабоксов, хранятся в таблице wp_postmeta.

Записи или посты (post)

Самая используемая единица из всех типов, что есть в WordPress — Записи (они же посты, post). Используется в роли постов блога и тому подобного. Имеет 2 предустановленных таксономии: рубрики, они же категории (category) и метки, они же теги (post_tag).

Таксономии служат для сортировки и упорядочивания записей.

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

Теги являются независимыми друг от друга единицами и этим чем-то похожи на Записи.

Также, по умолчанию, из записей формируется RSS лента сайта на WordPress.

Для Записей используются следующие файлы шаблонов (в порядке приоритета):

single-post.php
single.php
singular.php
index.php

Файлы шаблонов ищутся сверху вниз по списку в порядке приоритета. Если файл шаблона найден в теме, используется он, а поиск прекращается.

Страницы (page)

Страницы используются, в основном, в роли служебных страниц, посадочных страниц — лендингов, сборника энциклопедии и тому подобного. Имеют древовидную иерархию, то есть могут быть вложенными друг в друга, что отразится в адресе конечной страницы (ярлыки родительских будут присутствовать в цепочке URL), и в этой роли имеется возможность выставить им приоритет в сортировке.

Создаем специальный шаблон страницы (page)

Где-нибудь внутри темы в корне или ее поддиректории создать файл с произвольным названием и расширением php, например, landing.php. Внутри вы можете разместить совершенно любой шаблон, который может быть абсолютно не похож на другие страницы сайта. Но главное, это поместить вот такой код в начало файла:

<?php

/* Template Name: Наш уникальный лендинг */

Template Name — это специальная метка, которая говорит WordPress о том, что этот файл — специальный шаблон.

Теперь при создании и редактировании любой страницы (page) посмотрите в блоке справа с названием Атрибуты страницы, в нём в разделе Шаблон вы можете выбрать наш уникальный лендинг.

Как настроить шаблон страницы

Для Страниц (Page) используется следующая иерархия шаблонов. Как и с Записями, указываю в порядке приоритета:

{шаблон}.php
page-{ярлык_страницы}.php
page-{ID_страницы}
page.php
singular.php
index.php

Прикрепления, вложения или аттачмены (attachment)

Служебный тип, предназначенный для хранения информации о файлах (изображениях, аудио, видео и тому подобных), которые загружались через загрузчик в стандартном редакторе WordPress при редактировании Записи, Страницы или подобного: размер, вес, описание, к какому посту или странице прикреплены, и тому подобное.

Получить вложения для последующей манипуляции над ними можно с помощью следующего кода:

Получаем Аттачменты

$args = array(

‘post_type’ => ‘attachment’, // Тип поста: attachment

‘post_status’ => ‘inherit’, // По умолчанию «publish», а с ним вложения не получить,

//поэтому указываем специальный статус вложения «inherit»

);

$p = get_posts( $args );

//exit( print_r( $p ) ); // На выходе будем иметь массив с вложениями

Иерархия шаблонов для аттачментов:

{mime-тип}.php
{mime-подтип}.php
{mime-тип-подтип}.php
attachment.php
single.php
singular.php
index.php

Редакции, черновики или ревизии (revision)

Редакции, они же Ревизии — это версии черновиков записей, которые создаются автоматически, пока вы пишете статью в административной панели Вордпресса или сохраняете статью без фактической ее публикации.

В процессе написания, для каждой статьи по умолчанию сохраняется каждая версия черновика. Можно сравнить две разные версии, и к нужной можно откатиться назад.

Хранить помногу версий одной и той же статьи — довольно накладно и часто бессмысленно (хотя, наверное, правильнее было бы оставлять всё по умолчанию, регулярно подчищая старые редакции с помощью плагина, например WP Optimize), поэтому число сохраняемых версий Ревизий можно изменить с помощью 2 вариантов:

Использовать фильтр wp_revisions_to_keep
Прописать в wp-config.php

//Отключаем ревизии до минимально возможного значения

define( ‘WP_POST_REVISIONS’, 0 );

Возможные значения:

true или -1: сохраняет каждую версию черновика. Вариант по умолчанию
false или 0: отключает сохранение черновиков, кроме 1 автосохранения
Целое число больше нуля: сохраняется указанное число версий черновиков + 1 автосохранение. Старые версии, не укладывающиеся в указанное число, автоматически удаляются

Элементы навигационного меню (nav_menu_item)

Навигационное меню (nav_menu_item) — это тип записей, который хранит информацию об единице навигации в WordPress. Первый, и пока единственный тип записи, который используется не как остальные типы записей, данные для работы и отображения на сайте получают свои отдельные функции.

Также, навигационные меню по умолчанию не включены. Чтобы их включить, нужно объявить об их поддержке в functions.php:

Прописать

add_theme_support( ‘menus’ );

Или зарегистрировать место под меню с помощью register_nav_menu(), тогда поддержка меню включится автоматически

Для получения данных пользуйтесь wp_nav_menu(), потому что WP_Query не будет работать, и это отличительная особенность типа постов nav_menu_item

Пытаемся получить данные по типу поста nav_menu_item

// Этот код сработает

wp_nav_menu(); // Выведет первое зарегистрированное непустое меню

// А код ниже работать не будет

$args = array(

‘post_type’ => ‘nav_menu_item’, // Тип поста: page, attachment, …

);

$p = get_posts( $args );

exit( print_r( $p ) ); // На выходе будем иметь пустой массив

Определение пользовательского типа постов

WordPress может хранить и отображать множество различных типов контента. Одна часть данного контента называется постом, хотя пост сам по себе является специфическим типом постов. «Все типы постов хранятся в одном месте, в таблице wp_posts базы данных, но посты различаются по колонке post_type»

Post type относится к различным структурированным данным, сгруппированным вместе, и которые обслуживаются в базе данных WordPress в таблице posts.

Примером типа постов служит тип post (группа постов из блога), page (группа страниц), attachment (группа загружаемых медиа файлов), а также revision (группа редакций постов). Все эти типы родные или встроенные в WordPress. Зная, что такое тип поста, можно создать и зарегистрировать новый тип, который будет относиться к кастомным типам постов.

Если вы создаете сайт для компании или бизнеса на WordPress, то типами постов могут быть Portfolio, Testimonials и Products. Теперь, когда мы разобрались с концепцией пользовательских типов постов, давайте научимся их создавать. Не забывайте, что пользовательские типы записей могут быть абсолютно чем угодно, не только доступными публично фрагментами контента. Например, вы можете установить пользовательский тип записи как журнал ошибок, чтобы отслеживать ошибки в приложении. Здесь вы ограничены только собственным воображением.

Как правильно подобрать название нового типа записи

В WordPress зарезервированы следующие названия, которые нельзя использовать в качестве имени нового типа записи:

post
page
attachment
revision
nav_menu_item
action
theme
order

Также, стоит воздержаться от использования префикса wp_ в начале названия, так как, возможно, это вызовет конфликты с будущими версиями ядра WordPress.

Лучше всего, если вы будете предварять названия произвольными префиксами, связанными с названием вашего сайта, продукта или бренда, например step_by_step_product, тогда гарантированно избежите потенциальных конфликтов

Как создать пользовательский тип постов

Создать пользовательский тип постов довольно просто. Сперва, необходимо зарегистрировать тип при помощи функции register_post_type().

register_post_type( $post_type, $args );

Создает новый тип записи или изменяет имеющийся.

Тип записи должен создаваться в момент хука-события init. Он не будет создан, если прикрепить функцию до init и может работать неправильно, если использовать после.

В качестве названия для нового типа записи нужно указывать уникальное имя, отличное от уже имеющихся таксономий, типов записей и зарезервированных WordPress публичных и частных переменных.

С версии 4.6 был создан новый класс WP_Post_Type и весь код функции теперь обрабатывается этим классом, а эта функция стала оберткой для него.

Таксономии

Если для нового типа записи регистрируется таксономия, то всегда регистрируйте эту таксономию при регистрации типа записи, для этого используя параметр taxonomies. Если вы этого не сделаете, тип поста и таксономии не будут опознаны как связанные при срабатывании хуков, таких как: parse_query или pre_get_posts. Это может привести к неожиданным последствиям и ошибкам.

Таксономии нужно регистрировать отдельно. Т.е. несмотря на то, что вы указали таксономии при регистрации нового типа записи, вы должны отдельно зарегистрировать эти таксономии используя register_taxonomy().

Зарезервированные типы постов

Нельзя использовать следующие названия для новых типов постов, так как они используются WordPress:

post, page, attachment, revision, nav_menu_item — типы постов WordPress;
action, order, theme — названия, которые используются в функциях WordPress.

Во избежании конфликтов с уже используемыми типами постов рекомендуется использовать префикс в названии нового типа поста или указывать уникальную строку.

register_post_type( $post_type, $args );

registered_post_type — возвращает WP_Post_Type объект (с версии 4.6).

Важно: поcле создания нового типа записи. Обязательно нужно зайти в «Настройки» > «Постоянные ссылки» и просто нажать там кнопку «Сохранить изменения». Нужно это для того, чтобы правила ЧПУ были пересозданы и туда были добавлены правила нового типа записи.

Шаблон для создания нового типа записи

add_action(‘init’, ‘register_post_types’);
function register_post_types(){
register_post_type(‘post_type_name’, array(
‘label’ => null,
‘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’ => », // для родителей (у древовидных типов)
‘menu_name’          => ‘____’, // название меню
),
‘description’         => »,
‘public’              => false,
‘publicly_queryable’ => null,
‘exclude_from_search’ => null,
‘show_ui’             => null,
‘show_in_menu’        => null, // показывать ли в меню адмнки
‘show_in_admin_bar’   => null, // по умолчанию значение show_in_menu
‘show_in_nav_menus’   => null,
‘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’            => array(‘title’,‘editor’), // ‘title’,’editor’,’author’,’thumbnail’,’excerpt’,’trackbacks’,’custom-fields’,’comments’,’revisions’,’page-attributes’,’post-formats’
‘taxonomies’          => array(),
‘has_archive’         => false,
‘rewrite’             => true,
‘query_var’           => true,
) ); }

$post_type(строка) (обязательный)

Название типа записи (максимум 20 символов). Может содержать только строчные символы, числа, _ или -: a-z0-9_-. пробелы запрещены максимальная длина — 20 символов. По умолчанию: нет

$args(массив) — массив аргументов, по умолчанию: нет

Аргументы параметра $args

label (строка)
labels (массив)
description (строка)
public (логический)
publicly_queryable (логический)
exclude_from_search (логический)
show_ui (логический)
show_in_menu (строка/логический)
show_in_admin_bar (логический)
show_in_nav_menus (логический)
show_in_rest (логический)
rest_base (строка)
rest_controller_class (строка)
menu_position (число)
menu_icon (строка)
capability_type (строка/массив)
capabilities (массив)
map_meta_cap (логический)
hierarchical (логический)
supports (массив)
register_meta_box_cb (строка)
taxonomies (массив)
permalink_epmask (строка)
has_archive (строка/логический)
rewrite (массив/логический)
query_var (строка/логический)
can_export (логический)
delete_with_user (логический)
_builtin (логический)
_edit_link (строка)

label(строка) -имя типа записи помеченное для перевода на другой язык. По умолчанию: $post_type

labels(массив) — массив содержащий в себе названия ярлыков для типа записи.

Для нового типа записи, если для неустановленных строк, будут использованы названия (ярлыки) «постов» у не древовидных типов и ярлыки «постоянных страниц» древовидных типов. См. get_post_type_labels()

В массиве можно указать следующие аргументы:

name — основное название для типа записи, обычно во множественном числе. По умолчанию: если не установлено, name и singular_name примят значение аргумента label
singular_name — название для одной записи этого типа
add_new — текст для добавления новой записи, как «добавить новый» у постов в админ-панели. Если нужно использовать перевод названия, вписывайте подобным образом: _x(‘Add New’, ‘product’);
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
insert_into_item — вставить в запись
uploaded_to_this_item — загружено для этой записи
featured_image — миниатюра записи
set_featured_image — установить миниатюру записи
remove_featured_image — удалить миниатюру записи
use_featured_image — использовать как миниатюру записи
filter_items_list — фильтровать список записей
items_list_navigation — навигация по записям
items_list — список записей
menu_name — название меню. По умолчанию равен name.
name_admin_bar — название в админ баре (тулбаре). По умолчанию равен singular_name.
view_items — название в тулбаре, для страницы архива типа записей. По умолчанию: «View Posts» / «View Pages». С WP 4.7.
attributes — название для метабокса атрибутов записи. У страниц такой метабокс называется «Свойства страницы» («Page Attributes»). По умолчанию: «Post Attributes» или «Page Attributes». С WP 4.7.

description(строка) — короткое описание этого типа записи. По умолчанию: »

public(логический) — определяет является ли тип записи публичным или нет. На основе этого параметра строятся много других, т.е. это своего рода предустановка для комплекса других параметров.

false
- не показывать пользовательский интерфейс (UI) для этого типа записей (show_ui=false)
- запросы относящиеся к этому типу записей не будут работать в шаблоне (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(логический) — запросы относящиеся к этому типу записей будут работать во фронтэнде (в шаблоне сайта).

По умолчанию: значение глобального аргумента (public)

exclude_from_search(логический) — исключить ли этот тип записей из поиска по сайту. 1 (true) — да, 0 (false) — нет.

Если этот параметр установлен в true, то для терминов таксономий привязанных к этому типу записей, вывод работать не будет (пусть даже параметр public равен true). Т.е. этот тип постов будет полностью исключен из запросов типа query_posts()!

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

show_ui(логический) — показывать ли меню для управления этим типом записи в админ-панели. false — не показывать меню, true — показывать меню в админ-панели. По умолчанию: значение аргумента public

show_in_menu(строка/логический) — показывать ли тип записи в администраторском меню и где именно показывать управление этим типом записи. Аргумент show_ui должен быть включен!

false — не показывать в администраторском меню.
true — показывать как меню первого уровня.
строка — показывать как страницу первого уровня, как например ‘tools.php’ или ‘edit.php?post_type=page’

ЗАМЕТКА: Если используется строка для того, чтобы показать как подменю, какого-нибудь главного меню, создаваемого плагином, этот пункт станет первым в списке и соответственно изменит расположение пунктов меню. Для того, чтобы этого не произошло, в плагине, который создает свое меню нужно установить приоритет для действия admin_menu 9 или ниже.

По умолчанию: null

show_in_admin_bar(логический) — сделать этот тип доступным из админ бара. По умолчанию: null (значение $show_in_menu)

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

show_in_rest(логический) — нужно ли включать тип записи в REST API. С WP 4.7.

rest_base(строка) — ярлык в REST API. По умолчанию, название типа записи. С WP 4.7. По умолчанию: $post_type

rest_controller_class(строка) — название класса контроллера в REST API. С WP 4.7. По умолчанию: ‘WP_REST_Terms_Controller’

menu_position(число) — позиция где должно расположится меню нового типа записи:

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

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

С выходом WordPress 3.8 появился новый пакет иконок Dashicons, который входит в состав ядра WordPress. Это комплект из более 150 векторных изображений. Чтобы установит одну из иконок, напишите её название в этот параметр. Например иконка постов, называется так: dashicons-admin-post, а ссылок dashicons-admin-links. По умолчанию: 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’.

По умолчанию: «post»

Пример: допустим мы указали тут строку bill что равносильно array(‘bill’, ‘bills’), тогда WordPress автоматически сгенерирует следующие права для параметра ‘capabilities’:

[cap] => stdClass Object (

[edit_post] => edit_bill

[read_post] => read_bill

[delete_post] => delete_bill

[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

[create_posts] => edit_bills )

Чтобы посмотреть какие права были созданы, загляните в глобальную переменную: $GLOBALS[‘wp_post_types’][‘bill’].

capabilities(массив) — массив прав для этого типа записи.

По умолчанию, доступны 8 элементов массива, которые определяют права для этого типа записей (даже если map_meta_cap = false), это:

edit_post, read_post и delete_post — 3 разрешения контролирующие редактирование, прочтение и удаление типа записи. Это мета-права: не примитивные права, которые требуют вычислений на лету. Они не записываются в список прав каждого пользователя, а превращаются в примитивные права на лету с помощью функции map_meta_cap().
create_posts — алиас: тоже самое что и право edit_posts.
edit_posts — контролирует возможность редактировать объекты этого типа записи.
edit_others_posts — контролирует возможность редактировать объекты этого типа записей, которые принадлежат другому пользователю. Если тип записи не поддерживает авторов, то поведение этого аргумента будет похоже на edit_posts.
publish_posts — контролирует публикацию объектов этого типа записи.
read_private_posts — контролирует возможность прочтения личных объектов (записей).

Заметка: последние 4 примитивных права, используются в движке в разных местах.

Также, существуют еще 8 примитивных прав, которые не относятся напрямую к ядру. Но которые относятся к функции map_meta_cap() и проверяются там. Они устанавливаются автоматически, если указан параметр ‘map_meta_cap’ как true:

read — разрешает просматривать объект во фронт-энде.
delete_posts — разрешает удалять объект этого типа записи.
delete_private_posts — разрешает удалять личный объект этого типа записи.
delete_published_posts — разрешает удалять опубликованные объекты этого типа записи.
delete_others_posts — разрешает удалять записи принадлежащие другим автора. Если у записи нет автора, то поведение передается delete_posts.
edit_private_posts — разрешает редактировать личные записи.
edit_published_posts — разрешает редактировать опубликованные записи.
create_posts — разрешает создавать новые записи.

Заметка: Чтобы пользователь мог создавать новые записи, его роль должна кроме прочего иметь право ‘edit_posts’.

Этот параметр обычно устанавливается автоматически, опираясь на ‘capability_type’. Например если установить ‘capability_type’ и ‘map_meta_cap’, затем посмотреть в переменную $GLOBALS[‘wp_post_types’][‘post_type’], то мы увидим такой объект:

[cap] => stdClass Object (

// Мета возможности

[edit_post] => «edit_{$capability_type}»

[read_post] => «read_{$capability_type}»

[delete_post] => «delete_{$capability_type}»

// Примитивные права используются за пределами map_meta_cap():

[edit_posts] => «edit_{$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_posts] => «delete_{$capability_type}s»

[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»

[create_posts] => «edit_{$capability_type}s» )

где, s — это множественное число. По умолчанию: используется аргумент capability_type для построения списка разрешений

map_meta_cap(логический) — ставим true, чтобы включить дефолтный обработчик специальных прав map_meta_cap(). Он преобразует неоднозначные права (edit_post — один пользователь может, а другой нет) в примитивные (edit_posts — все пользователи могут). Обычно для типов постов этот параметр нужно включать, если типу поста устанавливаются особые права (отличные от ‘post’). Если установить в false, то стандартная роль «Администратор» не сможет редактировать этот тип записи. Для снятия такого ограничения придется добавить право ‘edit_{post_type}s’ к роли администратор. По умолчанию: false

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

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

supports(массив) — вспомогательные поля на странице создания/редактирования этого типа записи. Метки для вызова функции add_post_type_support().

title — блок заголовка;
editor — блок для ввода контента;
author — блог выбора автора;
thumbnail блок выбора миниатюры записи;
excerpt — блок ввода цитаты;
trackbacks — блок уведомлений;
custom-fields — блок установки произвольных полей;
comments — блок комментариев;
revisions — блок ревизий (не отображается пока нет ревизий);
page-attributes — блок атрибутов постоянных страниц (шаблон и древовидная связь записей, древовидность должна быть включена). Может быть использовано вместо.
post-formats – блок форматов записи, если они включены в теме.

По умолчанию: array(‘title’,’editor’)

register_meta_box_cb(строка) — callback функция, которая будет срабатывать при установки мета блоков для страницы создания/редактирования этого типа записи. Используйте remove_meta_box() и add_meta_box() в callback функции. По умолчанию: нет

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, то наш тип записи будет иметь все конечные точки, которые предусмотрены для постоянных страниц и меток.

По умолчанию permalink_epmask = EP_PERMALINK — это означает, что в URL создаваемого типа записи (в правила ЧПУ) будут добавлены конечные точки, которые добавляются к обычным записям WordPress.

Если не нужно добавлять никаких конечных точек к новому типу записи, то нужно указать EP_NONE. Или указываем EP_ALL, когда нужно добавить все конечные точки.

По умолчанию: EP_PERMALINK

has_archive(строка/логический) — включить поддержку страниц архивов для этого типа записей (пр. УРЛ записи выглядит так: site.ru/type/post_name, тогда УРЛ архива будет такой: site.ru/type. Если указать строку, то она будет использована в ЧПУ. Например, укажем тут typepage и получим ссылку на архив типа записи такого вида: site.ru/typepage. Файл этого архива в теме будет иметь вид archive-type.php). Для архивов будет добавлено новое правило ЧПУ, если аргумент rewrite включен. По умолчанию: false

rewrite(массив/логический) — использовать ли ЧПУ для этого типа записи. Чтобы не использовать ЧПУ укажите false. По умолчанию: true — название типа записи используется как префикс в ссылке. Можно в массиве указать дополнительные параметры для построения ЧПУ:

slug (строка) — префикс в ЧПУ и ярлык_записи. Используйте array( ‘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

query_var(строка/логический) — ставим false, чтобы убрать возможность запросов или устанавливаем название запроса для этого типа записей, по умолчанию: true — устанавливается аргумент $post_type

can_export(логический) — возможность экспорта этого типа записей, по умолчанию: true

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

true — удалять записи этого типа принадлежащие пользователю при удалении пользователя. Если включена корзина, записи не удаляться, а поместятся в корзину.
false — при удалении пользователя его записи этого типа никак не будут обрабатываться.
null — записи удаляться или будут перемещены в корзину, если post_type_supports(‘author’) установлена. И не обработаются, если поддержки ‘author’ у типа записи нет.

По умолчанию: null

_builtin(логический) — для внутреннего использования! True, если это встроенный/внутренний типа записи, по умолчанию: false

_edit_link(строка) — для внутреннего использования! Часть URL в ссылке на редактирования этого типа записи.

Вы можете зарегистрировать тип записи в WordPress в двух разных местах:

первое — это файл темы functions.php; второе — это пользовательский плагин.

Вы можете добавить приведенный ниже код и в пользовательский плагин, но для’

данного примера внесем его в файл темы functions.php

Регистрация нового типа записи

Пример регистрации произвольного типа записей «book»:

add_action(‘init’, ‘my_custom_init’);

function my_custom_init(){

register_post_type(‘book’, 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’ => »,

‘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’)

) ); }

Пример

Шаг 1. register_post_type()

Создадим пользовательский тип записи Book. Для этого создадим класс includes\custom_post_type\BookPostType

namespace includes\custom_post_type;

class BookPostType

{

public function __construct()

{

* Регистрируем Custom Post Type

add_action( ‘init’, array( $this, ‘registerBookPostType’ ) );

}

public function registerBookPostType(){

* Регистрируем новый тип записи

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’)

) );

}

Теперь нам нужно создать экземпляр класса includes\custom_post_type\BookPostType в методе конструкторе класса includes\StepByStepPlugin

class StepByStepPlugin

{

private static $instance = null;

private function __construct() {

StepByStepLoader::getInstance();

add_action(‘plugins_loaded’, array(&$this, ‘setDefaultOptions’));

// Создаем Custom Post Type Book

new BookPostType();

}

…

}

Заходим в панель администратора и увидим что у нас добавился раздел

WordPress автоматически создает пользовательский интерфейс администратора для нового пользовательского типа записи. Новый пункт меню позволяет вам создавать новые записи типа «Book», а также редактировать существующие записи

наравне с прочими в WordPress.

Шаг 2. Тексты уведомлений для типа постов

Сообщения при публикации или изменении типа записи book

Добавим нестандартное сообщения об изменении записи.

Наверное вы понимаете, о каких уведомлениях идет речь. Это сообщения, которые появляются в верхней части экрана при например сохранении или обновлении поста.

Если вы пропустите этот шаг, то по умолчанию будут использоваться уведомления из записей типа post.

namespace includes\custom_post_type;

class BookPostType

{

public function __construct()

{

* Регистрируем Custom Post Type

add_action( ‘init’, array( &$this, ‘registerBookPostType’ ) );

// Сообщения при публикации или изменении типа записи book

add_filter(‘post_updated_messages’, array( &$this, ‘bookUpdatedMessages’ ));

}

public function bookUpdatedMessages(){

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 запланирована на: %1$s. <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;

}

Шаг 3. Вкладка «Помощь»

Раздел «помощь» типа записи book

Вкладка «Помощь» находится в правой верхней части экрана. Для нашего типа поста её ещё пока что нет, но вы сможете найти её на странице редактирования записей например.

Да, содержимое этой вкладки мы тоже можем настроить. Это обычно бывает полезно при работе с клиентами, для которых админка WordPress не легка в освоении. Туда можно засунуть какую-нибудь справочную информацию и не только.

Следующий код будет работать в версиях WordPress 3.3 и выше.

class BookPostType

{

public function __construct()

{

* Регистрируем Custom Post Type

add_action( ‘init’, array( &$this, ‘registerBookPostType’ ) );

// Сообщения при публикации или изменении типа записи book

add_filter(‘post_updated_messages’, array( &$this, ‘bookUpdatedMessages’ ));

// Раздел «помощь» типа записи book

add_action( ‘contextual_help’, array( &$this, ‘addHelpText’ ), 10, 3 );

}

public function addHelpText($contextual_help, $screen_id, $screen ){

//$contextual_help .= print_r($screen); // используйте чтобы помочь определить параметр $screen->id

if(‘book’ == $screen->id ) {

$contextual_help = ‘

Напоминалка при редактировании записи book:

<ul>

<li>Указать жанр, например Фантастика или История.</li>

<li>Указать автора книги.</li>

</ul>

Если нужно запланировать публикацию на будущее:

<ul>

<li>В блоке с кнопкой «опубликовать» нажмите редактировать дату.</li>

<li>Измените дату на нужную, будущую и подтвердите изменения кнопкой ниже «ОК».</li>

</ul>

За дополнительной информацией обращайтесь:

<a href=»/» target=»_blank»>Блог о WordPress</a>

<a href=»http://wordpress.org/support/» target=»_blank»>Форум поддержки</a>

‘; }

elseif( ‘edit-book’ == $screen->id ) {

$contextual_help = ‘Это раздел помощи показанный для типа записи Book и т.д. и т.п.’ }

return $contextual_help;

} }

Шаг 4. Обновление постоянных ссылок

Завершающий штрих. Если на вашем сайте включены пермалинки, то, для того, чтобы страницы типа поста корректно отображались (и отображались вообще), переходим в Параметры > Постоянные ссылки и, ничего не меняя, нажимаем «Сохранить изменения».

Шаблоны для пользовательский типов постов

Всё зависит от того, какого рода информация отображается. Вариантов может быть 3: шаблон конкретной записи, шаблон архивов записей и шаблон таксономий

Шаблон страницы записи

Перечисляются в порядке приоритета

single-{тип_поста}.php
single.php
index.php
{тип_поста} в нашем случае, здесь и далее — это sheensay_product

Шаблон архива записей

archive-{тип_поста}.php
archive.php
index.php

Шаблон произвольной таксономии

taxonomy-{имя_таксономии}-{имя_термина}.php
taxonomy-{имя_таксономии}.php
taxonomy.php
archive.php
index.php

Как получить данные пользовательский типа записей

Получить данные произвольного типа записей (Custom Post Type) в WordPress для отображения на сайте можно теми же способами, что и обычные Записи и Страницы

Используем WP_Query

$args = array(

‘post_type’ => book, // Указываем наш новый тип записи

‘posts_per_page’ => 10,

);

$p = get_posts( $args );

foreach ( $p as $post ) {

setup_postdata( $post );

<?php } wp_reset_postdata(); ?>

Если же говорить про главный запрос, по которому данные, например, предзагружаются для вывода на главной странице или стандартных страницах архивов, то произвольные типы записей там отключены.

Поэтому, если вы хотите, чтобы какая-либо созданный тип записей отображался, скажем, на страницах архивов наряду с обычными записями, вам нужно изменить фильтр предзагрузки постов

Предзагружаем book на стандартные страницы архивов

// Подключаем к стандартным ‘post’ и ‘page’ наш book

add_action( ‘pre_get_posts’, ‘add_sheensay_product_in_main_query’ );

function add_sheensay_product_in_main_query( $query ) {

if ( is_archive() && $query -> is_main_query() )

$query -> set( ‘post_type’, array( ‘post’, ‘page’, ‘book’ ) );

return $query; }

Taxonomies

Что Такое Таксономия?

Таксономия определяется как способ группировки схожих объектов. В первую

очередь таксономии дают возможность определять взаимосвязи внутри контента

сайта. В случае WordPress для группировки записей вы используете рубрики

и метки. Делая это, вы определяете таксономию записей. Таксономия может

быть иерархической (рубрики и подрубрики), но это не обязательно, как в случае

с метками.

Предустановленные таксономии

По умолчанию WordPress предоставляет три таксономии:

Рубрика (Category) — сегмент для группировки схожих записей.
Метка (Tag) — метка, прикрепляемая к записи.
Рубрика ссылок (Link category) — сегмент для группировки схожих ссылок.

Рубрики являются иерархическими и определяются при создании записи. Метки

не используют иерархию и также определяются при создании записи. Рубрики

ссылок используются при группировке схожих ссылок через менеджер ссылок

WordPress. Три предустановленные таксономии доступны для использования

в копии WordPress с настройками по умолчанию.

Каждая создаваемая рубрика или метка является элементом этой таксономии.

Например, рубрика «Музыка» является элементом таксономии рубрик, метка

«Кетчуп» — элемент таксономии меток. Понимание таксономии и ее элементов

поможет вам при определении пользовательских таксономий в WordPress.

Понимание того, как можно классифицировать контент с использованием единой

структуры таксономий, существенно облегчит структуризацию контента сайта

на WordPress с самого начала. Разработка рамок единой таксономии дает легкий

и прозрачный доступ к информации на веб-сайте.

Структура таблиц таксономии

WordPress содержит три таблицы базы данных, в которых хранится информация

по таксономии: wp_terms, wp_term_relationships и wp_term_taxonomy. Эта схема

таксономии, добавленная в WordPress 2.3, делает функциональность таксономии

в WordPress невероятно гибкой, то есть вы можете создавать и определять любые

типы пользовательской таксономии для использования на сайте.

В таблице wp_terms хранятся все элементы таксономии. Это могут быть рубрики,

метки, рубрики ссылок и определенные вами пользовательские элементы таксономии.

Таблица wp_term_taxonomy определяет, к какой таксономии какой элемент

относится. Например, в этой таблице будут перечислены все ID меток со значением

таксономии post_tag. Если вы создали пользовательскую таксономию, ее значение

станет её именем. Таблица wp_term_relationships представляет собой таблицу

соотношений и объединяет элементы таксономии с контентом. Например, при

присвоении записи метки здесь создается новая запись, объединяющая ID записи

и ID элемента.

Понимание соотношений в таксономии

Чтобы в полной мере понять соотношения между таблицами таксономии, полезно

посмотреть на диаграмму структуры таблиц таксономии в базе данных на рис. 12.2.

Рис. 12.2. Структура таблиц таксономии

Как вы видите, три таблицы таксономии соединяются уникальными ID.

Построение собственных таксономий

У создания собственных таксономий множество преимуществ. Представьте, что

у вас есть блог-сайт о еде. При создании новых записей вы хотите пометить некий

рецепт как азиатский, но также маркировать его по ингредиентам, температуре

и времени приготовления и т. д. Создание пользовательских таксономий дает вам

свободу определения этих различных методов систематизации контента и расширяет

WordPress от программного обеспечения для ведения блогов до полноценной

системы управления контентом (CMS).

Обзор пользовательских таксономий

После исправления схемы таксономии в WordPress 2.3 у вас есть возможность

определять пользовательские таксономии для контекста. WordPress сделал создание

и интеграцию новых таксономий простым как никогда.

В WordPress 2.8 была добавлена возможность автоматического отображения метаполя

на экран редактирования типа записи для добавления элементов таксономии непосредственно в записи. WordPress также создает иконку в меню для доступа к новой панели управления таксономиями для администрирования элементов таксономии.

Создание индивидуальных таксономий

Пришло время построить первую пользовательскую таксономию! Вы собираетесь

создать первую таксономию для пользовательского типа записи book, который вы зарегистрировали ранее. Если вы продаете книги онлайн, вам необходимо

найти способ группировать те или иные типы книг. Вы собираетесь

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

в WordPress.

Сначала вам нужно определить новую таксономию с использованием функции

WordPress register_taxonomy().

register_taxonomy()

Добавляет (регистрирует) новую (пользовательскую) таксономию. Можно перезаписать существующую таксономию.

Функцию желательно вызывать во время события init (хук):

add_action(‘init’, ‘function_name’);

В качестве названия для новой таксономии нужно указывать уникальное имя, отличное от уже имеющихся таксономий, типов постов и зарезервированных WordPress публичных и частных переменных.

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

Когда нужно зарегистрировать новый тип записи, используйте register_post_type()

Работает на основе: WP_Taxonomy()

Хуки из функции:

registered_taxonomy

Возвращает

Ничего или WP_Error.

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

register_taxonomy( $taxonomy, $object_type, $args );

Шаблон использования

// хук для регистрации

add_action(‘init’, ‘create_taxonomy’);

function create_taxonomy(){

// заголовки

// весь список: http://wp-kama.ru/function/get_taxonomy_labels

$labels = array(

‘name’ => ‘Genres’,

‘singular_name’ => ‘Genre’,

‘search_items’ => ‘Search Genres’,

‘all_items’ => ‘All Genres’,

‘parent_item’ => ‘Parent Genre’,

‘parent_item_colon’ => ‘Parent Genre:’,

‘edit_item’ => ‘Edit Genre’,

‘update_item’ => ‘Update Genre’,

‘add_new_item’ => ‘Add New Genre’,

‘new_item_name’ => ‘New Genre Name’,

‘menu_name’ => ‘Genre’, );

// параметры

$args = array(

‘label’ => », // определяется параметром $labels->name

‘labels’ => $labels,

‘description’ => », // описание таксономии

‘public’ => true,

‘publicly_queryable’ => null, // равен аргументу public

‘show_in_nav_menus’ => true, // равен аргументу public

‘show_ui’ => true, // равен аргументу public

‘show_tagcloud’ => true, // равен аргументу show_ui

‘show_in_rest’ => null, // добавить в REST API

‘rest_base’ => null, // $taxonomy

‘hierarchical’ => false,

‘update_count_callback’ => »,

‘rewrite’ => true,

//’query_var’ => $taxonomy, // название параметра запроса

‘capabilities’ => array(),

‘meta_box_cb’ => null, // callback функция. Отвечает за html код метабокса (с версии 3.8): post_categories_meta_box или post_tags_meta_box. Если указать false, то метабокс будет отключен вообще

‘show_admin_column’ => false, // Позволить или нет авто-создание колонки таксономии в таблице ассоциированного типа записи. (с версии 3.5)

‘_builtin’ => false,

‘show_in_quick_edit’ => null, // по умолчанию значение show_ui

);

register_taxonomy(‘taxonomy’, array(‘post’), $args );

}

$taxonomy(строка) (обязательный) — название создаваемой таксономии.

Может содержать только строчные латинские символы, числа и _, т.е. a-z0-9_.

$object_type(строка/массив) (обязательный)

Название типов постов, к которым будет привязана таксономия. В этом параметре, например, можно указать ‘post’, тогда у обычных постов WordPress появится новая таксономия (возможность классификации).

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

Аргументы параметра $args

label (строка)
labels (массив)
public (логический)
show_in_nav_menus (логический)
show_ui (логический)
show_tagcloud (логический)
show_in_rest (логический)
rest_base (строка)
rest_controller_class (строка)
hierarchical (логический)
update_count_callback (строка)
rewrite (массив/логический)
publicly_queryable (логический)
query_var (строка/логический)
capabilities (массив)
meta_box_cb (строка)
show_admin_column (логический)
sort (логический)
show_in_quick_edit (логический)
_builtin (логический) (не для обычного использования)

label(строка) — название таксономии во множественном числе (для отображения в админке). По умолчанию: используется значение аргумента $labels->name

labels(массив) — массив описывающий заголовки таксономии (для отображения в админке).

По умолчанию используются заголовки «меток» для не древовидных типов таксономий и заголовки «категорий» для древовидных таксономий.

name — имя таксономии, обычно во множественном числе. По умолчанию _x( ‘Post Tags’, ‘taxonomy general name’ ) или _x( ‘Categories’, ‘taxonomy general name’ );
singular_name — название для одного элемента этой таксономии. По умолчанию _x( ‘Post Tag’, ‘taxonomy singular name’ ) или _x( ‘Category’, ‘taxonomy singular name’ );
menu_name — текст для названия меню. Эта строка обозначает название для пунктов меню. По умолчанию значение параметра name;
search_items — текст для поиска элемента таксономии. По умолчанию __( ‘Search Tags’ ) или __( ‘Search Categories’ );
popular_items — текст для блока популярных элементов. __( ‘Popular Tags’ ) или null;
all_items — текст для всех элементов. __( ‘All Tags’ ) или __( ‘All Categories’ );
parent_item — текст для родительского элемента таксономии. Этот аргумент не используется для не древовидных таксономий. По умолчанию null или __( ‘Parent Category’ );
parent_item_colon — текст для родительского элемента таксономии, тоже что и parent_item но с двоеточием в конце. По умолчанию нет или __( ‘Parent Category:’ );
edit_item — текст для редактирования элемента. По умолчанию __( ‘Edit Tag’ ) или __( ‘Edit Category’ );
update_item — текст для обновления элемента. По умолчанию __( ‘Update Tag’ ) или __( ‘Update Category’ );
add_new_item — текст для добавления нового элемента таксономии. По умолчанию __( ‘Add New Tag’ ) или __( ‘Add New Category’ );
view_item — текст для просмотра термина таксономии. По умолчанию: «Посмотреть метку», «Посмотреть категорию».
new_item_name — текст для создания нового элемента таксономии. По умолчанию __( ‘New Tag Name’ ) или __( ‘New Category Name’ );
separate_items_with_commas — текст описывающий, что элементы нужно разделять запятыми (для блога в админке). Не работает для древовидного типа. По умолчанию __( ‘Separate tags with commas’ ) или null;
add_or_remove_items — текст для «удаления или добавления элемента», который используется в блоке админке, при отключенном javascript. Не действует для древовидных таксономий. По умолчанию __( ‘Add or remove tags’ ) или null;
choose_from_most_used — текст для блога при редактировании поста «выберите из часто используемых». Не используется для древовидных таксономий. По умолчанию __( ‘Choose from the most used tags’ ) или null;
popular_items — текст для поиска популярных терминов. Этот параметр не используется для древовидных таксономий. По умолчанию: «Популярные метки» или null.
separate_items_with_commas — текст говорящий о том, что термины (метки) нужно разделять запятыми. Не используется для древовидных таксономий. По умолчанию: «Разделяйте метки запятыми» или null.
add_or_remove_items — текст для добавления или удаления терминов. Не используется для древовидных типов. По умолчанию: «Добавить или удалить метки». или null.
choose_from_most_used — Текст «Выбрать из часто используемых». Не используется для древовидных типов.
not_found — Текст «не найдено», который отображается, если при клике на часто используемые ни один термин не был найден.

Весь список смотрите в описании get_taxonomy_labels()

По умолчанию: заголовки меток/категорий

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

Показывать ли эту таксономию в интерфейсе админ-панели. Это значение передается параметрам publicly_queryable, show_ui, show_in_nav_menus если для них не установлено свое значение.

По умолчанию: true

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

true даст возможность выбирать элементы этой таксономии в навигационном меню.

По умолчанию: если нет, равно аргументу public

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

Показывать блок управления этой таксономией в админке.

По умолчанию: если нет, равно аргументу public

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

Создать виджет облако элементов этой таксономии (как облако меток).

По умолчанию: если нет, равно аргументу show_ui

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

Нужно ли включать таксономию в REST API. С WP 4.7.

rest_base(строка)

Ярлык в REST API. По умолчанию, название таксономии. С WP 4.7.

По умолчанию: $taxonomy

rest_controller_class(строка)

Название класса контроллера в REST API. С WP 4.7.

По умолчанию: ‘WP_REST_Terms_Controller’

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

true — таксономия будет древовидная (как категории). false — будет не древовидная (как метки).

По умолчанию: false

update_count_callback(строка)

Название функции, которая будет вызываться для обновления количества записей в данной таксономии, для типа(ов) записей которые ассоциированы с этой таксономией.

По умолчанию: нет

rewrite(массив/логический)

false — отключит перезапись. Если указать массив, то можно задать произвольный параметр запроса (query var). А по умолчанию будет использоваться параметр $taxonomy.

Возможные аргументы массива:

slug — предваряет посты этой строкой. По умолчанию название таксономии;
with_front — позволяет установить префикс для постоянной ссылки. По умолчанию true;
hierarchical — true — включает поддержку древовидных URL (с версии 3.1). По умолчанию false;

Массив передается в функцию add_permastruct(), поэтому тут также можно указать аргументы этой функции.

По умолчанию: true

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

Имеют ли пользователи доступ к элементам таксономии во внешней части сайта. Если не установлено, то берется значение параметра public. C версии 4.5.

По умолчанию: null (равен аргументу public)

query_var(строка/логический)

Если указать false, выключит параметры запроса и сам запрос. Или можно указать строку, чтобы изменить параметр запроса (query var). По умолчанию будет использоваться параметр $taxonomy — название таксономии.

По умолчанию: $taxonomy

capabilities(массив)

Массив прав для этой таксономии:

manage_terms — ‘manage_categories’
edit_terms — ‘manage_categories’
delete_terms — ‘manage_categories’
assign_terms — ‘edit_posts’

По умолчанию: нет

meta_box_cb(строка)

callback функция. Отвечает за то, как будет отображаться таксономия в метабоксе (с версии 3.8). Встроенные названия функций: post_categories_meta_box — показывать как категории, post_tags_meta_box — показывать как метки.Если указать false, то метабокс будет отключен вообще.

По умолчанию: null

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

Позволить или нет авто-создание колонки таксономии в таблице ассоциированного типа записи. (с версии 3.5)

По умолчанию: false

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

Следует ли этой таксономии запоминать порядок в котором созданные элементы (термины) прикрепляются к объектам (записям).

По умолчанию: null

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

Показывать ли таксономию в панели быстрого редактирования записи (в таблице, списке всех записей, при нажатии на кнопку «свойства»). С версии 4.2.

По умолчанию: null (значение show_ui)

_builtin(логический) (не для обычного использования)

Параметр предназначен для разработчиков. Если переключить на true, то это будет означать что эта таксономия относится к внутренним таксономия WordPress и не является встроенной (кастомной).

По умолчанию: false

Пример

Пример регистрации двух таксономий «genres» и «writers» для постов типа «book». Изменим класс includes\custom_post_type\BookPostType

namespace includes\custom_post_type;

class BookPostType

{

public function __construct()

{

* Регистрируем Custom Post Type

add_action( ‘init’, array( &$this, ‘registerBookPostType’ ) );

// хук, через который подключается функция

// регистрирующая новые таксономии createBookTaxonomies

add_action( ‘init’, array( &$this, ‘createBookTaxonomies’ ) );

// Сообщения при публикации или изменении типа записи book

add_filter(‘post_updated_messages’, array( &$this, ‘bookUpdatedMessages’ ));

// Раздел «помощь» типа записи book

add_action( ‘contextual_help’, array( &$this, ‘addHelpText’ ), 10, 3 );

}

public function registerBookPostType(){

* Регистрируем новый тип записи

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’),

‘taxonomies’ => array( ‘genre’, ‘writer’ ),

) ); }

public function createBookTaxonomies(){

// определяем заголовки для ‘genre’

$labels = array(

‘name’ => _x( ‘Genres’, ‘taxonomy general name’ ),

‘singular_name’ => _x( ‘Genre’, ‘taxonomy singular name’ ),

‘search_items’ => __( ‘Search Genres’ ),

‘all_items’ => __( ‘All Genres’ ),

‘parent_item’ => __( ‘Parent Genre’ ),

‘parent_item_colon’ => __( ‘Parent Genre:’ ),

‘edit_item’ => __( ‘Edit Genre’ ),

‘update_item’ => __( ‘Update Genre’ ),

‘add_new_item’ => __( ‘Add New Genre’ ),

‘new_item_name’ => __( ‘New Genre Name’ ),

‘menu_name’ => __( ‘Genre’ ),

);

// Добавляем древовидную таксономию ‘genre’ (как категории) жанр

register_taxonomy(‘genre’, array(‘book’), array(

‘hierarchical’ => true,

‘labels’ => $labels,

‘show_ui’ => true,

‘query_var’ => true,

‘rewrite’ => array( ‘slug’ => ‘genre’ ),

));

// определяем заголовки для ‘writer’

$labels = array(

‘name’ => _x( ‘Writers’, ‘taxonomy general name’ ),

‘singular_name’ => _x( ‘Writer’, ‘taxonomy singular name’ ),

‘search_items’ => __( ‘Search Writers’ ),

‘popular_items’ => __( ‘Popular Writers’ ),

‘all_items’ => __( ‘All Writers’ ),

‘parent_item’ => null,

‘parent_item_colon’ => null,

‘edit_item’ => __( ‘Edit Writer’ ),

‘update_item’ => __( ‘Update Writer’ ),

‘add_new_item’ => __( ‘Add New Writer’ ),

‘new_item_name’ => __( ‘New Writer Name’ ),

‘separate_items_with_commas’ => __( ‘Separate writers with commas’ ),

‘add_or_remove_items’ => __( ‘Add or remove writers’ ),

‘choose_from_most_used’ => __( ‘Choose from the most used writers’ ),

‘menu_name’ => __( ‘Writers’ ),

);

// Добавляем НЕ древовидную таксономию ‘writer’ (как метки)

register_taxonomy(‘writer’, ‘book’,array(

‘hierarchical’ => false,

‘labels’ => $labels,

‘show_ui’ => true,

‘query_var’ => true,

‘rewrite’ => array( ‘slug’ => ‘writer’ ),

)); } }

Metadata.

Что такое метаданные?

В WordPress под метаданными подразумеваются дополнительные фрагменты информации, прикрепленные к записи. Например, пользовательскому типу записей

book может потребоваться цена, хранящаяся вместе с каждым имеющимся товаром.

Цена может храниться в виде метаданных и легко отображаться на странице

с подробной информацией о товаре. Метаданные в терминологии WordPress часто называют произвольными (пользовательскими) полями (Custom Fields). Это более понятный пользователю термин,

используемый в консоли администратора. WordPress добавляет метаполе произвольных полей на экран редактирования записи по умолчанию. Если у пользовательского типа записи есть значение custom-fields, определенное для аргумента supports, это метаполе также появится.

Все метаданные хранятся в таблице wp_postmeta в базе данных WordPress.

Функции метаданных

add_metadata()

Добавляет мета (дополнительные) данные к любому объекту (запись, комментарий, пользователь).

delete_metadata()

Удаляет метаданные указанного объекта (пост, юзер, коммент).

get_metadata()

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

is_protected_meta()

Проверяет указанный ключ метаполя, не является ли он защищенным (внутренним).

register_meta()

Регистрирует метаполе (ключ произвольного поля).

sanitize_meta()

Очищает значение мета данных. Сама функция ничего не делает, а примеряет фильтр «sanitize_{$meta_type}_meta_{$meta_key}», через который разные мета данные можно очистить по-разному.

update_metadata()

Обновляет метаданные для указанного объекта (пост, юзер, коммент). Если указанных данных не найдено, то они будут добавлены, как новые.

add_post_meta()

Добавляет произвольное поле для определенного поста/записи.

delete_post_meta()

Удалят все произвольные поля с указанным ключом у указанного поста.

get_post_custom()

Возвращает многомерный массив с данными всех произвольных полей текущего поста.

get_post_custom_keys()

Возвращает массив с ключами произвольных полей, принадлежащих определенному посту.

get_post_custom_values()

Возвращает массив значений произвольных полей с определенным названием у определенного поста.

get_post_meta()

Возвращает значение указанного произвольного поля записи (поста). Можно получить массив всех полей записи (поста).

the_meta()

Выводит произвольные поля записи (мета данные расположенные в таблице wp_postmeta). Поля выводятся в списке <li>

update_post_meta()

Обновляет произвольное поле указанного поста или добавляет новое.

Блок произвольных полей в админке WordPress своими руками

Прежде чем начать рассказывать о том как создать произвольный блок данных в админ-панели на странице редактирования постов, который будет управлять указанными произвольными полями, следует отметить, что WordPress — платформа которая, пожалуй, как никакая другая поддается расширению с наименьшими усилиями. В частности, именно поэтому под WordPress написано так много плагинов — все очень просто, нужно лишь знать азы PHP и понимать принцип работы системы.

Каждый, кто достаточно близко знаком с WordPress неоднократно встречался с понятием «произвольные поля» и с их помощью решал некоторые нетривиальные задачи.

Произвольные поля в WordPress — очень удобный инструмент, когда нужно «прикрепить» к конкретному посту какие-либо дополнительные данные. Такими данными может быть что угодно, начиная от логических true/false (1/0), заканчивая объемными текстами, массивами и прочим. К примеру, мы можем создать новое произвольное поле Title и в его значение написать текст (альтернативный заголовок поста), затем в коде шаблона использовать следующий код, чтобы вывести этот текст:

<title><?php echo get_post_meta($post->ID, ‘title’, true); ?></title>

Следует отметить, что функцию get_post_meta() можно использовать за пределами Цикла WordPress, т.е. где угодно в шаблоне. В данном примере мы используем её в <head> части документа, чтобы дать html странице заголовок отличный от заголовка самой статьи (иногда полезно для SEO).

Произвольные поля используются в WordPress сплошь и рядом, различными плагинами оценки постов (WP-PostRatings), SEO плагинами (Platinum SEO Pack), позволяющими указать Title, Description, Keywords поста и многими другими плагинами. Образно говоря, каждая четвертая нестандартная задача решается посредством произвольных полей, поэтому если вы еще не знаете как их использовать, то ознакомьтесь с этим мануалом. А ниже мы поговорим о том, как создать отдельный блок с нужными нам произвольными полями и как сделать это без плагинов.

Мало кто знает, что если создать произвольное поле ключ которого (название) начинается на _ (нижнее подчеркивание), например _my_special_key, то такое поле не будет выводиться в выпадающем списке произвольных полей при редактировании постов и будет считаться «внутренним» произвольным полем, которое используется системой. Создать такое поле можно только запросом к БД, например, используя функции add_post_meta() или update_post_meta().

Создаем мета блок произвольных полей

Для создания метаблока нам понадобятся всего 2 хука: add_meta_boxes и save_post, функция add_meta_box()

add_meta_box()

Добавляет дополнительные блоки (meta box) на страницы редактирования/создания постов, постоянных страниц или произвольных типов записей в админ-панели.

Вызывается во время события (хука) add_meta_boxes. Для версий ниже 3.0 на хук admin_init.

Ничего не возвращает.

add_meta_box( $id, $title, $callback, $screen, $context, $priority, $callback_args );

$id(строка) (обязательный)

id атрибут HTML тега, контейнера блока.

По умолчанию: нет

$title(строка) (обязательный)

Заголовок/название блока. Виден пользователям.

По умолчанию: нет

$callback(строка) (обязательный)

Функция, которая выводит на экран HTML содержание блока. Должна выводить результат на экран.

По умолчанию: нет

$screen(строка/массив/WP_Screen)

Название экрана для которого добавляется блок. Смотрите get_current_screen(). Например может быть:

Для типов записей: post, page, link, attachment или custom_post_type
Или для других страниц админки: link, comment.
Можно указать несколько типов в массиве: array(‘post’, ‘page’). C версии 4.4.

По умолчанию: null (текущий экран)

$context(строка)

Место где должен показываться блок: normal, advanced или side.

По умолчанию: ‘advanced’

$priority(строка)

Приоритет блока для показа выше или ниже остальных блоков: high или low.

По умолчанию: ‘default’

$callback_args(массив)

Аргументы, которые нужно передать в callback функцию указанную в параметре $callback. callback функция получит данные поста (объект $post) и аргументы переданные в этом параметре.

По умолчанию: null

Пример

namespace includes\custom_post_type;

class BookPostType

{

public function __construct() {

// …. подключаем функцию активации мета блока (my_extra_fields)

add_action(‘add_meta_boxes’, array( &$this, ‘priceExtraFields’ ), 1);

// включаем обновление полей при сохранении

add_action(‘save_post’, array( &$this, ‘priceExtraFieldsUpdate’ ), 0); }

// Создадим новый мета блок для постов

public function priceExtraFields(){

add_meta_box(

‘price_extra_fields’, // id атрибут HTML тега, контейнера блока.

‘Стоимость’, // Заголовок/название блока. Виден пользователям.

array( &$this, ‘renderPriceExtraFields’ ), //Функция, которая выводит на экран HTML содержание блока

‘book’, // Название экрана для которого добавляется блок.

‘normal’, // Место где должен показываться блок

‘high’ // Приоритет блока для показа выше или ниже остальных блоков:

); }

// Заполним этот блок полями html формы.

// Делается это через, указанную в add_meta_box() функцию renderPriceExtraFields(). Именно она отвечает за содержание мета блока:

//Функция, которая выводит на экран HTML содержание блока

public function renderPriceExtraFields($post){

?><label>

<input type=»number» name=»price_extra[price]» value=»<?php echo get_post_meta($post->ID, ‘price’, 1); ?>» />

Стоимость

</label><?php }

* Сохраняем данные

* На этом этапе, мы уже создали блок произвольных полей, теперь нужно обработать данные полей при сохранении поста.

* Обработать, значит записать их в в базу данных или удалить от туда. Для этого используем хук save_post, который

* срабатывает в момент сохранения поста. В этот момент мы получим данные из массива price_extra[] и обработаем них:

public function priceExtraFieldsUpdate($post_id ){

if ( defined(‘DOING_AUTOSAVE’) && DOING_AUTOSAVE ) return false; // выходим если это автосохранение

if( !isset($_POST[‘price_extra’]) ) return false; // выходим если данных нет

// Все ОК! Теперь, нужно сохранить/удалить данные

$priceExtra = array_map(‘trim’, $_POST[‘price_extra’]); // чистим все данные от пробелов по краям

foreach( $priceExtra as $key=>$value ){

if( empty($value) ){

delete_post_meta($post_id, $key); // удаляем поле если значение пустое

continue; }

update_post_meta($post_id, $key, $value); // add_post_meta() работает автоматически

}

return $post_id; } }

Categories : Word Press, www

Discussions

admin 20 декабря, 2017

— установил фильтр лимита ревизии записей (2) и вывел в лог это значение
— установил новый шаблон для страницы: My Home Work Landing (файл с закомментированным заголовком, который определяется как шаблон)
— добавил кастомное поле к постам (Add New Custom Field): HomeWorkCustomFieldText со значением по умолчанию в виде текста
— зарегистрировал новую таксономию My New Home Work Topic (в файле functions.php)
— зарегистрировал новый пост-тип Home Work Production в файле плагина

#12. Post Type. Taxonomies. Metadata

Latest Posts

Стандартные типы записей WordPress

Записи или посты (post)

Страницы (page)

Создаем специальный шаблон страницы (page)

Прикрепления, вложения или аттачмены (attachment)

Редакции, черновики или ревизии (revision)

Элементы навигационного меню (nav_menu_item)

Определение пользовательского типа постов

Как правильно подобрать название нового типа записи

Как создать пользовательский тип постов

register_post_type( $post_type, $args );

Таксономии

Зарезервированные типы постов

Шаблон для создания нового типа записи

Аргументы параметра $args

Регистрация нового типа записи

Пример

Шаг 1. register_post_type()

наравне с прочими в WordPress.

Шаг 3. Вкладка «Помощь»

Шаг 4. Обновление постоянных ссылок

Шаблоны для пользовательский типов постов

Шаблон страницы записи

Шаблон архива записей

Шаблон произвольной таксономии

Как получить данные пользовательский типа записей

Taxonomies

Что Такое Таксономия?

Предустановленные таксономии

Структура таблиц таксономии

Понимание соотношений в таксономии

Построение собственных таксономий

Обзор пользовательских таксономий

Создание индивидуальных таксономий

register_taxonomy()

Хуки из функции:

Возвращает

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

Шаблон использования

Аргументы параметра $args

Пример

Metadata.

Что такое метаданные?

Функции метаданных

Блок произвольных полей в админке WordPress своими руками

Создаем мета блок произвольных полей

add_meta_box()

Пример

Discussions