Непорочный post type. Как добавлять категории в пользовательские типы постов в WordPress. Создание пользовательских типов записей

О произвольных типах записей в Вордпрессе (CPT, Custom Post Types in WordPress), как создать и настроить, добавить категории и теги, как сделать вложенные URL /тип записи/рубрика/запись или http://example.com/post_type/category/post/ .
Тут также описывается, как расширить стандартный функционал WordPress, создав новые типы записей, которые можно использовать в различных целях: добавить собственное порфтолио, картотеку фильмов и музыки, каталог продукции, календарь событий, даже сделать свой небольшой интернет-магазин (потому что для большого лучше пользоваться готовыми решениями навроде WooCommerce) или социальную сеть, и много чего ещё в этом духе.
Вначале общая информация, дальше — частности.

О записях в WordPress: где хранятся в базе данных, и как их получить

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

Приведу пример, как получить 10 записей типа post (стандартные Записи в панели администратора).
В общих чертах, данные особо запрашивать не надо. В шаблонах они уже предустановлены, например, в single.php данные по записи уже доступны для обработки в цикле

If (have_posts()) { while (have_posts()) { the_post(); // Тут используем данные из цикла, такие как the_title() и т.п. } }

Если данные нужно получить где-то вне цикла или шаблона, используется запрос WP_Query

$args = array("post_type" => "post", // Тип поста: page, attachment, ... "posts_per_page" => 10, // 10 записей за раз); $p = get_posts($args); // Данные можно раскрыть в цикле if (!empty($p)) { foreach ($p as $post) { setup_postdata($post); ?> ">

Данные можно получить посредством SQL запроса:

Global $wpdb; $query = "SELECT * FROM {$wpdb -> posts} WHERE post_type = "post" LIMIT 10"; $p = $wpdb -> get_results($query); exit(print_r($p)); // в $p теперь массив с данными о постах

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

Предустановленные типы записей в WordPress: post, page, attachment, revision, nav_menu_item

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

Самая используемая единица из всех типов, что есть в WordPress — Записи (они же посты, post). Используется в роли постов блога и тому подобного. Имеет 2 предустановленных таксономии: рубрики, они же категории (category) и метки, они же теги (post_tag).
Таксономии служат для сортировки и упорядочивания записей.
Рубрики отличаются от меток тем, что имеют древовидную структуру (могут быть вложенными друг в друга).
Метки являются независимыми друг от друга единицами и этим чем-то похожи на Записи.
Также, по умолчанию, из записей формируется RSS лента сайта на Вордпрессе.

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

  1. single-post.php
  2. single.php
  3. singular.php
  4. index.php

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

Страницы (page)

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

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

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

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

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

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

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

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

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

$args = array("post_type" => "attachment", // Тип поста: attachment "post_status" => "inherit", // По умолчанию "publish", а с ним вложения не получить, поэтому указываем специальный статус вложения "inherit"); $p = get_posts($args); exit(print_r($p)); // На выходе будем иметь массив с вложениями

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

  1. {mime-тип}.php
  2. {mime-подтип}.php
  3. {mime-тип-подтип}.php
  4. attachment.php
  5. single.php
  6. singular.php
  7. index.php

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

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

  1. Использовать фильтр wp_revisions_to_keep
  2. Прописать в wp-config.php //Отключаем ревизии до минимально возможного значения define("WP_POST_REVISIONS", 0);

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

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

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

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

  1. Прописать add_theme_support("menus");
  2. Или зарегистрировать место под меню с помощью register_nav_menu() , тогда поддержка меню включится автоматически

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

// Этот код сработает wp_nav_menu(); // Выведет первое зарегистрированное непустое меню // А код ниже работать не будет $args = array("post_type" => "nav_menu_item", // Тип поста: page, attachment, ...); $p = get_posts($args); exit(print_r($p)); // На выходе будем иметь пустой массив

Пользовательский Произвольный тип записи (Custom Post Type, CPT WordPress)

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

Add_action("init", "sheensay_post_type"); function sheensay_post_type() { register_post_type("sheensay_product", array("labels" => array("name" => "Продукция", "singular_name" => "Продукцию",), "public" => true, // тип записи открыт для поиска и тому подобного "has_archive" => true, // Включаем страницы архивов "supports" => array("title", "editor", "thumbnail", "comments"), // Включаем поддержку заголовка, редактора, миниатюры, комментариев)); }

Здесь sheensay_product — это название нового типа записей. Оно не должно конфликтовать с другими в системе, об этом подробнее ниже.
Также, в этом варианте оно служит ярлыком этого типа записей, то есть присутствует в URL. Если же хотите указать другой ярлык, например продукция , делайте как на примере ниже

Add_action("init", "sheensay_post_type"); function sheensay_post_type() { register_post_type("sheensay_product", array("labels" => array("name" => "Продукция", "singular_name" => "Продукцию",), "public" => true, "rewrite" => array("slug" => "продукция"), // Тут определяется ярлык Custom Post Type "has_archive" => true, "supports" => array("title", "editor", "thumbnail"),)); }

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

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

  • attachment
  • revision
  • nav_menu_item
  • action
  • theme
  • order

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

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

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

Add_action("init", "sheensay_post_type"); function sheensay_post_type() { // Регистрируем таксономию register_taxonomy("sheensay_product_type", "sheensay_product", array("label" => "Типы", "hierarchical" => true, // Если TRUE, таксономия будет аналогом рубрик (категорий). Если FALSE (по умолчанию), то таксономия станет аналогом меток (тегов). "rewrite" => array("slug" => "тип-продукции"),)); // Регистрируем произвольный тип записи (Custom Post Type) register_post_type("sheensay_product", array("labels" => array("name" => "Продукция", "singular_name" => "Продукцию",), "public" => true, "rewrite" => array("slug" => "продукция"), // Тут определяется ярлык CPT "has_archive" => true, "supports" => array("title", "editor", "thumbnail"), // Включаем поддержку заголовка, редактора, миниатюры)); }

Шаблоны для произвольных типов постов

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

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

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

  1. single-{тип_поста}.php
  2. single.php
  3. index.php

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

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

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

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

Здесь имя_таксономии — это sheensay_product_type , а имя_термина — это ярлык той таксономии, что вы создадите в админке.

Как получить данные произвольного типа записей (Custom Post Type WordPress) и отобразить на сайте

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

$args = array("post_type" => "sheensay_product", // Указываем наш новый тип записи "posts_per_page" => 10,); $p = get_posts($args); foreach ($p as $post) { setup_postdata($post); ?> ">

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

// Подключаем к стандартным "post" и "page" наш "sheensay_product" 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", "sheensay_product")); return $query; }

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

Ниже представлен класс, с помощью которого вы сможете зарегистрировать любой произвольный тип записей с собственной таксономией, а URL будет иметь вид
http://example.com/продукция/тип/продукт

Чтобы URL формировался, вы должны перейти в настройки постоянных ссылок /wp-admin/options-permalink.php и установить любой отличный от простого вид общих настроек

Ниже сам код класса. Вы можете не вносить в него никаких изменений, а поменять ярлык типа записи можно в самом конце в строке new Sheensay_Product("продукция");
Сам код пишется в или в . Первый вариант предпочтительнее, так как в этом случае, вы не потеряете доступа к контенту нового типа записей при смене активной темы.

post_type = $post_type; /* * Регистрируем Custom Post Type */ add_action("init", array($this, "sheensay_cpt_product")); /* * Фильтруем URL */ add_filter("post_type_link", array($this, "product_permalink_structure"), 10, 2); /* * Чтобы работала пагинация */ add_action("generate_rewrite_rules", array($this, "fix_product_category_pagination")); } function sheensay_cpt_product() { /* * Регистрируем произвольную таксономию к новому типу записей */ register_taxonomy("sheensay_product_type", "sheensay_product", array("label" => "Типы", "hierarchical" => true, "query_var" => true, "rewrite" => array("slug" => $this -> post_type),)); /* * Регистрируем новый тип записи */ $labels = array("name" => "Продукция", // Основное название "singular_name" => "Продукцию", // Добавить "add_new" => "Добавить новую", // Имя ссылки на новую запись в сайдбаре "add_new_item" => "Добавить новую продукцию", // Заголовок в редакторе при добавлении новой записи); $args = array("labels" => $labels, "public" => true, "publicly_queryable" => true, "show_ui" => true, "query_var" => true, "capability_type" => "post", "hierarchical" => false, "menu_position" => null, "supports" => array("title", "editor", "thumbnail", "excerpt"), "rewrite" => array("slug" => $this -> post_type . "/%sheensay_product_type%", "with_front" => false,), "has_archive" => $this -> post_type,); register_post_type("sheensay_product", $args); if (current_user_can("manage_options")) // Вот с этой функцией осторожней. Она сбрасывает все правила определения URL. Лучше её закомментировать после завершения всех работ flush_rewrite_rules(); } function product_permalink_structure($post_link, $post) { if (FALSE !== strpos($post_link, "%sheensay_product_type%")) { $product_type_term = get_the_terms($post -> ID, "sheensay_product_type"); if (!empty($product_type_term)) $post_link = str_replace("%sheensay_product_type%", $product_type_term -> slug, $post_link); } return $post_link; } function fix_product_category_pagination($wp_rewrite) { unset($wp_rewrite -> rules[ $this -> post_type . "/([^/]+)/page/?({1,})/?$"]); $wp_rewrite -> rules = array($this -> post_type . "/?$" => $wp_rewrite -> index . "?post_type=sheensay_product", $this -> post_type . "/page/?({1,})/?$" => $wp_rewrite -> index . "?post_type=sheensay_product&paged=" . $wp_rewrite -> preg_index(1), $this -> post_type. "/([^/]+)/page/?({1,})/?$" => $wp_rewrite -> index . "?sheensay_product_type=" . $wp_rewrite -> preg_index(1) . "&paged=" . $wp_rewrite -> preg_index(2),) + $wp_rewrite -> rules; } } /* * Запускаем класс * В скобках можно определить название ярлыка типа записи */ new Sheensay_Product("продукция");

Теперь в админке вы можете зарегистрировать новую продукцию и их типы

Build an object with all post type capabilities out of a post type object

Post type capabilities use the "capability_type" argument as a base, if the capability is not set in the "capabilities" argument array or if the "capabilities" argument is not supplied.

The capability_type argument can optionally be registered as an array, with the first value being singular and the second plural, e.g. array("story, "stories") Otherwise, an "s" will be added to the value for the plural form. After registration, capability_type will always be a string of the singular value.

By default, seven keys are accepted as part of the capabilities array:

    edit_post, read_post, and delete_post are meta capabilities, which are then generally mapped to corresponding primitive capabilities depending on the context, which would be the post being edited/read/deleted and the user or role being checked. Thus these capabilities would generally not be granted directly to users or roles.

  • edit_posts - Controls whether objects of this post type can be edited.
  • edit_others_posts - Controls whether objects of this type owned by other users can be edited. If the post type does not support an author, then this will behave like edit_posts.
  • publish_posts - Controls publishing objects of this post type.
  • read_private_posts - Controls whether private objects can be read.

These four primitive capabilities are checked in core in various locations. There are also seven other primitive capabilities which are not referenced directly in core, except in map_meta_cap(), which takes the three aforementioned meta capabilities and translates them into one or more primitive capabilities that must then be checked against the user or role, depending on the context.

  • read - Controls whether objects of this post type can be read.
  • delete_posts - Controls whether objects of this post type can be deleted.
  • delete_private_posts - Controls whether private objects can be deleted.
  • delete_published_posts - Controls whether published objects can be deleted.
  • delete_others_posts - Controls whether objects owned by other users can be can be deleted. If the post type does not support an author, then this will behave like delete_posts.
  • edit_private_posts - Controls whether private objects can be edited.
  • edit_published_posts - Controls whether published objects can be edited.

These additional capabilities are only used in map_meta_cap(). Thus, they are only assigned by default if the post type is registered with the "map_meta_cap" argument set to true (default is false).

Хуков нет.

Возвращает

Объект. Object with all the capabilities as member variables.

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

get_post_type_capabilities($args); $args(объект) (обязательный) Post type registration arguments.

Заметки

  • Смотрите: register_post_type()
  • Смотрите: map_meta_cap()

Список изменений

С версии 3.0.0 Введена.

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

capability_type)) { $args->capability_type = array($args->capability_type, $args->capability_type . "s"); } // Singular base for meta capabilities, plural base for primitive capabilities. list($singular_base, $plural_base) = $args->capability_type; $default_capabilities = array(// Meta capabilities "edit_post" => "edit_" . $singular_base, "read_post" => "read_" . $singular_base, "delete_post" => "delete_" . $singular_base, // Primitive capabilities used outside of map_meta_cap(): "edit_posts" => "edit_" . $plural_base, "edit_others_posts" => "edit_others_" . $plural_base, "publish_posts" => "publish_" . $plural_base, "read_private_posts" => "read_private_" . $plural_base,); // Primitive capabilities used within map_meta_cap(): if ($args->map_meta_cap) { $default_capabilities_for_mapping = array("read" => "read", "delete_posts" => "delete_" . $plural_base, "delete_private_posts" => "delete_private_" . $plural_base, "delete_published_posts" => "delete_published_" . $plural_base, "delete_others_posts" => "delete_others_" . $plural_base, "edit_private_posts" => "edit_private_" . $plural_base, "edit_published_posts" => "edit_published_" . $plural_base,); $default_capabilities = array_merge($default_capabilities, $default_capabilities_for_mapping); } $capabilities = array_merge($default_capabilities, $args->capabilities); // Post creation capability simply maps to edit_posts by default: if (! isset($capabilities["create_posts"])) { $capabilities["create_posts"] = $capabilities["edit_posts"]; } // Remember meta capabilities for future reference. if ($args->map_meta_cap) { _post_type_meta_capabilities($capabilities); } return (object) $capabilities; }

Начиная с версии 2.9 WordPress предоставил возможность использования произвольных типов записей. Теперь же с версии 3.0 всё стало еще приятнее с опцией создания панелей для ваших произвольных типов записей. В этой статье мы покажем вам как внедрить Произвольные Типы записей на ваш сайт на WordPress.

Создание произвольных типов записей — используем Плагин

На сегодняшний день в версии 3.0 WordPress нет встроенного интерфейса для создания произвольных типов записей. Есть только два способа, доступных для создания произвольных типов записей: плагины или хард-кодинг темы в файле functions.php . Сначала давайте рассмотрим реализацию задуманного с использованием плагинов.

Custom Post Type UI

Custom Post Type UI — это плагин, разработанный Brad Williams, который позволяет вам с легкостью создавать произвольные типы записей и таксономии. Одной из самых примечательных возможностей этого плагина является то, что он генерирует код для создания произвольных типов записей, которые в последующем можно вставить в файл functions.php темы, а из минусов то, что невозможно использовать таксономии для всех ваших типов записей.

В панели Custom Post Type UI кликните на “Add New”.

  • “Post Type Name” — это то, что будет использоваться WordPress для запросов на все записи из этого post_type.
  • “Label” — то, что будет отображаться в сайдбаре вашей Консоли, по типу стандартного меню «Записи».
  • Если раскрыть “View Advanced Options”, то можно увидеть несколько дополнительных настроек. Большинство из них интуитивно понятны, например “Public” и “Show UI”. Первая при переключении ее в True позволит вывести меню произвольного типа записи в сайдбар, а вторая (Show UI) при значении True создает панель меню.
  • “Rewrite” — то, что позволит произвольным типам записей использовать SEO Friendly WordPress URL (постоянные ссылки, ЧПУ).
  • В “Custom Rewrite Slug” вы указываете все, что вам угодно. WordPress будет использовать указанный slug для генерации постоянных ссылок. Поэтому если у нас есть домен example.com и slug — “movies”, то ваша ссылка на произвольный тип записи будет выглядеть примерно так example.com/movies .
  • Функция WordPress “Query Var” позволяет вам выполнять запросы к вашим новым типам записей. Если мы возьмем пример, приведенный выше, то чтобы получить доступ к записи с заголовком, My First Movie Post , который находится в post_type Movies , мы можем ввести example.com/?movies=my-first-movie-post . Посему переменная запроса выглядит так: ?posttypename

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

Создание произвольных типов записей — используем файл Functions.php

Если вы предпочтете создавать произвольные типы записей без плагинов, то просто добавьте следующий код в файл functions.php вашей темы:

// Создаем тип записей Movies register_post_type("movies", array("label" => "Movies", "public" => true, "show_ui" => true, "capability_type" => "post", "hierarchical" => false, "rewrite" => array("slug" => "movies"), "query_var" => true, "supports" => array("title", "editor", "excerpt", "trackbacks", "custom-fields", "comments", "revisions", "thumbnail", "author", "page-attributes",)));

Давайте проанализируем код.

register_post_type($post_type, $args): Эта функция принимает два параметра, $post_type или название типа записи, и $args, массив параметров.

label: Имя, задаваемое типу записи, которое будет отображаться в сайдбаре административной панели сайта.

show_ui : true/false. Отображает или скрывает дефолтный интерфейс для управления этим типом записей.

capability_type: По-умолчанию: post. Тип записи для проверки возможностей чтения, редактирования и удаления.

hierarchical: Является ли запись иерархической.

rewrite: true/false. По-умолчанию: true . Если параметр slug указан, то имя slug добавляется перед записью.

query_var: true/false Устанавливает переменную для запроса к произвольному типу записи.

supports: По-умолчанию: title и author . Устанавливает различные фичи, которые будут поддерживаться типом записи.

Посетите WordPress Codex для более подробной информации по register_post_type() .

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

Для вывода записей из вашего произвольного типа необходимо добавить следующий код в цикл. Измените “name” на имя вашего типа записей. Примечание: вам не нужно добавлять ваши произвольные типы записей в ваш файл index.php. Можно создать и там выполнить следующий запрос внутри цикла.

$query = new WP_Query("post_type=name");

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

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 без знания программирования.

Доброго времени суток, дорогие хабравчане, я уже много лет делаю сайты на wordpress и решил поделится своим опытом. Мне сильно порадовала новость ранее опубликованная aleksandrit , о том что "WordPress используется уже на более чем 50 миллионах сайтов ", это новость вдохновляет все больше изучать глубокие и скрытые возможности Wordpress. Ранее подобная тема уже была опубликована bRuz ом но я бы хотел подойти к вопросу иначе, шаг за шагом.

И так начнем с очевидного.

Зачем нужны custum post type

Главная цель custum post type позволить разработчику организовать данные на сайте. например: если речь идет о блоге, то у нас есть несколько типов данных(записи, медиафайлы, страницы и ссылки). Но что делать тем у кого сайт посвящен? новинкам кино индустрии? подобному сайту понадобится такой тип записей как «Обзор», у обзора должны быть такие характеристики как: жанр, год выпуска, обложка, актеры и т.д… Использования custum post type в отличие от обычных записей, дает нам возможность использовать эти данные в шаблоне, а так же искать по определенным параметрам и сортировать.

Начнем создавать

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

Function create_post_type() { // создаем новый тип записи

array(
"labels" => array(
"name" => __("Обзоры"), // даем названия разделу, для панели управления
"singular_name" => __("Обзор") // даем названия одной записи
),
"public" => true,
"menu_position" =>
"rewrite" => array("slug" => "reviews") // указываем slug для ссылок например: http://mysite/reviews/
);
}

И так что получилось,
Обратите внимания на то что в левой панели появилась вкладка обзоры.

Как мы видим на этой картинке у нас появились пару проблем. заголовок все еще остался таким «Добавить запись» и нету возможности добавить обложку. Попробуем это исправить, для этого нам понадобится добавить пару параметров (полный список параметров ищите в кодексе).
function create_post_type() { // создаем новый тип записи
register_post_type("reviews", // указываем названия типа
array(
"labels" => array(
"name" => __("Обзоры"), // даем названия разделу для панели управления
"singular_name" => __("Обзор"), // даем названия одной записи
"add_new" => _x("Добавить новый"),// далее полная русификация админ. панели
"add_new_item" => __("Добавить новый обзор"),
"edit_item" => __("Редактировать обзор"),
"new_item" => __("Новый обзор"),
"all_items" => __("Все обзоры"),
"view_item" => __("Просмотр обзора"),
"search_items" => __("Поиск обзора"),
"not_found" => __("Нет обзоров"),
"not_found_in_trash" => __("обзоры не найдены"),
"menu_name" => "Обзоры"

),
"public" => true,
"menu_position" => 5, // указываем место в левой баковой панели
"rewrite" => array("slug" => "reviews"), // указываем slug для ссылок например: http://mysite/reviews/
"supports" => array("title", "editor", "thumbnail", "revisions") // тут мы активируем поддержку миниатюр
);
}

Add_action("init", "create_post_type"); // инициируем добавления типа

Результат:

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

Loop

Если честно, мне приходят в голову два способа отображения нового типа записи. и так примеры:
Первый способ: использовать шаблонный файл, допустим тип новой записи называется "reviews", в этом слачае мы создаем файл под названием archive-reviews.php для отображения множество записей и single-reviews.php для отображения одной записи (оффтоп. приятный пример иерархии всех шаблонов прекрасно отображён на данной инфограме) далее мы используем простой код итерации по записям:
стандартная итерация по массиву
the_title();// заголовок

echo "";
the_content();// запись
echo "";
endwhile;

Второй способ: вызов лупа из любой части шаблона,
$args = array("post_type" => "reviews", "posts_per_page" => 10);//тут мы указываем на тип записи по которой желаем пройтись и количество записей на одной странице
$loop = new WP_Query($args);// получаем результат запроса в переменное loop
while ($loop->have_posts()) : $loop->the_post(); // далее стандартная итерация по массиву
the_title();// заголовок
php the_post_thumbnail(array(150,150)); //получаем миниатюру записи
echo "";
the_content();// запись
echo "";
endwhile;

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

В следующий раз я хотел бы раскрыть такую прекрасную функцию как Taxonomies и custom fields

Теги: wordpress, cms, разработка сайтов, wordpress 3.3