Пользовательские посты типа пострадала вас? Нет ничего более разочаровывающего в разработке для WordPress, чем работа с настраиваемой нумерацией пост-типов. Я разработал метод, который решил мои проблемы, и я думаю, что он решит и ваши тоже.
Вступление
Поскольку я начал создавать больше премиальных тем WordPress, я начал разрабатывать базовую тему как своего рода фреймворк, который можно использовать в каждом новом проекте. Процесс шел хорошо, пока я не начал работать с пользовательскими типами постов . Вот когда я неизбежно столкнулся с моим давним врагом, пользовательским постагированием типа поста.
После выпуска пользовательских типов записей в WordPress 2.9 их разбиение на страницы оказалось трудным в зависимости от обстоятельств. Даже сильные профессионалы WordPress время от времени оказывались в тупике .
К счастью, я чувствую, что наконец-то разбил нумерацию страниц пост-типа. Я представляю, как сгибаюсь над ним в свете лунного света, мое лицо отточено от свершения, одна нога упирается в землю, а другая твердо в грудь.
Мой ключ к простому настраиваемому разбиению на страницы записей — использование шаблона archive-posttype.php для выполнения чего-то, что я называю цепочкой , то есть мы используем их так, как они включены в другие файлы шаблонов WordPress, где требуется разбиение на страницы. То, что это делает, сокращает пользовательскую разработку для различных обстоятельств, в которых разработчик хотел бы разбивать на страницы. Думайте об этом как об использовании пользовательского шаблона архива типа поста в качестве индекса или всеобъемлющего. На этом пути есть несколько поворотов, но это большая идея. Давайте начнем.
Шаг 1 Нумерация страниц
Поскольку кодирование является фундаментальной наукой, давайте начнем с вопроса о нумерации страниц. Несмотря на то, что я кланяюсь величию плагина для нумерации страниц, WP PageNavi , как недавно отметил Джейкоб Голдман , в этом действительно нет необходимости . WordPress имеет собственную функцию разбиения на страницы, называемую paginate_links (), и, очевидно, большинство разработчиков ничего об этом не знают. Обязательно прочитайте его документацию, но чтобы сэкономить время на разработку собственного кода для functions.php, вот мой пример, подобный примеру Кодекса:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
|
function paginate() {
global $wp_query, $wp_rewrite;
$wp_query->query_vars[‘paged’] > 1 ?
$pagination = array(
‘base’ => @add_query_arg(‘page’,’%#%’),
‘format’ => »,
‘total’ => $wp_query->max_num_pages,
‘current’ => $current,
‘show_all’ => true,
‘type’ => ‘plain’
);
if ( $wp_rewrite->using_permalinks() ) $pagination[‘base’] = user_trailingslashit( trailingslashit( remove_query_arg( ‘s’, get_pagenum_link( 1 ) ) ) . ‘page/%#%/’, ‘paged’ );
if ( !empty($wp_query->query_vars[‘s’]) ) $pagination[‘add_args’] = array( ‘s’ => get_query_var( ‘s’ ) );
echo paginate_links( $pagination );
}
|
Мой метод цепочки был разработан с учетом этой функции. Использование WP PageNavi для нестандартной нумерации постов становится очень уродливым, поэтому я не буду показывать вам, как это сделать по той же причине, по которой друзья не позволяют друзьям пьянствовать. Пожалуйста. Но давайте перейдем к тому, к чему вы действительно пришли — наконец-то выяснив, как не допустить нумерацию пользовательских типов записей после 404 или всегда возвращаться к первой странице.
Шаг 2 Пользовательский тип архива Шаблон сообщения
Так как пользовательские типы записей не имеют своих собственных индексных страниц, и, как я уже говорил, я думаю, что шаблон archive-posttype.php является его заменой, в частности, потому что я использую его как основу для разбивки на страницы во всех других шаблонах. Многие разработчики будут сначала подчеркивать шаблон страницы как индексную страницу, но 1.) Я, очевидно, не согласен и 2.) мы вернемся к ним позже. Даже суперзвезда WordPress, Джастин Тэдлок , согласен с тем, что пользовательские типы сообщений должны иметь по крайней мере возможность использовать собственные индексные страницы .
К счастью, моя функция paginate () из коробки с шаблоном archive-posttype.php . Уф. Но проблема в том, что его разбиение на страницы связано с настройкой сообщений на странице в Настройки> Чтение . А поскольку пользовательские типы сообщений являются именно такими, пользовательские, в девяти случаях из десяти разработчик захочет, чтобы их сообщения на странице также были пользовательскими. Чтобы сделать это проще всего, я написал фильтр в functions.php следующим образом:
|
1
2
3
4
5
|
function portfolio_posts_per_page( $query ) {
if ( $query->query_vars[‘post_type’] == ‘portfolio’ ) $query->query_vars[‘posts_per_page’] = 1;
return $query;
}
if ( !is_admin() ) add_filter( ‘pre_get_posts’, ‘portfolio_posts_per_page’ );
|
Этот метод пришел ко мне через пост Джонатана Кристофера под названием « Сообщения WordPress на страницу на пользовательский тип сообщения» . Спасибо, Джонатан!
Что произойдет, если я не хочу, чтобы в моей структуре постоянных ссылок было то же имя, что и в моем пользовательском типе записи (например, http://company.com/portfolio/)? Я рад, что ты спросил. Это одна из причин, по которой разработчик предпочел бы шаблон страницы для отображения своих пользовательских типов записей. Это дает пользователю полный контроль над структурой постоянных ссылок, поскольку они могут просто изменить имя страницы, использующей этот шаблон страницы. Это понятно, и мы сделаем это в ближайшее время, но для тех из нас, кто не нуждается в этом или хочет другого пути в будущем, есть небольшая правка, которую мы можем сделать под капотом, чтобы подчинить эту структуру нашей воле.
Функция для создания пользовательского типа записи, register_post_type () , принимает аргумент, называемый rewrite. Значение этого аргумента передается в виде массива, и изменение значения слага будет изменять структуру постоянных ссылок. Вот пример:
|
1
|
‘rewrite’ => array( ‘slug’ => ‘insertyourpermalinknamehere’, ‘with_front’ => true ),
|
После того, как вы изменили это, перейдите в «Настройки»> «Постоянные ссылки» и нажмите кнопку «Сохранить изменения», чтобы сбросить кэш перезаписи. Посетите ваш сайт и обновите страницу, чтобы просмотреть изменения. Сделано и сделано. Опять же, единственный недостаток этого метода заключается в том, что пользователи, не обладающие техническими знаниями, не смогут изменить название своей структуры постоянных ссылок из интерфейса администратора, если, конечно, они не направляются в Редактор тем, чтобы изменить этот перезаписываемый фрагмент.
Шаг 3 Шаблоны страниц
Разработчики нередко отображают и разбивают на страницы свои пользовательские типы постов на статической главной странице с помощью шаблона страницы. Причина этого двоякая; это дает пользователю возможность изменять структуру имен постоянных ссылок, о которой мы только что говорили, и позволяет им отображать пользовательские типы сообщений на главной странице своего сайта. Но здесь все может быть ужасно. Мне стыдно сказать, что я однажды закодировал нумерацию пользовательских типов постов тремя разными способами в одной теме. Отчасти это происходит из-за использования WP PageNavi, но я признаю этот смущающий факт, чтобы подчеркнуть, что весь этот процесс может быть ошеломляющим для разработчиков тем, которые не в курсе дел.
Давайте назовем наш шаблон страницы page-portfolio.php, чтобы соответствовать соглашению об именах для пользовательских шаблонов типов записей, даже если оно не одно. Вот код:
|
1
2
3
4
5
6
7
8
9
|
/* Template Name: Portfolio */
$paged = 1;
if ( get_query_var(‘paged’) ) $paged = get_query_var(‘paged’);
if ( get_query_var(‘page’) ) $paged = get_query_var(‘page’);
query_posts( ‘&post_type=portfolio&paged=’ . $paged );
require_once( ‘archive-portfolio.php’ );
|
Это первый раз, когда вы видите шаблон archive-posttype.php, связанный с другим шаблоном. И это работает! Но что, черт возьми, происходит? Этот непонятный бизнес с переменными значениями $ paged подчеркивает точные проблемы, с которыми, похоже, сталкиваются разработчики, с настраиваемой нумерацией пост-типов. В основном, если это исправление (кашель) отсутствует, и пользователь нажимает, чтобы просмотреть страницу 2, как кто-то, кто был взволнован, WordPress запутывается и не знает, где он находится. И чтобы добавить оскорбление к ране, очевидно, WordPress знает об этом и принимает это как обычную процедуру разработки, публикуя эту заметку в разделе « Параметры пагинации» на странице Кодекса для WP_Query () :
Примечание о нумерации страниц: вы должны установить get_query_var (‘page’); если вы хотите, чтобы ваш запрос работал с нумерацией страниц. Начиная с WordPress 3.0.2, вы получаете get_query_var (‘page’) вместо get_query_var (‘paged’). Параметр разбивки на страницы «paged» для WP_Query () остается неизменным.
Для меня имеет смысл, что разработчики должны иметь возможность установить эту переменную и указать на конкретную страницу. Что не имеет смысла, так это то, что нумерация страниц по сути работает с типами записей по умолчанию (например, пост, страница, вложение), а не с пользовательскими.
Помимо необходимости исправления кода, здесь есть еще одна загвоздка, заключающаяся в том, что вы не можете называть свою страницу слагом тем же, что и ваш пользовательский тип сообщения слагом. Думайте о своем слаге типа поста как о зарезервированном ключевом слове; тем не менее, вы можете сделать заголовок вашей страницы таким же именем, как и ваш пользовательский слаг типа поста, при условии, что ваш слаг страницы отличается.
Шаг 4 Шаблон главной страницы
Использование шаблона front-page.php блокирует пользователей на пользовательской главной странице без возможности их изменения (если только они не удаляют файл или не переименовывают его временно). Вот почему большинство разработчиков выбирают метод Page Template для создания статических титульных страниц, но ради моего метода, допустим, мы используем первый. Чтобы добиться настраиваемой нумерации пост-типов для этого шаблона, все, что нам нужно, это просто включить то, что мы сделали для archive-posttype.php, вот так:
|
1
|
require_once( ‘page-portfolio.php’ );
|
Шаг 5 Пользовательские типы записей
Шаблон taxonomy-posttype-taxonomy.php работает почти так же, как шаблон front-page.php , но вместо того, чтобы включать шаблон page-portfolio.php , вместо этого вы включите наш индекс archive-posttype.php , как это:
|
1
|
require_once( ‘archive-posttype.php’ );
|
Это завершает степень моего метода. Там, где я когда-то стучал головой о стол в два часа утра, теперь я спокойно перебираю проекты в два часа дня. Победа! Ну, по крайней мере пока. Я не настолько наивен, чтобы думать, что я не могу оказаться в ситуации, когда этот метод не работает для нумерации пользовательских типов постов, но я еще не сделал этого.
Вывод
В отличие от других моих постов, я надеюсь, что этот пост устарел. Я надеюсь, что WordPress примет участие в недавнем опросе, который показывает, что 92% всех разработчиков используют WordPress в качестве CMS и еще раз посмотрят, как работает нумерация страниц на их платформе. Команда на WordPress — не что иное, как профессионал. Я представляю будущее, в котором есть встроенные инструменты разбивки на страницы и, возможно, пользовательская страница администратора с типом поста в разделе «Настройки» для администрирования постов на страницу для каждого типа поста. Но сейчас я надеюсь, что этот метод цепочки поможет многим разработчикам, которых я видел, страдающих на форумах WordPress . Пожалуйста, не стесняйтесь загружать, использовать и злоупотреблять следующими заархивированными файлами в качестве основы для успешной нумерации пользовательских типов записей. Наслаждайтесь!
Пользовательский тип метода постраничного разбиения на рамки (ZIP)