Сергей Береснев. Wordpress post type register
регистрация типов постов в WordPress
В случае успеха функция возвращает объект зарегистрированного типа поста, в случае неудачи — объект WP_Error. Функция должна использоваться только внутри хука init.
Читайте подробнее о том, что такое типы записей (типы постов).
| register_post_type( $post_type, $args = array() ) |
- post
- page
- attachment
- revision
- nav_menu_item
- action
- order
- theme
- true — исключить записи данного типа из результатов поиска на сайте,
- false — не исключать.
По умолчанию: противоположные значения параметра public.
show_in_nav_menus (логическое) нужно ли элементы данного типа записей сделать доступными для добавления в меню сайта.По умолчанию: значение аргумента public. show_ui (логическое) нужно ли добавлять стандартный интерфейс в админке для редактирования и добавления записей данного типа.По умолчанию: значение аргумента public.
- true — пункты в меню будут добавлены (это видно на предыдущем скриншоте),
- false — хоть интерфейс для типов постов и будет доступен по прямой ссылке в админке, в меню он не появится,
- ссылку на страницу управления нашим типом поста мы можем добавить как вложенную для другого элемента меню верхнего уровня — для этого нужно будет указать его ID (являющийся атрибут href нужной нам ссылки), например tools.php или edit.php?post_type=page;
По умолчанию: значение аргумента show_ui.
show_in_admin_bar (логическое) нужно ли добавлять ссылку на создание новой записи данного типа в админ панель.
По умолчанию: значение аргумента show_in_menu.
menu_position (целое число) порядок расположения в меню в админке.| 1 | в самом верху меню |
| 2-3 | под «Консоль» |
| 4-9 | под «Записи» |
| 10-14 | под «Медиафайлы» |
| 15-19 | под «Ссылки» |
| 20-24 | под «Страницы» |
| 25-59 | под «Комментарии» (по умолчанию, null) |
| 60-64 | под «Внешний вид» |
| 65-69 | под «Плагины» |
| 70-74 | под «Пользователи» |
| 75-79 | под «Инструменты» |
| 80-99 | под «Параметры» |
| больше 100 | под разделителем после «Параметры» |
Кроме того, в WordPress 3.8 появился встроенный пакет иконок Dashicons — вы можете использовать любую из этих иконок, просто указав её название в качестве значения параметра, например dashicons-cart.
По умолчанию используется иконка обычных записей.
delete_with_user (логическое) при удалении пользователя на блоге, нужно ли автоматически удалять все записи данного типа, которые он опубликовал.По умолчанию: false. hierarchical (логическое) должен ли данный тип постов иметь иерархию.По умолчанию: false. has_archive (логическое|строка) должен ли данный тип постов иметь собственную страницу архивов. В качестве значения параметра можно указать ярлык страницы архивов.По умолчанию: false. rewrite (массив|логическое) устанавливает правила для постоянных ссылок в URL. Если в качестве значения данного параметра указать false, то правила для постоянных ссылок создаваться не будут. slug (строка) ярлык, используемый для записей данного типа (по умолчанию — название типа поста) with_front (логическое) нужно ли добавлять в постоянные ссылки значение $wp_rewite->front (по умолчанию — true) feeds (логическое) нужно ли создавать RSS ленту для данного типа поста (по умолчанию — значение параметра has_archive) pages (логическое) нужно ли разрешить постраничную навигацию в постах регистрируемого типа, используя тег <!--nextpage--> (по умолчанию — true) supports (массив) какие метабоксы нужно добавить на страницы редактирования записей данного типа.- title — поле для ввода заголовка поста
- editor — текстовый редактор
- excerpt — метабокс «Цитата»
- author — метабокс «Автор»
- thumbnail — метабокс «Миниатюра записи» (кроме того, ваша тема должна их поддерживать)
- comments — метабокс «Комментарии» (если указано, то разрешены комментарии к постам регистрируемого типа)
- trackbacks — метабокс «Отправить обратные ссылки»
- custom-fields — метабокс «Произвольные поля» (произвольные поля будут поддерживаться в любом случае)
- revisions — метабокс «Редакции» (если указано, то в базе данных будут создаваться редакции постов данного типа)
- page-attributes — метабокс «Атрибуты страницы» с возможностью выбора родительского эоемента и установления порядка menu_order
- post-formats — метабокс «Формат», про форматы постов читайте подробнее здесь.
Пример регистрации типа поста
Если не знаете, куда вставлять код — вставляйте в functions.php вашей текущей темы.
| add_action( 'init', 'true_register_products' ); // Использовать функцию только внутри хука init function true_register_products() { $labels = array( 'name' => 'Товары', 'singular_name' => 'Товар', // админ панель Добавить->Функцию 'add_new' => 'Добавить товар', 'add_new_item' => 'Добавить новый товар', // заголовок тега <title> 'edit_item' => 'Редактировать товар', 'new_item' => 'Новый товар', 'all_items' => 'Все товары', 'view_item' => 'Просмотр товаров на сайте', 'search_items' => 'Искать товары', 'not_found' => 'Товаров не найдено.', 'not_found_in_trash' => 'В корзине нет товаров.', 'menu_name' => 'Товары' // ссылка в меню в админке ); $args = array( 'labels' => $labels, 'public' => true, // благодаря этому некоторые параметры можно пропустить 'menu_icon' => 'dashicons-cart', // иконка корзины 'menu_position' => 5, 'has_archive' => true, 'supports' => array( 'title', 'editor', 'excerpt', 'thumbnail', 'comments'), 'taxonomies' => array('post_tag') ); register_post_type('product',$args); } |
misha.blog
Wordpress: register_post_type и default taxonomies
Проблема
WordPress 3+ принес нам возможность создавать свои типы постов. Останавливаться на этом сейчас не буду, благо FAQ полно. Есть маленький нюанс, связанный с одной из опций метода register_post_type. Я столкнулся сегодня с тем, что при регистрации своего типа к нему не подключились категории. Решение оказалось тривиальным.
Решение
Вот код регистрации типа данных Course
-
<?
-
register_post_type(‘course’,
- ‘labels’ => array(
-
‘name’ => __(‘Courses’),
-
‘singular_name’ => __(‘Course’),
-
‘not_found’ => __(‘No courses found’),
-
‘not_found_in_trash’ => __(‘No courses found in Trash’),
-
‘edit_item’ => __(‘Edit Course’),
-
‘search_items’ => __(‘Search Courses’),
-
‘view_item’ => __(‘View Course’),
-
‘new_item’ => __(‘New Course’),
-
‘add_new’ => _x(‘Add New’, ‘course’),
-
‘add_new_item’ => __(‘Add New Course’),
-
),
-
‘public’ => true,
-
‘exclude_from_search’ => true,
-
‘menu_position’ => 20,
- ‘taxonomies’ => array(‘category’),
- ‘supports’ => array(
-
‘title’,
-
‘editor’,
-
‘page-attributes’,
-
‘custom-fields’
-
),
-
‘show_in_nav_menus’ => false,
-
)
-
);
Обратите внимание на строку 'taxonomies' => array('category'),. Казалось бы все правильно. Но в интерфейсе категории так и не появились.Копнув по-глубже я обнаружил, что мой код вызывается раньше кода регистрации taxonomy Category.Проблему решило заключение кода в функцию и добавление action’a в точку init
-
<?
-
add_action(‘init’, ‘initCustomPostTypes’);
-
function initCustomPostTypes()
-
{
-
//Courses
-
register_post_type(‘course’,
- ‘labels’ => array(
-
‘name’ => __(‘Courses’),
-
‘singular_name’ => __(‘Course’),
-
‘not_found’ => __(‘No courses found’),
-
‘not_found_in_trash’ => __(‘No courses found in Trash’),
-
‘edit_item’ => __(‘Edit Course’),
-
‘search_items’ => __(‘Search Courses’),
-
‘view_item’ => __(‘View Course’),
-
‘new_item’ => __(‘New Course’),
-
‘add_new’ => _x(‘Add New’, ‘course’),
-
‘add_new_item’ => __(‘Add New Course’),
-
),
-
‘public’ => true,
-
‘exclude_from_search’ => true,
-
‘menu_position’ => 20,
- ‘taxonomies’ => array(‘category’),
- ‘supports’ => array(
-
‘title’,
-
‘editor’,
-
‘page-attributes’,
-
‘custom-fields’
-
),
-
‘show_in_nav_menus’ => false,
-
)
-
);
-
}
keriat.ru
Руководство по созданию пользовательских типов постов в Wordpress
WordPress за последние годы стал одной из наиболее популярных систем управления контентом (CMS), но настоящий прорыв произошел с созданием механизма пользовательских типов постов, который позволяет создавать различного типа контент. Давайте посмотрим, как это сделать, и какие возможности это замечательная функциональность предлагает.
На практике, пользовательские типы сообщений были введены давно, а точнее с 17 февраля 2005 года, когда в WordPress 1.5 была добавлена поддержка статических страниц, и добавлено поле post_type в базу данных.
Функция wp_insert_post() была еще в WordPress 1.0, так что после того как поле post_type было добавлено в версии 1.5, вы можете просто установить нужное значение в поле post_type при добавлении записи. Конечно, для создания и управления пользовательскими типами сообщений требуется гораздо больше, чем просто добавления нужного значения в поле post_type, однако объем необходимого кодирования постоянно уменьшается, так как функции WordPress становятся все более и более гибкими.
Начиная с версии 2.9, функция register_post_type() и некоторые другие полезные методы стали доступны каждому. На данный момент, трудоемкое кодирование и хаки не нужны, чтобы сделать WordPress полномасштабной CMS, и вы можете использовать множество мощных встроенных функций.
Пользовательский тип записи - это не более чем обычный пост с другим значением в поле post_type в базе данных. Тип поста для обычного сообщения - это post, для страниц используется тип page, аттачменты используют тип attachment, и так далее. Теперь же вы можете создавать свои собственные типы для созданного контента. Вы можете создавать пользовательские типы сообщений, например, для книг, фильмов, рецензий, продуктов и так далее.
Если все создано правильно, вам понадобится всего лишь нескольких строк кода, чтобы создать следующее:
- Пользовательский тип записей будет отображаться в админке в виде отдельного пункта меню со своим собственным списком постов и пунктом "добавить новую" запись.
- Переход по http://mysite.com/customposttype/ приведет вас на страницу архива для этого типа записей.
- Категории и теги могут быть также сделаны доступными для пользовательских типов сообщений, или вы можете создать пользовательскую таксономию.
Различные типы контента имеют различные требования к данным. Для обычного сообщения, вы можете указать автора, категорию, дату и так далее. Для типа сообщений «книги», в идеале вы должны бы иметь возможность указать автора книги, количество страниц, жанр, издательство и другие специфичные для книги данные. Используя пользовательские мета-поля, это легко реализовать. Пользовательские мета-поля позволяют вам добавлять дополнительные поля для редактирования сообщения.
Работа с пользовательскими типами сообщений
Чтобы эффективно создавать и использовать пользовательские типы сообщений, вы должны быть знакомы со следующим:
- Создание пользовательских типов сообщений,
- Создание пользовательской таксономии,
- Создание пользовательских мета-полей.
Создание пользовательских типов сообщений
Первым на повестке дня является создание собственных типов сообщений. В идеале вы должны создать плагин для работы с пользовательскими типами постов, но если вы не знаете как это сделать, или просто нужен быстрый тест, вы можете использовать файл functions.php в вашей теме.
function my_custom_post_product() { $args = array(); register_post_type( 'product', $args ); } add_action( 'init', 'my_custom_post_product' );Это простейший вариант, он создаст тип сообщения, который практически не имеет настроек. Он не будет отображаться в админке, информационные мессаджи будут такими же, как для остальных постов ("сообщение сохранено", "сообщение обновлено" и т.д.) и так далее. Для разработки нового типа наших сообщений, соответствующего нашим потребностям, добавим ряд настроек при помощи массива $args.
function my_custom_post_product() { $labels = array( 'name' => _x( 'Книги', 'post type general name' ), 'singular_name' => _x( 'Книга', 'post type singular name' ), 'add_new' => _x( 'Добавить новую', 'book' ), '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' => 'Holds our products and product specific data', 'public' => true, 'menu_position' => 5, 'supports' => array( 'title', 'editor', 'thumbnail', 'excerpt', 'comments' ), 'has_archive' => true, ); register_post_type( 'product', $args ); } add_action( 'init', 'my_custom_post_product' );labels: параметр labels должен содержать массив, определяющий различные надписи, необходимые для пользовательского типа записи. description: краткое описание для нашего пользовательского типа записи, для чего мы его используем.public: этот опция управляет массой вещей одновременно. Установка её как true включает массу других опций. Подробнее об этом позже.menu_position: определяет позицию меню пользовательского типа поста в админке. Чем больше значение вы установите, тем ниже меню будет размещено.supports: эта опция устанавливает элементы управления WordPress, которые доступны на странице редактирования для пользовательского типа поста. По умолчанию, только поле title и редактор показаны. Если вы хотите добавить поддержку для комментариев, ревизий, миниатюр и пр., вы должны будете указать их здесь. Для получения полного списка возможных параметров смотрите документацию.has_archive: если установлено как true, то URL для данной категории будет в виде mysite.com/posttype/ (по умолчанию)
После добавления этого кода, вы должны увидеть меню для пользовательского типа записей. Теперь вы будете иметь возможность добавлять сообщения, просматривать список постов этого типа в админке, а также видеть сообщения на сайте.
Пользовательские информационные сообщения
WordPress генерирует множество сообщений, в ответ на действиями пользователя. Обновление, публикации, поиск и т.д., все это ведет к появлению информационных сообщений, которые, по умолчанию, адаптированы для стандартных действий. Но Вы можете легко изменить текст этих сообщений с помощью хука post_updated_messages.
function my_updated_messages( $messages ) { global $post, $post_ID; $messages['product'] = array( 0 => '', 1 => sprintf( __('Product updated. <a href="%s">View product</a>'), esc_url( get_permalink($post_ID) ) ), 2 => __('Custom field updated.'), 3 => __('Custom field deleted.'), 4 => __('Product updated.'), 5 => isset($_GET['revision']) ? sprintf( __('Product restored to revision from %s'), wp_post_revision_title( (int) $_GET['revision'], false ) ) : false, 6 => sprintf( __('Product published. <a href="%s">View product</a>'), esc_url( get_permalink($post_ID) ) ), 7 => __('Product saved.'), 8 => sprintf( __('Product submitted. <a target="_blank" href="%s">Preview product</a>'), esc_url( add_query_arg( 'preview', 'true', get_permalink($post_ID) ) ) ), 9 => sprintf( __('Product scheduled for: <strong>%1$s</strong>. <a target="_blank" href="%2$s">Preview product</a>'), date_i18n( __( 'M j, Y @ G:i' ), strtotime( $post->post_date ) ), esc_url( get_permalink($post_ID) ) ), 10 => sprintf( __('Product draft updated. <a target="_blank" href="%s">Preview product</a>'), esc_url( add_query_arg( 'preview', 'true', get_permalink($post_ID) ) ) ), ); return $messages;} add_filter( 'post_updated_messages', 'my_updated_messages' );Хотя, как вы можете видеть, это не самый удобный способ управления сообщениями.
Обратите внимание, что вы можете изменить сообщения для всех пользовательских типов постов с помощью этой одной функции. Массив $messages содержит сообщения для всех типов постов, так что вы можете изменить их все здесь.
Контекстная справка
Эту функциональность я редко вижу реализованной на сайтах. Как пользователь, я никогда не использовал эту возможность, но я уверен, что многие люди используют её.
Контекстную справку на раскрывающейся вкладке можно увидеть в правом верхнем углу страницы. Давайте посмотрим, как её содержимое может быть изменено.
function my_contextual_help( $contextual_help, $screen_id, $screen ) { if ( 'product' == $screen->id ) {$contextual_help = '<h3>Products</h3> <p>Products show the details of the items that we sell on the website. You can see a list of them on this page in reverse chronological order - the latest one we added is first.</p> <p>You can view/edit the details of each product by clicking on its name, or you can perform bulk actions using the dropdown menu and selecting multiple items.</p>'; } elseif ( 'edit-product' == $screen->id ) { $contextual_help = '<h3>Editing products</h3> <p>This page allows you to view/modify product details. Please make sure to fill out the available boxes with the appropriate details (product image, price, brand) and <strong>not</strong> add these details to the product description.</p>'; } return $contextual_help;}add_action( 'contextual_help', 'my_contextual_help', 10, 3 );
Это немного сложно, потому что вы должны знать ID экрана, на котором вы находитесь. Если вы выведите на экран переменную $screen, вы легко определите ID экрана. Это функцию также можно использовать для изменения контекстной справки всех пользовательских типов сообщений за раз, но я лично рекомендую их группировать вместе с предыдущими двумя блоками и использовать её только для одного пользовательского типа записи за один раз.
Напомним, что мы использовали три функции для создания «полноценного» пользовательского типа поста. Мы использовали функцию register_post_type() для создания собственного типа поста и два хука - contextual_help и post_updated_messages - для создания полезной справки и релевантных сообщений, соответственно.
Пользовательская таксономия
Ваши обычные сообщения в блоге используют категории и теги для создания организационной структуры. Тем не менее, такая же организация не всегда будет подходить для пользовательских типов постов. Ваши сообщения в блоге могут быть о "жизни", ваших "мыслях" или "мечтах", что, очевидно, не подходит для продуктов или книг.
Эта проблема вынудила разработчиков создавать пользовательскую таксономию. Вы можете создать отдельную таксономию под названием «Категории продуктов» и использовать её только для продуктов. Кевин Лири написал большую статью о пользовательской таксономии в WordPress, которую я очень рекомендую прочитать.
function my_taxonomies_product() { $args = array(); register_taxonomy( 'product_category', 'product' $args );} add_action( 'init', 'my_taxonomies_product', 0 );Аналогично пользовательским типам сообщений, вы также можете очень легко создать таксономию, но нужно поработать над ней немного, чтобы адаптировать её к вашим потребностям. Давайте посмотрим на этот пример:
function my_taxonomies_product() { $labels = array( 'name' => _x( 'Product Categories', 'taxonomy general name' ), 'singular_name' => _x( 'Product Category', 'taxonomy singular name' ), 'search_items' => __( 'Search Product Categories' ), 'all_items' => __( 'All Product Categories' ), 'parent_item' => __( 'Parent Product Category' ), 'parent_item_colon' => __( 'Parent Product Category:' ), 'edit_item' => __( 'Edit Product Category' ), 'update_item' => __( 'Update Product Category' ), 'add_new_item' => __( 'Add New Product Category' ), 'new_item_name' => __( 'New Product Category' ), 'menu_name' => __( 'Product Categories' ), ); $args = array( 'labels' => $labels, 'hierarchical' => true, ); register_taxonomy( 'product_category', 'product', $args );} add_action( 'init', 'my_taxonomies_product', 0 );Как видите, код очень поход на предыдущий пример с созданием пользовательского типа постов. Мы добавили некоторые надписи и установили опцию hierarchical равную true. Это позволяет использовать таксономию как категории. При установке этого параметра как false (это по умолчанию), таксономия будет как теги.
Там есть еще несколько других настроек, о которых вы можете прочитать в статье, на которую я дал ссылку выше, или вы можете прочитать в документации к функции register_taxonomy().
Мета-поля записей
Мета-поля - это перетаскиваемые блоки, которые вы видите на экране при редактировании записи. Есть множество встроенных мета-полей, таких как настройки публикации, таксономия, автор записи и т.д., но вы можете создать несколько своих собственных областей.
Мета-поля, как правило, используются для гораздо более удобного управления пользовательскими данными. Вы можете добавить, например, проверку ошибок на стороне клиента и многие другие полезные вещи.
Justin Tadlock написал подробную статью о пользовательских мета-полях, которая является наиболее полной статьей на эту тему. Я рекомендую прочитать её для глубокого изучения вопроса, но начать вы можете здесь.
Создание мета полей требует трех шагов:
- Определить само поле,
- Определить содержание мета поля
- Определите, каким образом данные из поля обрабатываются.
Определение мета поля
add_action( 'add_meta_boxes', 'product_price_box' );function product_price_box() { add_meta_box( 'product_price_box', __( 'Product Price', 'myplugin_textdomain' ), 'product_price_box_content', 'product', 'side', 'high' );}
Приведенный выше код создает мета область со следующими параметрами (в указанном порядке):
- Уникальный идентификатор для мета поля (оно не обязательно должно совпадать с именем функции),
- Название мета поля (видимое для пользователей),
- Функцию, которая будет отображать содержимое поля,
- Тип поста, которому мета поле принадлежит,
- Место размещения мета поля
- Приоритет мета поля (определяет "как высоко" оно будет находится).
Определение содержания мета области:
function product_price_box_content( $post ) { wp_nonce_field( plugin_basename( __FILE__ ), 'product_price_box_content_nonce' ); echo '<label for="product_price"></label>'; echo '<input name="product_price" placeholder="enter a price" type="text">';}
Это простая область данных, которая содержит только цену, поэтому мы создали лейбл и текстовое поле для управления ей. Поле nonce добавляется по требованиям безопасности.
Обработка данных
В большинстве случаев, вы сохраняете эти данные как пользовательское поле, но Вы можете также вызывать API какого-либо сервиса, создавать XML-файл и так далее. Но все же наиболее распространенное использование - это сохранение пользовательских данных, так что давайте рассмотрим, как это можно сделать.
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 );}
Большая часть этой функции относится к безопасности. Вначале, если автосохранение выполнено, то ничего не происходит, потому что пользователь фактически не засабмитил форму. Затем проверяется поле nonce, после чего проверяются права доступа. Если все проверки прошли, мы обновляем данные с помощью функции update_post_meta().
Отображения содержимого
Если вы создали сообщение с параметром has_archive установленным как "true", то WordPress будет выводить список этих сообщений на странице архива сообщений этого типа. Если ваш пользовательский тип сообщений называется "book", то вы можете просто перейти по адресу http://mysite.com/books/, и вы увидите список постов этого типа.
Эта страница использует файл archive-[post_type].php для отображения, если он существует (в нашем случае это archive-books.php). Если он не существует, то будет использоваться archive.php, а если и он не существует в папке с темой, то будет использоваться файл index.php.
Еще один способ отображения пользовательского типа контента, это использование пользовательских запросов с помощью класса WP_Query. Для отображения сообщений с определенным типом и пользовательской таксономией, вы могли бы написать что-то вроде этого:
<?php $args = array( 'post_type' => 'product', 'tax_query' => array( array( 'taxonomy' => 'product_category', 'field' => 'slug', 'terms' => 'boardgames' ) ) ); $products = new WP_Query( $args ); if( $products->have_posts() ) { while( $products->have_posts() ) { $products->the_post(); ?> <?php the_title() ?> <?php the_content() ?> <?php } } else { echo 'Oh ohm no products!'; }?>Отображение метаданных
Метаданные могут быть легко получены с помощью функции get_post_meta(). В нашем примере выше, мы сохраняли мета-поле с именем product_price. Мы можем получить значение этого поля, используя следующий код:
<?php // If we are in a loop we can get the post ID easily $price = get_post_meta( get_post_ID(), 'product_price', true );// To get the price of a random product we will need to know the ID $price = get_post_meta( $product_id, 'product_price', true );?>
Заключение
Как вы можете видеть, создание полноценной CMS довольно просто благодаря модульной системе WordPress и встроенным функциям. Методы, описанные здесь, могут быть использованы для создания полностью настроиваемого содержимого на сайте и в админке.
Перевод статьи с smashingmagazine.com
Если у Вас возникли вопросы, то для скорейшего получения ответа рекомендуем воспользоваться нашим форумом
Комментарии:
Добавить комментарий
www.webmasters.by
