Непорочный post type. Register_post_type() — позволяет зарегистрировать новый тип поста

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

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

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

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

От автора: Дни, когда WordPress был просто системой для блогов, прошли. Возможность расширения функционала с помощью плагинов и тем, группировка постов, структурирование данных по типам, а также появление в ядре WP Rest API привели к эволюционированию WordPress в полномасштабную систему управления контентом и платформу разработки.

За эти годы я успешно создал большое количество кастомных веб-приложений на новейших версиях WordPress, в которых по полной использовались кастомные типы постов. Примером может послужить сайт theme marketplace моего плагина для WordPress ProfilePress .

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

Ну хватит долгих речей, перейдем к основной цели данного урока – изучению всех тонкостей пользовательских типов в WordPress.

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

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

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

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

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

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

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

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

function portfolio_cpt() { $args = array("label" => "Portfolio", "public" => true,); register_post_type("portfolio", $args); } add_action("init", "portfolio_cpt");

function portfolio_cpt () { $ args = array ( "label" = > "Portfolio" , "public" = > true , register_post_type ("portfolio" , $ args ) ;

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

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

function portfolio_cpt() { register_post_type("portfolio"); } add_action("init", "portfolio_cpt");

function portfolio_cpt () { register_post_type ("portfolio" ) ; add_action ("init" , "portfolio_cpt" ) ;

Если создать тип, как показано выше, то он не будет отображаться в панели администратора (хотя к нему по-прежнему можно обратиться по ссылке http://example.com/wp-admin/edit.php?post_type=portfolio“), название также не будет отображаться (label), а уведомления администратора будут такими же, как и для встроенных типов постов. Пробежимся по аргументам массива настройки пользовательских типов и по соответствующим функциям.

Label

Множественное описательное имя типа. К примеру, если создать тип movie, то он должен называться Movies. По умолчанию стоит $post_type – первый параметр в функции register_post_type().

Labels

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

name: Множественная форма названия типа постов.

singular_name: Форма названий типов постов в единственном числе.

add_new: Пункт меню для добавления нового поста.

add_new_item: При создании нового поста отображается заголовок.

edit_item: Заголовок отображается при редактировании поста.

new_item: Отображается в меню любимых в шапке панели администратора.

search_items: Текст кнопки панели поиска на экране редактирования поста.

not_found: Текст отображается, когда не найдено ни одного поста в поиске через панель администратора.

not_found_in_trash: Текст отображается, когда в корзине нет постов.

Полный список лейблов и их описаний можно найти по ссылке .

Description

Краткое описание типа поста. Я не нашел, где в WordPress можно это задействовать.

Public

В зависимости от Булева значения оно автоматически решит, какие должны быть аргументы, если они не заданы. Если вы хотите контролировать публичные аргументы, можно задать три аргумента:

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

publicly_queryable: задает, можно ли выполнить запросы по этому типу постов со стороны пользователя.

exclude_from_search: должны ли посты появляться в результатах поиска.

menu_position

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

menu_icon

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

"menu_icon" => get_stylesheet_directory_uri() . "/images/portfolio-icon.png",

Hierarchical

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

Supports

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

title: Поле ввода текста для создания заголовка поста.

editor: TinyMCE редактор для написания текста поста.

thumbnail: встроенные изображения.

excerpt: Область textarea для отрывка поста.

trackbacks: включение и отключение трекбеков и пингбеков.

custom-fields: кастомные поля input.

comments: включение или отключение комментариев.

revisions: Возможность редакции постов.

post-formats: Добавляет форматы постов

page-attributes: Атрибуты страницы. Важный параметр для иерархических типов постов, можно выбрать родительский пост.

register_meta_box_cb

Добавляет колбэк функцию, которая вызывается при установке мета боксов для формы редактирования. Функция принимает один аргумент $post, в котором хранится объект WP_Post текущего редактируемого поста. Функция особенно полезна для разработчиков. С ее помощью можно создавать пользовательские мета боксы, которые будут отображаться на экране редактирования типа.

"register_meta_box_cb" => "metabox_callback_func",

has_archive

Если установить данный аргумент в true, к кастомным типам постов добавятся архивы. К примеру, новый тип books, если зайти на страницу http://yoursite.com/books, то отобразится список постов по типу books.

Rewrite

С помощью данного аргумента при просмотре одного поста или архива можно задать структуру ссылок данного типа. По умолчанию стоит true и используется переменная $post_type. Чтобы отключить перезапись, необходимо установить данный параметр в false. Для полной ясности разберем пару примеров. Скажем, вы создали новый тип постов review и хотите изменить URL с review на assessment. Аргумент для перезаписи ниже изменит URL с http://example.com/review/harry-potter/ на http://example.com/assessment/harry-potter/ для конкретного поста и http://example.com/review/ на http://example.com/assessment/ для архива данного типа.

false

Всегда при изменении URL в WordPress сохраняйте изменения в панели Настройки >> ссылки для повторного создания правил перезаписи. Параметр slug отвечает за URL, а with_front задает будет структуру ссылки. Все еще не поняли для чего нужен with_front? Разберем пример. Скажем, структура вашей ссылки точно такая же как на изображении ниже с надписью blog на конце.

Если with_front равен false, URL конкретного поста и архива будут выглядеть http://example.com/blog/assessment/harry-potter/ и http://example.com/blog/assessment соответственно, но если задать true, то ссылки к посту и к архиву будут следующие http://example.com/assessment/harry-potter/ и http://example.com/assessment/. Заметили, что в последних ссылках нет blog? Вот в этом разница.

can_export

С помощью данного аргумента можно задать, можно ли экспортировать посты кастомного типа через инструменты WordPress. По умолчанию стоит true.

query_var

С помощью данного аргумента можно контролировать переменные запроса, используемые для получения постов данного типа.
Если задано true, вы сможете запросить кастомный тип book по ссылке example.com/?book=harry-potter, где harry-potter это параметр slug ссылки. Если задать строку, а не true, можно написать так: example.com/?publication=harry-potter.

Нюанс с query_var

Если query_var не задан в аргументе массива регистрации типа, по умолчанию устанавливается значение $post_type, т.е. данный параметр задан всегда, если его принудительно не установить в false.

И тут есть один нюанс. Если значение query_var добавить через строку запроса в URL, всегда будет выдаваться страница 404. Тут нужно прояснить. Скажем, значение query_var равно review, то URL вашего сайта можно указать в любой из следующих форм:

Эти ссылки приведут вас на странице 404. Об этом я узнал по собственному горькому опыту. Когда я столкнулся с этой проблемой я создал тему на WordPress core trac и сообщил об ошибке. У меня ушло несколько недель на то, чтобы разобраться с этой проблемой перед тем, как мне ответила команда WordPress.

Ускоряем настройку пользовательских типов постов с помощью плагинов

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

Custom Post Type UI

Custom Post Type Maker

Заключение

В этом уроке мы узнали, что такое пользовательские типы постов и как их создавать. Эта первая статья из серии о кастомных типах постов в 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”, в хлебных крошках вы получите ссылку на категорию, к которой принадлежит Новость, при других вариантах вывода кастомных записей это не получалось сделать.

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