Кастомный тип записи по умолчанию использует index.php для архивной страницы.

Вопрос или проблема

Я разработал пользовательскую тему с пользовательским типом записи, названным events. Однако по какой-то причине WP отказывается использовать мой шаблон страницы архива с именем файла archive-events.php в соответствии с иерархией шаблонов WP. WP продолжает по умолчанию использовать index.php в качестве шаблона для этого типа записи.

Ранее у меня была страница, настроенная в WP, которая была установлена на слуг /events/, который теперь является слугом пользовательского типа записи. Эта страница теперь удалена, и я не знаю, является ли это проблемой, из-за которой WP отказывается использовать archive-events.php для моего списка архивов пользовательского типа записи. Я попытался изменить и сохранить структуру постоянных ссылок, но это не сработало. В настоящее время структура пермальных ссылок установлена на “Имя записи”, т.е. http://my.domain/post-name/.

Более подробная информация:

  • Я зарегистрировал пользовательский тип записи events (код ниже)
  • Слуг типа записи – “events”, и отдельные записи успешно отображаются по ссылке http://domain.com/events/post-name
  • Страница архива для типа записи доступна по /events/, но используется index.php, даже несмотря на то, что я создал шаблон архива для типа записи как archive-events.php
  • Чтобы подтвердить, какой шаблон WP использует для отображения страницы архива для пользовательского типа записи, я создал функцию, которая выводит $GLOBALS['current_theme_template'], используемый для рендеринга страницы. Это подтверждает, что WP использует index.php для рендеринга страницы архива.
  • В моем файле header.php я выводил функцию get_post_type_archive_link('events'), чтобы подтвердить, что WP считает, что страница архива для моего пользовательского типа записи должна быть http://domain.com/events/
  • Шаблоны archive.php и index.php WP отдаются как ожидается, но шаблон для пользовательского типа записи пропускается WP, независимо от обстоятельств
  • В качестве теста я переименовал мой существующий пользовательский тип записи на что-то новое, переназначил все свои запросы на этот CPT и обновил имена шаблонов соответственно. Тем не менее, WP отказывается использовать cpt-archive.php в качестве шаблона для пользовательского типа записи и вместо этого отдает либо archive.php, либо index.php.

Вот мой код в functions.php для регистрации типа записи:

function registerEvents()
{
    $labels = array(
        'name'                  => _x( 'События', 'Общее название типа записи', 'textdomain' ),
        'singular_name'         => _x( 'Событие', 'Сигнальное название типа записи', 'textdomain' ),
        'menu_name'             => _x( 'События', 'Текст админ-меню', 'textdomain' ),
        'name_admin_bar'        => _x( 'События', 'Добавить новое в панели инструментов', 'textdomain' ),
        <snip>
    );
    $args = array(
        'labels'                => $labels,
        'public'                => true,
        'hierarchical'          => false,
        'publicly_queryable'    => true,
        'exclude_from_search'   => false,
        'show_ui'               => true,
        'show_in_menu'          => true,
        'show_in_rest'          => false,
        'menu_position'         => 5,
        'menu_icon'             => 'dashicons-calendar-alt',
        'capability_type'       => 'post',
        'has_archive'           => true,
        'query_var'             => true,
        'delete_with_user'      => false,
        'supports'              => array( 
            'title',
            'editor',
            'excerpt',
            'thumbnail',
            'page-attributes'
        ),
        'taxonomies'            => array( 'kind' ), // Пользовательская таксономия, ранее зарегистрированная
        'rewrite'               => array( 'slug' => 'events', 'with_front' => false ),
    );
    register_post_type( 'events', $args );
}
add_action( 'init', 'registerEvents' );

Решение этой проблемы оказалось следующим:

  • Изменение названия пользовательского типа записи с “events” (со слугом /events/) на “event” (со слугом /event/)
  • Создание страницы с пользовательским шаблоном со слугом /events/ для отображения архивов пользовательского типа записи

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

На протяжении всего процесса я использовал wp-cli для очистки внутреннего кеша WP и удаления всех временных данных, но это не дало результата.

Если вы регистрируете типы записей вручную (в отличие от использования CPT UI или чего-то подобного), вам нужно помнить, что следует перейти в настройки > постоянные ссылки и просто нажать ‘Сохранить’. Это пару раз сбивало меня с толку.

Ответ или решение

Почему архивный шаблон кастомного поста "events" используется как index.php

В процессе разработки темы WordPress с кастомным постом "events" вы столкнулись с проблемой, связанной с тем, что архивная страница для вашего кастомного поста не отображает ожидаемый шаблон archive-events.php, а вместо этого используется универсальный шаблон index.php. Это распространенная проблема, с которой разработчики WordPress могут столкнуться, и в этом ответе мы рассмотрим возможные причины и решения данной ситуации.

1. Основы шаблонной иерархии WordPress

WordPress использует шаблонную иерархию для определения, какой файл шаблона должен быть использован для рендеринга конкретного контента. Для кастомных постов, если у вас зарегистрирован пост типа с архивом и его слагом, ожидается, что WordPress будет использовать файл archive-{post_type}.php (в вашем случае archive-events.php) для отображения архивной страницы.

2. Проверка регистрации кастомного поста

В приведенном коде для регистрации поста можно увидеть, что параметры задаются корректно:

  • 'has_archive' => true — это ключевой параметр, который указывает, что для данного кастомного поста существует архивная страница.
  • 'rewrite' => array( 'slug' => 'events', 'with_front' => false ) — данный параметр определяет слаг для архивной страницы.

Убедитесь, что функция register_post_type() выполнена во время хука init, как это сделано в вашем коде:

add_action( 'init', 'registerEvents' );

3. Удаленные страницы и конфликты

Как вы уже заметили, ранее существовала страница с адресом /events/. Если данная страница была настроена и использовалась, это потенциально могло создать конфликт с регистрацией кастомного поста. В WordPress при удалении страниц и последующем изменении структуры ссылок могут оставаться кэши, которые мешают обновлению адресов и сворачивают работу пагинации.

Ваша попытка перезаписать структуру постоянных ссылок — это хороший шаг. Помните, что иногда полезно просто перейти в раздел «Постоянные ссылки» и снова нажать «Сохранить изменения», чтобы сбросить кэш и обновить правила.

4. Проверка конфликтов с другими плагинами или темами

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

5. Проверка и отладка

С помощью функции, выведенной в вашем коде, вы уже подтвердили, что используется index.php. Для дальнейшей проверки вы можете задействовать инструменты отладки, такие как debug_backtrace() или использовать плагин Query Monitor для специалистической отладки.

6. Альтернативное решение

На основании вашего опыта, вы нашли обходной путь, изменив название кастомного поста на "event" с слагом /event/. Это действительно позволяет избежать проблемы. Если данный вариант вас устраивает, рассмотрите возможность создания временной страницы с адресом /events/, где вы можете выводить архивные данные кастомного поста через пользовательский шаблон.

Заключение

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

Оцените материал
Добавить комментарий

Капча загружается...