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

Создаем кастомный тип записи (Custom Post Type) Articles с кастомными категориями (Custom Taxonomy) Articles Category .

В моем случае все стандартные записи – это Товары, поэтому Статьи выведем через кастомные записи.

В файле функций functions.php регистрируем кастомный тип записи Articles:

Function wptp_create_post_type() { $labels = array("name" => __("Articles"), "singular_name" => __("Articles"), "add_new" => __("New Article"), "add_new_item" => __("Add New Article"), "edit_item" => __("Edit Article"), "new_item" => __("New Article"), "view_item" => __("View Article"), "search_items" => __("Search Articles"), "not_found" => __("No Articles Found"), "not_found_in_trash" => __("No Articles found in Trash"),); $args = array("labels" => $labels, "has_archive" => true, "public" => true, "hierarchical" => false, "menu_position" => 5, "supports" => array("title", "editor", "excerpt", "custom-fields", "thumbnail"),); register_post_type("articles", $args); } add_action("init", "wptp_create_post_type");

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

"taxonomies" => array("category"),

Если для кастомных постов вы создаете еще и кастомные таксономии, то связывать их надо с созданными таксономиями, если брать пример ниже, то это будут articles_category

"taxonomies" => array("articles_category"),

Затем для кастомного типа записи Articles регистрируем таксономии ‘Article Category’, чтобы разные записи могли принадлежать разным категориям.

Function wptp_register_taxonomy() { register_taxonomy("articles_category", "articles", array("labels" => array("name" => "Article Categories", "singular_name" => "Article Category", "search_items" => "Search Article Categories", "all_items" => "All Article Categories", "edit_item" => "Edit Article Categories", "update_item" => "Update Article Category", "add_new_item" => "Add New Article Category", "new_item_name" => "New Article Category Name", "menu_name" => "Article Category",), "hierarchical" => true, "sort" => true, "args" => array("orderby" => "term_order"), "show_admin_column" => true)); } add_action("init", "wptp_register_taxonomy");

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

"rewrite" => array("slug" => "blog"),

При изменении слагов необходимо обновить настройки “Постоянных ссылок” в админке, иначе будете получать 404 ошибку вместо нужной страницы.

Больше примеров можно найти и . Но привести весь этот код в порядок помогла , за что автору большая благодарность.

За внешний вид кастомной записи отвечает файл single.php , но чтобы изменить вид кастомной записи можно создать файл single-{post_type}.php – в моем случае будет single-articles.php со своим содержимым.

Теперь нужно вывести кастомные записи на странице. По умолчанию за отображение архива кастомных записей отвечает файл index.php . Но можно создать файл, который будет отвечать за вывод кастомных записей в своей таксономии.

Вариант 1 – самый правильный. Выводим записи в таксономии так же как и в обычной категории.

Для этого создаем файл taxonomy-{taxonomy}.php – в моем случае будет taxonomy-articles_category.php и в нем выводим обычный цикл, как и для стандартных записей в категории:

В файле tax-item.php выводим данные, которые нам нужно получить из каждой записи, например, заголовок, ссылку на запись, миниатюру и excerpt.

В файле pagination.php выводим пагинацию вот такого формата .

Цикл не изменяем, пагинация отлично работает. Это самый оптимальный вариант для отображения Кастомных Таксономий.

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

Для этого в шаблоне создаем файл archive-{post_type}.php – в моем случае будет archive-articles.php , в котором точно так же как и в таксономии выводим обычный цикл, только вместо заголовка Таксономии выводим имя кастомного типа записи :

При этом варианте, если не создана страница архива для кастомной записи, тогда получить список всех кастомных записей можно по прямой ссылке BLOG_URL?post_type={post_type} или в моем случае http://site.com/articles/ .

Вариант 3. Просто выводим все кастомные записи Articles на странице с заданным шаблоном

"articles", "posts_per_page" => -1); $loop = new WP_Query($args); while ($loop->have_posts()) : $loop->the_post(); get_template_part("include/tax-item"); endwhile; ?>

get_template_part("include/tax-item"); – в файле tax-item.php я вывожу содержимое записи, которое нужно мне для отображения записей внутри цикла (заголовок, миниатюру, дату, цитату и т.д.)

Этот вариант выводит все записи Articles на странице, не зависимо от таксономий (категорий).

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

При этом, если вы используете плагин Yoast SEO и используете его хлебные крошки:

Тогда при выборе в настройках плагина таксономии “Articles Category” в “Taxonomy to show in breadcrumbs for post types”, в хлебных крошках вы получите ссылку на категорию, к которой принадлежит Новость, при других вариантах вывода кастомных записей это не получалось сделать.

Нашей статьи, посвященной созданию и использованию собственных типов записей, мы охватили суть пользовательских собственных типов записей в Wordpress, а также постарались начать работать над созданием собственных типов. Мы также осветили способы сохранения модульности за счет использования отдельного PHP-файла, что позволяет нам переносить типы записей от шаблона к шаблону.

Сегодня же мы хотим рассказать вам о процессе создания таксономии для собственных типов постов, а также о создании собственных полей и мета-блоков, о сохранении данных и использовании их в собственных шаблонах для Wordpress.

Давайте приступим!

Создание таксономии (для возможности сортировки по категории)

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

Для этого мы будем использовать Wordpress-функцию . Как вы можете видеть ниже и в codex.wordpress.org, аргументы, которые она принимает, это taxonomy, за которым следует тип объекта и, наконец, $args. Для нашего примера мы создали 2 таксономии – Skills и Club Level. Мы применяем таксономии к типу записей athlete, а затем задаем аргументы, включая ярлыки и переписываем привилегии. Давайте взглянем на код.

Register_taxonomy("Sport", array("athlete"), array("hierarchical" => true, "label" => "Sport", "singular_label" => "Sport", "rewrite" => true));
register_taxonomy("Club Level", array("athlete"), array("hierarchical" => true, "label" => "Club Level", "singular_label" => "Club Level", "rewrite" => true));
Зарегистрированные таксономии выглядят примерно следующим образом.

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

Закончили уже?

Хм, в целом, у вас уже есть собственный тип записи, который функционирует. Но на данный момент он ничем не отличается от обычных записей. Давайте окунемся в создание собственных полей для ваших записей, которые позволят вам указывать уникальную информацию, а затем отображать её в шаблонах.

Создание собственных полей

Для того чтобы начать творить настоящее волшебство с помощью собственных типов записей, для начала вам нужно будет инициализировать функцию для возможности добавлять мета-блоки. Нашу мы назовем admin_init(), и выглядеть она будет следующим образом:

Add_action("admin_init", "admin_init");

function admin_init(){
add_meta_box("personal_info", "Personal Info", "personal_info", "athlete", "normal", "low");
}
Первая часть нашего кода инициализирует функцию admin_init(). Понятно, что вторая часть данного кода представляет собой саму функцию. В целом, этот код сообщает вашему шаблону о необходимости создать новый мета-блок под названием «Personal Info», поместить его в тип записи athlete и затем дать ему низкий приоритет (расположение в типе записи).

Круто! Ну а теперь мы закончили?

Нет еще. Но уже совсем близко! Давайте добавим еще несколько собственных полей. Это больше относится к HTML, нежели к PHP.

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

А теперь начинается самое интересное. Мы собираемся создать мета-блок с личными данными (мы его уже сделали выше, а сейчас собираемся заполнить его), который будет спрашивать имя и фамилию человека, пол, адрес электронной почты, номер телефона и дату рождения.

Для того чтобы сделать это, мы создаем функцию под названием personal_info(). Та же функция, которую мы вызывали в функции admin_init(). А теперь, включаем свет? Все линии сходятся.

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

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

Таксономии

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

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

Важно: после создания нового типа записи. Обязательно нужно зайти на страницу Настройки → Постоянные ссылки. Нужно это для того, чтобы правила ЧПУ были пересозданы и туда были добавлены правила нового типа записи.

Возвращает

WP_Post_Type объект (с версии 4.6).

Шаблон для создания нового типа записи
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" => 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-z0-9_- .

Зарезервированные названия для типов постов . Нельзя использовать следующие названия для новых типов постов, так как они используются WordPress и ваш код будет конфликтовать с текущим кодом или функциями WordPress:

Post page attachment revision nav_menu_item custom_css customize_changeset action author order theme $args(массив) Массив аргументов.
По умолчанию: array() (параметры по умолчанию)

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

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

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

  • Для не древовидных типов записей - названия "постов".
  • Для древовидных типов записей - названия "постоянных страниц".

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

"name" => "", // основное название для типа записи, обычно во множественном числе. "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. "item_updated" => "", // Текст заметки в редакторе записи при обновлении записи. С WP 5.0. // По умолчанию: «Post updated.» / «Page updated.» "item_published" => "", // Текст заметки в редакторе записи при публикации записи. С WP 5.0. // По умолчанию: «Post published.» / «Page published.» "item_published_privately" => "", // Текст заметки в редакторе записи при публикации private записи. С WP 5.0. // По умолчанию: «Post published privately.» / «Page published "item_reverted_to_draft" => "", // Текст заметки в редакторе записи при возврате записи в draft. С WP 5.0. // По умолчанию: «Post reverted to draft.» / «Page reverted to "item_scheduled" => "", // Текст заметки в редакторе записи при запланированной публикации на будущую дату. С WP 5.0. // По умолчанию: «Post scheduled.» / «Page scheduled.»

Для полного списка значений см. get_post_type_labels()

По умолчанию: если не установлено, name и singular_name примят значение аргумента label

Description(строка) Короткое описание этого типа записи. Значение используется в REST API. Значение можно получить с помощью функции get_the_post_type_description() .
По умолчанию: "" public(логический)

Определяет является ли тип записи публичным или нет. На основе этого параметра строятся много других, т.е. это своего рода пред-установка для следующих параметров:

    • 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
  • title - блок заголовка;
  • editor - блок для ввода контента;
  • author - блок выбора автора;
  • thumbnail блок выбора миниатюры записи. Нужно также включить поддержку в установке темы post-thumbnails ;
  • 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() .

Этот параметр позволяет указать, какую группу конечных точек мы хотим подключить к создаваемому типу записи (к URL записи). Например, если указать "permalink_epmask" = EP_PAGES & EP_TAGS , то наш тип записи будет иметь все дополнительные варианты URL (конечные точки), которые предусмотрены для постоянных страниц и меток.

По умолчанию 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

По умолчанию: true (тип записи используется как префикс)

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

Устанавливает название параметра запроса для создаваемого типа записи.

Ставим false, чтобы убрать возможность запросов.

  • false - отключает параметр запроса. Запись не будет доступна по URL: /?{query_var}={post_slug} .
  • string - указывает название параметра зпроса. /?{query_var_string}={post_slug} .

Заметка: query_var не имеет смысла, если параметр publicly_queryable = false .

Заметка: Этот параметр добавляет указанное значение (если не указано, то ярлык типа записи) в список разрешенных параметров WordPress, чтобы 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" у типа записи нет.
// $tax_slug = get_term_parents_list($term_id, $tax_name, array("separator" => "/", "format" => "slug", "link" => false, "inclusive" => true,));

Также важно, чтобы при реге типа записи, параметр hierarchical был false !

#3 Добавление таксономии в ЧПУ (у записи и таксы одинаковый префикс)

Этот пример показывает как создать запись типа Вопросы и разделы для нее. При этом ЧПУ будут:

  • У записи: site.ru/faq/{категория}/{ярлык-записи}
  • У таксы: site.ru/faq/{категория}

Тут важно сначала регнуть таксу, а потом тип записи...

Add_action("init", "register_faq_post_type"); function register_faq_post_type() { // Раздел вопроса - faqcat register_taxonomy("faqcat", array("faq"), array("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", array("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"),)); } ## Отфильтруем ЧПУ произвольного типа // фильтр: apply_filters("post_type_link", $post_link, $post, $leavename, $sample); add_filter("post_type_link", "faq_permalink", 1, 2); function faq_permalink($permalink, $post){ // выходим если это не наш тип записи: без холдера %products% if(strpos($permalink, "%faqcat%") === false) return $permalink; // Получаем элементы таксы $terms = get_the_terms($post, "faqcat"); // если есть элемент заменим холдер if(! is_wp_error($terms) && !empty($terms) && is_object($terms)) $term_slug = array_pop($terms)->slug; // элемента нет, а должен быть... else $term_slug = "no-faqcat"; return str_replace("%faqcat%", $term_slug, $permalink); }

Заметки

Плагин для реги типа записи

Есть удобный плагин, который позволяет регистрировать новые типы записей (постов) и новые таксономии: Custom Post Type UI

Переименование заголовков типа записи

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

Этот код показывает, как переименовать стандартный тип записи "Записи" в "Статьи":

## заменим слово «записи» на «статьи» //$labels = apply_filters("post_type_labels_{$post_type}", $labels); add_filter("post_type_labels_post", "rename_posts_labels"); function rename_posts_labels($labels){ // заменять автоматически не пойдет например заменили: Запись = Статья, а в тесте получится так "Просмотреть статья" /* оригинал stdClass Object ("name" => "Записи", "singular_name" => "Запись", "add_new" => "Добавить новую", "add_new_item" => "Добавить запись", "edit_item" => "Редактировать запись", "new_item" => "Новая запись", "view_item" => "Просмотреть запись", "search_items" => "Поиск записей", "not_found" => "Записей не найдено.", "not_found_in_trash" => "Записей в корзине не найдено.", "parent_item_colon" => "", "all_items" => "Все записи", "archives" => "Архивы записей", "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_admin_bar" => "Запись",) */ $new = array("name" => "Статьи", "singular_name" => "Статья", "add_new" => "Добавить статью", "add_new_item" => "Добавить статью", "edit_item" => "Редактировать статью", "new_item" => "Новая статья", "view_item" => "Просмотреть статью", "search_items" => "Поиск статей", "not_found" => "Статей не найдено.", "not_found_in_trash" => "Статей в корзине не найдено.", "parent_item_colon" => "", "all_items" => "Все статьи", "archives" => "Архивы статей", "insert_into_item" => "Вставить в статью", "uploaded_to_this_item" => "Загруженные для этой статьи", "featured_image" => "Миниатюра статьи", "filter_items_list" => "Фильтровать список статей", "items_list_navigation" => "Навигация по списку статей", "items_list" => "Список статей", "menu_name" => "Статьи", "name_admin_bar" => "Статью", // пункте "добавить"); return (object) array_merge((array) $labels, $new); }

Очень дешевые, но качественные подписчики в Инстаграме доступны по адресу 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.

Код register post type : wp-includes/post.php WP 5.2.3

20) { _doing_it_wrong(__FUNCTION__, __("Post type names must be between 1 and 20 characters in length."), "4.2.0"); return new WP_Error("post_type_length_invalid", __("Post type names must be between 1 and 20 characters in length.")); } $post_type_object = new WP_Post_Type($post_type, $args); $post_type_object->add_supports(); $post_type_object->add_rewrite_rules(); $post_type_object->register_meta_boxes(); $wp_post_types[ $post_type ] = $post_type_object; $post_type_object->add_hooks(); $post_type_object->register_taxonomies(); /** * Fires after a post type is registered. * * @since 3.3.0 * @since 4.6.0 Converted the `$post_type` parameter to accept a `WP_Post_Type` object. * * @param string $post_type Post type. * @param WP_Post_Type $post_type_object Arguments used to register the post type. */ do_action("registered_post_type", $post_type, $post_type_object); return $post_type_object; }

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

Немного истории

На практике, пользовательские типы записей появились достаточно давно, а точнее с 17 февраля 2005 года, когда в WordPress 1.5 была добавлена ​​поддержка пользовательских типов для статических страниц, посредством post_type поля в базе данных. Функция Wp_insert_post() была примерно с WordPress 1.0 так что, когда поле post_type было реализовано в 1.5, можно было достаточно просто заполнить его с помощью этой функции.

И только в версии 2.8 появилась функция register_post_type() для создания пользовательских типов и некоторые другие полезные вещи были доступны в «ночных сборках», а уже с 2.9 функции стали доступны всем.

А что сейчас?!

Пользовательский тип записи это не более чем обычная запись (статья) с определенным значением поля post_type в базе данных. В обычной записи поле post_type имеет значение post , страница имеет значение page и так далее. Однако теперь мы можем создавать свои собственные типы, чтобы указать особенности контента, содержащегося в записи. Можно создать пользовательские типы записей для книг, фильмов, анекдотов, продуктов и всего чего угодно.
Если все сделано правильно, то с помощью всего лишь нескольких строк кода можно достичь следующих результатов:

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

Различные типы контента предъявляют различные требования к данным. Для обычных записей вы хотите, чтобы был указан автор, категория и дата. В то время как для записи с типом «книги», хотелось бы иметь возможность указать автора книги, количество страниц, жанр, издательство и другие конкретные данные. Этого легко добиться используя пользовательские (meta boxes) области для ввода данных.

— области для ввода дополнительных данных прямо на странице создания записи. Такие области упрощают работу с пользовательскими типами записей.


Работа с пользовательскими типами записей

Чтобы эффективно создавать и использовать пользовательские типы записей, Вы должны быть знакомы со следующими составляющими:

  • Создание пользовательских типов записей;
  • Создание пользовательской таксономии;
  • Создание пользовательских областей данных.

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

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

1
2
3
4
5


$args = array () ;
}

Это простейшая форма создания типа, который практически не имеет настроек. Для разработки нового типа наших записей, будем использовать некоторые из наиболее часто используемых опций и добавим их к ранее пустому массиву $args .

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

function my_custom_post_product() {
$labels = array (
"name" => _x( "Продукция" , "post type general name" ) ,
"singular_name" => _x( "Продукт" , "post type singular name" ) ,
"add_new" => _x( "Добавить новый" , "product" ) ,
"add_new_item" => __( "Добавить новый продукт" ) ,
"edit_item" => __( "Редактировать продукт" ) ,
"new_item" => __( "Новый продукт" ) ,
"all_items" => __( "Вся продукция" ) ,
"view_item" => __( "Смотреть продукт" ) ,
"search_items" => __( "Найти продукт" ) ,
"not_found" => __( "Продукты не найдены" ) ,
"not_found_in_trash" => __( "Нет удаленной продукции" ) ,
"parent_item_colon" => "" ,
"menu_name" => "Продукция"
) ;
$args = array (
"labels" => $labels ,
"description" => "Пользовательский тип записей продукции" ,
"public" => true ,
"menu_position" => 5 ,
"supports" => array ( "title" , "editor" , "thumbnail" , "excerpt" , "comments" , "product_category" ) ,
"has_archive" => true ,
) ;
register_post_type( "product" , $args ) ;
}
add_action( "init" , "my_custom_post_product" ) ;

  • labels — данный массив меток используется для описания создаваемого пользовательского типа записи в теме./li>
  • description — краткая информация создаваемого пользовательского типа записи, что он делает и почему мы его используем.
  • public — использовать ли пользовательский тип публично и показывать ли его в административной зоне. В данном случае установлено истина.
  • menu_position — позиция пункта меню нашего типа на основной панели администратора. Значение 5 значит пункт установиться сразу после пункта меню «Записи», если 10 значит после пункта «Медиафайлы» и тд.
  • supports — данная опция содержит массив, в котором описаны те поля которые мы можем редактировать на странице создания записи. То есть title — появится поле для ввода названия записи, editor — будет отображена текстовая область для ввода текста записи и тд. А также указана используемая пользовательская таксономия product_category .
  • has_archive — если установлено true, будет создано правило rewrite, позволяя получить список записей нашего типа по адресу http://mysite.com/product/



После установки этого кода в файл function.php , вы должны увидеть меню для пользовательского типа записей. Появилась возможность добавлять запись и просмотреть список записей.

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

Интерактивные оповещения

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

function my_updated_messages( $messages ) {
global $post , $post_ID ;
$messages [ "product" ] = array (
0 => "" ,
1 => sprintf ( __("Продукт обновлен. Посмотреть"
2 => __() ,
3 => __("Пользовательские поля обновлены." ) ,
4 => __("Продукт обновлен." ) ,
5 => isset ($_GET [ "revision" ] ) ? sprintf ( __("Product restored to revision from %s" ) , wp_post_revision_title( (int) $_GET [ "revision" ] , false ) ) : false ,
6 => sprintf ( __("Продукт опубликован. Посмотреть" ) , esc_url( get_permalink($post_ID ) ) ) ,
7 => __("Продукт сохранен." ) ,
8 => sprintf ( __("Продукт отправлен. Посмотреть"
9 => sprintf ( __("Продукт запланирован на: %1$s. Посмотреть" ) , date_i18n( __( "M j, Y @ G:i" ) , strtotime ( $post -> post_date ) ) , esc_url( get_permalink($post_ID ) ) ) ,
10 => sprintf ( __("Product draft updated. Посмотреть" ) , esc_url( add_query_arg( "preview" , "true" , get_permalink($post_ID ) ) ) ) ,
) ;
return $messages ;
}
add_filter( "post_updated_messages" , "my_updated_messages" ) ;

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


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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

function my_contextual_help( $contextual_help , $screen_id , $screen ) {
if ( "edit-product" == $screen -> id ) {

$contextual_help = "

Продукция


На этой странице находится список всей продукции, которая продается на сайте. Записи расположены в обратном хронологическом порядке, последними в списке являются товары, которые мы добавили первыми.


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

" ;

} elseif ( "product" == $screen -> id ) {

$contextual_help = "

Создание/редактирование продукта


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

" ;

}
return $contextual_help ;
}
add_action( "contextual_help" , "my_contextual_help" , 10 , 3 ) ;

Для того чтобы показать такую подсказку нам необходимо знать идентификатор экрана. Если при создании понадобится узнать ID экрана просто делаем так:

echo $screen -> id ;



Пользовательская таксономия

На обычного блога для создания организационной структуры вполне хватает категорий и тегов. В то время как для пользовательских типов постов этого не всегда достаточно. Такую проблему может решить пользовательская таксономия. В нашем случае таксономия с названием «Категории продуктов», которая используется только для записей с пользовательским типов «Продукция».

Процесс создания пользовательской таксономии практически идентичен созданию пользовательских типов записей. Давайте посмотрим на нашем примере:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

function my_taxonomies_product() {
$labels = array (
"name" => _x( "Категории продуктов" , "taxonomy general name" ) ,
"singular_name" => _x( "Категория продуктов" , "taxonomy singular name" ) ,
"search_items" => __( "Найти категорию продуктов" ) ,
"all_items" => __( "Все категории продуктов" ) ,
"parent_item" => __( "Родительская категория продуктов" ) ,
"parent_item_colon" => __( "Родительская категория продуктов:" ) ,
"edit_item" => __( "Редактировать категорию продуктов" ) ,
"update_item" => __( "Обновить категорию продуктов" ) ,
"add_new_item" => __( "Добавить новую категорию продуктов" ) ,
"new_item_name" => __( "Новая категория продуктов" ) ,
"menu_name" => __( "Категории продуктов" ) ,
) ;
$args = array (
"labels" => $labels ,
"hierarchical" => true ,
) ;
register_taxonomy( "product_category" , "product" , $args ) ;
}
add_action( "init" , "my_taxonomies_product" , 0 ) ;

Как и при создании пользовательского типа мы сформировали массив label, и указали что для создаваемой таксономии актуальна иерархическую структуру (т.е. могут быть родительский и дочерний элементы) — это свойственно рубрикам в обычных записях. В противном случае если структура не иерархическая — созданы обычные теги. Более подробно о таксономии Вы можете почитать .


Дополнительные области данных

Дополнительные области или блоки для ввода данных (meta boxes) вы могли видеть на странице редактирования записи. Все знают стандартные , такие как выбор рубрики или тегов. Также в некоторых темах встречаются позволяющие прикрепить картинку к записи и тд.

Так как мы создаем пользовательский тип «Продукция», то нам явно понадобится цена продукта, давайте рассмотрим процесс создания пользовательских .

Процесс создания можно разделить на 3 этапа:

  • Определение самого блока;
  • Определение содержимого (какие поля присутствуют в блоке);
  • Описание алгоритмов обработки введенных данных.

Определение meta boxes

1
2
3
4
5
6
7
8
9
10
11

add_action( "add_meta_boxes" , "product_price_box" ) ;
function product_price_box() {
add_meta_box(
"product_price_box" ,
__( "Цена продукта" , "myplugin_textdomain" ) ,
"product_price_box_content" ,
"product" ,
"side" ,
"high"
) ;
}

Приведенный выше код создает блок со следующими параметрами:

  • product_price_box — уникальный идентификатор для meta box (он не обязательно должен совпадать с названием функции);
  • Цена продукта — название meta box, которое видит админ на странице;
  • product_price_box_content — функция, которая будет отображать содержимое окна;
  • product — название пользовательского типа записи, к которому принадлежит meta boxes;
  • side — положение блока на странице (side , normal или advanced — по-умолчанию);
  • high — приоритет meta boxes (в данном случае «высокий», блок находится в самом верху сайдбара. Варианты: high , core , low или default — по-умолчанию).

Определение содержимого

1
2
3
4
5

function product_price_box_content( $post ) {
wp_nonce_field( plugin_basename( __FILE__ ) , ) ;
echo "" ;
echo "" ;
}

Добавляем всего лишь одно поле, для ввода цены продукта. Заметьте название функции совпадает со значением третьего параметра при объявлении (код выше).

Обработка введенных данных

Последний шаг — это сохранение введенной цены на продукт в базу данных.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

add_action( "save_post" , "product_price_box_save" ) ;
function product_price_box_save( $post_id ) {

if ( defined ( "DOING_AUTOSAVE" ) && DOING_AUTOSAVE )
return ;

if ( ! wp_verify_nonce( $_POST [ "product_price_box_content_nonce" ] , plugin_basename( __FILE__ ) ) )
return ;

if ( "page" == $_POST [ "post_type" ] ) {
if ( ! current_user_can( "edit_page" , $post_id ) )
return ;
} else {
if ( ! current_user_can( "edit_post" , $post_id ) )
return ;
}
$product_price = $_POST [ "product_price" ] ;
update_post_meta( $post_id , "product_price" , $product_price ) ;
}

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

Отображение записей созданного типа на блоге

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

Так как в процессе создании пользовательского типа мы указали истину для параметра has_archive то список записей типа product доступны по адресу http://mysite.com/product/ .

Для отображения используется файл archive-.php (в нашем случае archive-product.php) если такой существует. Иначе, для отображения будет использован archive.php и если такой файл отсутствует в теме, то будет использовать )
) ;
$products = new WP_Query( $args ) ;
if ( $products -> have_posts () ) {
while ( $products -> have_posts () ) {
$products -> the_post () ;
?>
< h1>
< div class = "content" >


}
}
else {
echo "О нет, продукты не обнаружены!" ;
}
?>

Отображение цены

Введенные дополнительные данные, в нашем случае цена продукта, могут быть получены с помощью функции get_post_meta () . Так как мы используем дополнительно поле product_price , то чтобы получить значение цены:

Плагин для создания пользовательских типов записей

Если Вы не уверены в своих силах в области программирования, то всегда можно найти уже готовое решение (плагин) и воспользоваться им. Пользовательские типы не исключение. Плагин WCK Custom Post Type Creator позволяет вам легко создавать пользовательские типы записей для WordPress без знания программирования.

    Аплодировать, хлопать, бить в ладони (ладоши). Стоит оратору эффектно закончить хотя бы самую бессодержательную речь, и зал дрожит от рукоплесканий. Браво! Браво! закричали все... и даже в ладоши забили. Тург. Ср. аплодировать... Словарь русских … Словарь синонимов

    - (иноск.) одобрять, радоваться (выражая это рукоплесканіемъ хлопаніемъ въ ладони). Ср. Эта выдумка очень понравилась всѣмъ дамамъ: онѣ дружно захлопали въ ладоши. Писемскій. Масоны. 5, 4. Ср. Восплесните руками всѣ народы, воскликните Богу гласомъ … Большой толково-фразеологический словарь Михельсона (оригинальная орфография)

    РУКОПЛЕСКАТЬ, рукоплещу, рукоплещешь, несовер., кому чему (книжн.). Ударять, плескать в ладоши в знак одобрения, аплодировать. Весь зал рукоплескал оратору. «Свет ей рукоплещет, свет ей подражает.» Некрасов. Толковый словарь Ушакова. Д.Н. Ушаков … Толковый словарь Ушакова

    рукоплескать - рукоплескать, рукоплещу, рукоплещет (не рекомендуется рукоплескаю, рукоплескает); прич. рукоплещущий; дееприч. рукоплеща (неправильно рукоплеща) … Словарь трудностей произношения и ударения в современном русском языке

    - (иноск.) одобрять, радоваться (выражая это рукоплесканием хлопанием в ладони) Ср. Эта выдумка очень понравилась всем дамам: они дружно захлопали в ладоши. Писемский. Масоны. 5, 4. Ср. Восплесните руками все народы, воскликните Богу гласом радости … Большой толково-фразеологический словарь Михельсона

    Несов. неперех. устар. 1. Ударять, хлопать в ладоши в знак одобрения, горячего признания чего либо; аплодировать. 2. перен. Воздавать похвалы кому либо, горячо одобрять кого либо или что либо. Толковый словарь Ефремовой. Т. Ф. Ефремова. 2000 … Современный толковый словарь русского языка Ефремовой

    Рукоплескать, рукоплещу, рукоплещем, рукоплещешь, рукоплещете, рукоплещет, рукоплещут, рукоплеща, рукоплескал, рукоплескала, рукоплескало, рукоплескали, рукоплещи, рукоплещите, рукоплещущий, рукоплещущая, рукоплещущее, рукоплещущие, рукоплещущего … Формы слов

    рукоплескать - рукоплеск ать, ещ у, ещет … Русский орфографический словарь

    рукоплескать - (I), рукоплещу/, пле/щешь, щут … Орфографический словарь русского языка

    Плещу, плещешь; нсв. кому чему и без дополн. = Аплодировать. Р. победителям Олимпийских игр. Р. при появлении режиссёра и киноактёров … Энциклопедический словарь

Книги

  • Герои олимпийских игр , В. Л. Штейнбах. В 2008 году Россия отмечает столетие выступления наших спортсменов на Олимпиадах. Это не просто спортивные состязания, Олимпийские игры являются гимном мужеству, стойкости, силе воли и…
  • Из писем П. А. Вяземского , Петр Вяземский. «Иван Иванович ‹Дмитриев› написал несколько превосходных басен. Скипетр – в руках законного царя: горе и стыд самозванцам! Разумеется, здесь дело идет не о Крылове: он счастливый смельчак,…

Читайте также: