Создаем кастомный тип записи (Custom Post Type) с кастомными категориями (Custom Taxonomy). Лучшие WordPress-плагины для работы с произвольными типами записей Как правильно подобрать название нового типа записи

На сегодняшнем уроке мы познакомимся с понятием custom post type , а также научимся создавать свой кастомный post type и шаблон для него. Custom post type это одно из основных направлений в WordPress , с которым работают разработчики.

В WordPress-е блоге посты и страницы - все это post type и чтобы расширить функционал, разработчику нужно добавлять новые post type . Например у вас сайт для продажи книг, вы же не будете публиковать эти книги, как блог-посты. Для этого вы создадите новый post type с названием "book" , у которого будет свой внешний вид, свой шаблон и свои настройки.

Сегодня мы создадим свой post type под названием "book" , который будет иметь кастомный шаблон для публичного поста и для страницы с архивами. Давайте сначала ознакомимся с документацией WordPress - Codex/Post Type . Первым делом в кодексе перечислены все названия в (Default Post Types) , которые мы не можем использовать при регистрации новых названий постов.

Для создания кастомных постов в WordPress существует специальная функция - register_post_type() . Разберем на примере ниже.

Функция register_post_type подключается к ядру WordPress-а при помощи другой функции-хука - add_action . Хук это крючок, за который мы цепляем нашу функцию к ядру WordPress , который при инициализации своих функций, добавляет и нашу.

Давайте попробуем зарегистрировать наш post type , скопируем кусок кода из примера выше и вставим его в файл function.php , стартовой темы underscore , которую мы установили на прошлом уроке и назвали my_theme - "Файлы темы Wordpress" . Сделать это можно через админку WordPress-а в теме, Внешний вид / Редактор , открываете файл function.php и вставляете код из кодекса внизу документа.

Разберем подробнее этот код. WordPress регистрирует post type при помощи функции register_post_type . В круглых скобках передаются параметры, первый параметр acme_product - это id нового типа поста, который мы меняем на свой book .

Register_post_type("book",

За ним идет параметр, который получает эта функция, это массив настроек, в примере их всего три, а в документации гораздо больше. Переименуем "Products" на "books" , а "Product" на "book" .

Array(
"labels" => array(
"name" => __("books"),
"singular_name" => __("book")
),

Public означает, что пост публичный, его видят все и он попадает в архив has_archive .

"public" => true,
"has_archive" => true,
)

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

/**
* My blog custome code.
*/

Сохраняем пост идем в консоль админки и видим новый тип поста book , однако он с минимальным количеством настроек.

На странице codex вы увидите полный список настроек. Нам надо добавить возможность добавления превью-картинки, передадим в массиве параметр "thumbnail" . Кроме того, вернем назад title и editor .

"supports" => array("title", "editor", "thumbnail"),

Точно так же можно добавлять и другие настройки из документации. Рекомендуется для пользовательских названий, в том числе и для post type применять префиксы (my_book) , чтобы избежать конфликта с другими плагинами, ведь названия могут совпасть. Для избежания ошибок WordPress рекомендует все вами разработанные функции, переменные, id , классы и константы прописывать с префиксами.

Кастомный шаблон для нового post type

Создадим два поста в новом типе записей book с названиями Book 1 и Book 2 и откроем сайт по адресу http://my_blog.com/book/.

Мы видим, что загрузился нами созданный post type book , а не дефолтный post type WordPress-а , но загружаются все равно старый archive.php , а нам надо создать свой, вместо дефолтного. Мы хотим, чтобы книги не находились в блог постах, а выглядели иначе, без типичной блоговой структуры. Создадим пустой файл archive-book.php и подключим к нему шапку,

get_header();
?>

get_footer();
?>

и сделаем вывод контента в цикле, скопировав код из раздела документации Post_Types , заменив "product" на "book" .

$args = array("post_type" => "book", "posts_per_page" => 10);
$loop = new WP_Query($args);
while ($loop->have_posts()) : $loop->the_post();
the_title();
echo "

";
the_content();
echo "
";
endwhile;
?>

Аналогичный действия надо сделать и для файла single.php .

Возвращает существующие (зарегистрированные) типы записей. Можно фильтровать вывод по множеству критериев.

✈ 1 раз = 0.000001с = скорость света | 50000 раз = 0.14с = очень быстро | PHP 7.1.11, WP 4.9.8

Хуков нет.

Возвращает

Массив. Список названий типов записей или массив объектов (вывод настраивается в параметре $output).

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

get_post_types($args, $output, $operator); $args(массив) name => page label => Страницы labels => stdClass Object() description => public => 1 hierarchical => 1 exclude_from_search => publicly_queryable => show_ui => 1 show_in_menu => 1 show_in_nav_menus => 1 show_in_admin_bar => 1 menu_position => 20 menu_icon => capability_type => page map_meta_cap => 1 register_meta_box_cb => taxonomies => Array() has_archive => query_var => can_export => 1 delete_with_user => 1 _builtin => 1 _edit_link => post.php?post=%d cap => stdClass Object(edit_post => edit_page read_post => read_page delete_post => delete_page edit_posts => edit_pages edit_others_posts => edit_others_pages publish_posts => publish_pages read_private_posts => read_private_pages read => read delete_posts => delete_pages delete_private_posts => delete_private_pages delete_published_posts => delete_published_pages delete_others_posts => delete_others_pages edit_private_posts => edit_private_pages edit_published_posts => edit_published_pages create_posts => edit_pages) rewrite => show_in_rest => 1 rest_base => pages rest_controller_class => WP_REST_Posts_Controller
  • label
  • singular_label
  • description
  • public - Логический, если true, то выбраны будут только публичные типы записей (см. описание register_post_type()).
  • publicly_queryable
  • exclude_from_search
  • show_ui
  • capability_type
  • edit_cap
  • edit_type_cap
  • edit_others_cap
  • publish_others_cap
  • read_cap
  • delete_cap
  • hierarchical
  • supports
  • register_meta_box_cb
  • taxonomies
  • menu_position
  • menu_icon
  • permalink_epmask
  • rewrite
  • query_var
  • Builtin
    Логический. Если true, то будут возвращены встроенные типы записей WP: page, posts... false - вернет только новые типы записей.

    Типы записей относящиеся к критерию _builtin:

    • mediapage
    • attachment
    • revision
    • nav_menu_item - с версии 3.0
    • custom post type - с версии 3.0
  • _edit_link

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

$output(строка)

Как выводить результат. Возможны 2 варианта:

  • names - будет возвращен массив имен;
  • objects - будет возвращен массив объектов с данными типа записи.
    По умолчанию: "names"
$operator(строка) Оператор сравнения для указанных критериев. Может быть: "and" и "or".
По умолчанию: "and"

Примеры

#1 Выведем на экран список названий всех зарегистрированных типов записей

Выведет зарегистрированные типы записей:

$post_types = get_post_types(); /* $post_types = Array ( => post => page => attachment => revision => nav_menu_item => article => question) */ foreach($post_types as $post_type) { echo $post_type ."\n"; } /* Выведет: post page attachment revision nav_menu_item article func */

#2 Выведем на экран список типов записей имеющих страницу во форонте

$post_types = get_post_types([ "publicly_queryable"=>1 ]); $post_types["page"] = "page"; // встроенный тип не имеет publicly_queryable unset($post_types["attachment"]); // удалим attachment /* Array => post => custom_type1 => custom_type2 => custom_type3 => page */

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

$args = array("public" => true, "_builtin" => false); $output = "names"; // names or objects, note names is the default $operator = "and"; // "and" or "or" $post_types = get_post_types($args, $output, $operator); foreach ($post_types as $post_type) { echo "

". $post_type. "

"; }

#4. Пример, получение типа записи по названию

Здесь используется вывод в виде объекта данных (object). Выводим тип записи с названием property:

$post_types = get_post_types([ "name"=>"property" ], "objects"); foreach ($post_types as $post_type) { echo "

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

Способ с плагином

Для начинающих пользователей мы рекомендуем использовать Custom Post Type UI плагин, чтобы создать пользовательский тип постов. Используя этот плагин, у вас есть возможность ассоциировать пользовательский тип постов с любой встроенной или пользовательской таксономией, включая категории. После установки плагина зайдите в CPT UI » Add/Edit Post Types для того, чтобы создать новый пользовательский тип постов или отредактировать существующий.

Прокрутите вниз до Advanced Options и там вы увидите параметр Built in Taxnomies. Отметьте ячейку напротив категорий и сохраните свой тип постов.

Ручное добавление категорий для пользовательского типа постов

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

‘taxonomies’ => array(‘category’),

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

‘taxonomies’ => array(‘topics’, ‘category’),

Вот пример целого кода, где мы создали пользовательский тип постов под названием «фильмы» с поддержкой всех встроенных категорий.

Function custom_post_type() { // Set UI labels for Custom Post Type $labels = array("name" => _x("Movies", "Post Type General Name", "twentythirteen"), "singular_name" => _x("Movie", "Post Type Singular Name", "twentythirteen"), "menu_name" => __("Movies", "twentythirteen"), "parent_item_colon" => __("Parent Movie", "twentythirteen"), "all_items" => __("All Movies", "twentythirteen"), "view_item" => __("View Movie", "twentythirteen"), "add_new_item" => __("Add New Movie", "twentythirteen"), "add_new" => __("Add New", "twentythirteen"), "edit_item" => __("Edit Movie", "twentythirteen"), "update_item" => __("Update Movie", "twentythirteen"), "search_items" => __("Search Movie", "twentythirteen"), "not_found" => __("Not Found", "twentythirteen"), "not_found_in_trash" => __("Not found in Trash", "twentythirteen"),); // Set other options for Custom Post Type $args = array("label" => __("movies", "twentythirteen"), "description" => __("Movie news and reviews", "twentythirteen"), "labels" => $labels, "supports" => array("title", "editor", "excerpt", "author", "thumbnail", "comments", "revisions", "custom-fields",), "hierarchical" => false, "public" => true, "show_ui" => true, "show_in_menu" => true, "show_in_nav_menus" => true, "show_in_admin_bar" => true, "menu_position" => 5, "can_export" => true, "has_archive" => true, "exclude_from_search" => false, "publicly_queryable" => true, "capability_type" => "page", // This is where we add taxonomies to our CPT "taxonomies" => array("category"),); // Registering your Custom Post Type register_post_type("movies", $args); } /* Hook into the "init" action so that the function * Containing our post type registration is not * unnecessarily executed. */ add_action("init", "custom_post_type", 0);

Отображение нескольких типов постов на странице категории

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

Add_filter("pre_get_posts", "query_post_type"); function query_post_type($query) { if(is_category()) { $post_type = get_query_var("post_type"); if($post_type) $post_type = $post_type; else $post_type = array("nav_menu_item", "post", "movies"); // don"t forget nav_menu_item to allow menus to work! $query->set("post_type",$post_type); return $query; } }

Не забудьте поменять movies на название своего пользовательского типа постов.

Наша специальность - разработка и поддержка сайтов на WordPress. Контакты для бесплатной консультации - ,

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, а также постарались начать работать над созданием собственных типов. Мы также осветили способы сохранения модульности за счет использования отдельного 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(). А теперь, включаем свет? Все линии сходятся.

Loading...Loading...