В WordPress есть возможность иметь разные типы типов записей. Основной тип записей, который вы будете использовать в WordPress, — это тип записей, называемый post . Но есть и другие значения по умолчанию, такие как страницы и вложения. Все типы записей в WordPress хранятся в одной и той же таблице. Wp_posts, в этой таблице есть столбец, который будет определять тип записи, это определяется как post_type .
В версии 3.0 WordPress была создана функция, позволяющая легко создавать собственные типы сообщений.
Типы сообщений по умолчанию
Два основных типа записей — это пост и страница, основные различия между этими двумя типами постов в том, как они используются в WordPress для отображения вашего контента. Сообщение в основном используется для блога, как структура, это позволит вам легко отображать весь ваш контент в порядке опубликованной даты. Это означает, что вы можете отобразить список всех ваших сообщений в том порядке, в котором они были опубликованы. Вы можете использовать этот тип поста для любого контента, который можно упорядочить по дате, это не обязательно должны быть посты в блоге.
Другим отличием постов от страниц является возможность назначать категории и теги для группировки постов, например, в блоге вы можете создать категорию статей, категорию учебника, категорию новостей. Теперь вы можете просмотреть все сообщения в этих категориях снова в порядке дат, чтобы показать все возможные сообщения.
Страницы не привязаны к конкретной дате и не могут быть назначены категориям или тегам. По этой причине они, как правило, будут использоваться для страниц статического типа, таких как форма контакта, страницы с отображением категорий, карта сайта, условия и т . Д. Страницам могут быть назначены шаблоны страниц, так что вы можете создать шаблон PHP для отображения контента, тогда все, что вам нужно сделать, это назначить этот шаблон страницам, чтобы они отличались от стандартных страниц постов блога.
Как создать пользовательский тип сообщения
Пользовательские типы сообщений были первым шагом от превращения WordPress из блогового приложения в полноценную CMS. Если вам нужно создать новый тип контента, вам нужно принять решение о том, как этот контент будет использоваться в вашем приложении, соответствует ли контент вашим стандартным постам в блоге и, следовательно, может отличаться, назначая другую категорию для Это? Будет ли содержание больше вписываться в страницу и не зависит от конкретной даты? Или это новый тип контента, например, если вы создавали магазин и хотите показывать товары, тогда он не подходит как пост или страница, поэтому нам нужно создать наш собственный тип поста .
Создание нового пользовательского типа записи добавит новый элемент в меню администратора для этого нового типа записи, чтобы вы могли легко создавать новый контент.
Чтобы определить новый пользовательский тип записи, вам нужно использовать функцию register_post_type () . Эта функция принимает 2 параметра, первый из которых является новым именем для типа записей, а второй — список аргументов, определяющих поведение для типа записей.
add_action( 'init', 'create_post_type' );
function create_post_type() {
$args = array();
register_post_type( 'post_type_name', $args);
}
Существует список аргументов, которые вы отправляете этой функции, и каждый из них определяет, как можно использовать тип записи.
- label — строка для описательного имени множественного числа для типа сообщения.
- ярлыки — массив описательных имен для типов записей.
- описание — краткое описание типа сообщения.
- public — логическое значение, если тип записи может быть виден публике и, следовательно, может быть просмотрен из внешнего интерфейса.
- exclude_from_search — логическое значение, если этот тип сообщения можно искать.
- publicly_queryable — логическое значение, если этот тип сообщения может быть запрошен.
- show_ui — логическое значение, если WordPress сгенерирует пользовательский интерфейс для управления типом записи.
- show_in_nav_menus — логическое значение, чтобы решить, можете ли вы отображать этот тип записи в меню.
- show_in_menu — логическое значение, чтобы решить, будет ли этот тип сообщения отображаться в меню администратора.
- show_in_admin_bar — логическое значение, чтобы решить, отображается ли тип сообщения в панели администратора.
- menu_position — целое число для позиционирования меню типа сообщения.
- menu_icon — URL-адрес для отображения значка рядом с элементом меню.
- ability_type — строка, используемая для создания возможностей чтения, редактирования и удаления.
- Возможности — Массив возможностей для этого типа сообщений.
- map_meta_cap — логическое значение, чтобы решить, хотите ли вы использовать мета-обработку по умолчанию.
- иерархический — логическое значение, определяющее, можно ли назначать этот тип записи категориям / тегам.
- Поддерживает — Массив сообщений, которые поддерживает этот тип сообщений.
- register_meta_box_cb — Предоставить функцию обратного вызова для создания любых мета-полей сообщений.
- таксономии — массив зарегистрированных таксономий, которые может использовать этот тип записей.
- has_archive — логическое значение для включения типов записей.
- rewrite — массив того, как URL-слагы будут переписаны.
- query_var — Строка, чтобы установить ключ для типа сообщения.
- can_export — логическое значение, чтобы проверить, можно ли экспортировать это сообщение.
Вот пример использования этих аргументов для создания вашего пользовательского типа записи .
add_action( 'init', 'register_cpt_cp_name' );
function register_cpt_cp_name() {
$labels = array(
'name' => __( 'plural post type name', 'text_domain' ),
'singular_name' => __( 'single post type name', 'text_domain' ),
'add_new' => _x( 'Add New single post type name', '${4:Name}', 'text_domain' ),
'add_new_item' => __( 'Add New single post type name', 'text_domain}' ),
'edit_item' => __( 'Edit single post type name', 'text_domain' ),
'new_item' => __( 'New single post type name', 'text_domain' ),
'view_item' => __( 'View single post type name', 'text_domain' ),
'search_items' => __( 'Search plural post type name', 'text_domain' ),
'not_found' => __( 'No plural post type name found', 'text_domain' ),
'not_found_in_trash' => __( 'No plural post type name found in Trash', 'text_domain' ),
'parent_item_colon' => __( 'Parent single post type name:', 'text_domain' ),
'menu_name' => __( 'plural post type name found', 'text_domain' ),
);
$args = array(
'labels' => $labels,
'hierarchical' => true,
'description' => 'description',
'taxonomies' => array( 'category' ),
'public' => true,
'show_ui' => true,
'show_in_menu' => true,
'menu_position' => 5,
//'menu_icon' => '',
'show_in_nav_menus' => true,
'publicly_queryable' => true,
'exclude_from_search' => false,
'has_archive' => true,
'query_var' => true,
'can_export' => true,
'rewrite' => true,
'capability_type' => 'post',
'supports' => array(
'title', 'editor', 'author', 'thumbnail',
'custom-fields', 'trackbacks', 'comments',
'revisions', 'page-attributes', 'post-formats'
),
);
register_post_type( 'cp_name', $args );
}
Файлы шаблонов тем
Когда вы создаете новый пользовательский тип записи по умолчанию, он будет использовать тот же HTML- код, что и в файле single.php , но если вы создали пользовательский тип записи, то, скорее всего, вы захотите отобразить его иначе, чем в стандартных типах записей . Поэтому вы можете добавить новый файл шаблона, который будет использоваться при отображении вашего пользовательского типа записи.
Для одиночных шаблонов все, что вам нужно сделать, это создать новый файл темы и вызвать single- {posttype} .php , поэтому для приведенного выше примера вы создадите новый файл с именем single-cp_name.php , теперь он будет использоваться для отображения Ваш пользовательский тип сообщения.
Вы даже можете отобразить достижения для этого типа записей, создав новый файл шаблона с именем reach-cp_name.php .
Запрос пользовательского типа сообщения
Если вы хотите, чтобы этот новый пользовательский тип записи отображался со стандартными типами сообщений, вы можете изменить основной запрос WordPress, включив в него свой пользовательский тип записи . Для этого вам нужно использовать фильтр pre_get_posts, чтобы добавить пользовательский тип записи в запрос.
add_action( 'pre_get_posts', 'add_custom_post_type_to_query' );
function add_custom_post_type_to_query( $query ) {
if ( is_home() && $query->is_main_query() )
$query->set( 'post_type', array( 'post', 'page', 'new-custom-post-type' ) );
return $query;
}
Переписать проблемы
У меня это было несколько раз: вы создаете тип поста, а затем, когда вы пытаетесь передать контент на внешний интерфейс, вы получаете ошибку 404 и не можете понять, почему. Тип записи настроен правильно, файл шаблона там еще ничего не отображается, и вы получите страницу 404.
Скорее всего, проблема в том, что правила перезаписи не были обновлены. Правила переписывания WordPress хранятся в таблице wp_options и используются для направления WordPress к нужному контенту. Иногда их необходимо обновлять при создании нового пользовательского типа записи. Для этого есть три способа.
Сначала вы можете перейти на страницу «Постоянные ссылки» «Настройки» -> «Постоянные ссылки» и изменить постоянную ссылку, нажав кнопку «Сохранить», а затем изменить ее на прежнюю. Это обновит все правила перезаписи на вашем сайте, и ваши типы сообщений должны отображаться.
Во-вторых, вы можете открыть phpMyAdmin, перейти к таблице wp_options и удалить запись правил перезаписи из этой таблицы. В следующий раз, когда WordPress загрузится, он проверит правила перезаписи в этой таблице, если их там нет, то он создаст правила заново.
Третий вариант — поместить функцию flush_rewrite_rules () в функцию типа записи реестра. Это полностью обновит правила типа записей и исправит все проблемы с перенаправлением.
register_post_type( 'portfolio' , $args ); flush_rewrite_rules();
Плагин Или Functions.php
Теперь перейдем к большой дискуссии, когда речь заходит о пользовательских типах сообщений. Все согласны с тем, что пользовательские типы сообщений — это отличная функциональность, и это означает, что вы можете значительно расширить сферу своего приложения WordPress. Но проблема в том, что вам нужно решить, куда поместить код для создания пользовательского типа записи.
Во всех функциях на вашем сайте WordPress вы можете определить его в двух местах: в плагине или в теме functions.php. Каждый элемент функциональности, который вы добавляете на свой сайт, должен быть определен для размещения в одном из этих мест. То, как вы решаете, где функционировать, довольно просто, должна ли эта функциональность существовать в какой-либо теме, которую я использую? Если ответ «да», добавьте его с помощью плагина. Если функциональность, которую вы добавляете, предназначена для облегчения дизайна сайта, тогда он должен находиться в файле functions.php.
Просто, не правда ли … вы обнаружите, что большую часть времени добавляемая вами функциональность живет в плагине, и большую часть времени я обнаруживаю, что мой файл functions.php почти пуст.
Но с пользовательскими типами постов линии между плагином и темой могут быть размыты. С одной стороны, вы говорите, что это данные для сайта, если я изменю свою тему, то я хочу иметь возможность использовать этот контент в следующей теме, поэтому я размещаю пользовательские типы сообщений в плагине. То есть, когда я меняю тему, весь контент все еще будет доступен, мне просто нужно добавить файлы новой темы, чтобы отобразить этот контент так, как я хочу.
Другая сторона дискуссии состоит в том, что в пользовательских типах записей есть данные, которые будут отображаться с использованием темы, вам необходимо создать файлы пользовательских тем для отображения этих данных, поэтому пользовательские типы сообщений должны находиться в файле functions.php темы. Проблема возникает, когда вы хотите изменить темы, вы теряете весь этот контент … очень раздражает. Вы по-прежнему можете получить доступ к этому контенту в базе данных или повторно добавив код регистрационного типа в файл functions.php, но обычные пользователи не будут знать об этом, они будут только предполагать, что весь их контент потерян.
На премиум-темах с популярных торговых площадок вы увидите множество тем с пользовательскими типами записей в файле functions.php, наиболее распространенный тип записей — раздел портфолио. Я был бы очень раздражен, если бы я потратил 50 долларов на тему, включил весь контент для своего портфолио только для того, чтобы потерять его, когда я сменил тему.
Единственный раз, когда я могу подумать о том, когда можно использовать пользовательские типы записей в файле functions.php, это если вы создаете чрезвычайно нишевую тему, которая не будет использоваться другим сайтом. Поэтому, если в будущем пользователь должен будет изменить темы, он должен будет создать собственную тему для своего веб-сайта.
Лично я считаю, что пользовательские типы сообщений всегда должны размещаться в плагине, это данные, которые вы всегда хотите иметь на своем сайте, даже если вы меняете темы, так же как и в плагине. Данные могут быть недоступны для просмотра темой, но, по крайней мере, пользователь может видеть их в административной области и знает, что данные не потеряны.
Что вы думаете? Пользовательские типы сообщений в плагине или файл functions.php?