Пользовательские типы записей не выделяются в меню навигации
Работа на сайте театральных мероприятий. Структура требует нескольких отдельных областей событий, каждая с верхней страницей, на которой перечислены события в определенной области, и соответствующими отдельными страницами событий под страницей списков. Поскольку каждая из страниц области событий требует различной обработки, я подумал, что это хорошая ситуация для пользовательских типов сообщений, использующих как шаблоны с одним [событием], так и с архивом[событие] для каждой области.
Я установил пользовательский интерфейс пользовательских типов записей, чтобы создайте пользовательские типы записей (включая соответствующую пользовательскую таксономию) и Расширенные пользовательские поля для создания мета-полей. Пока все хорошо. Тип настраиваемой записи архива (полный список событий области) извлекает метаданные из одного типа настраиваемой записи, и обе страницы настраиваемой записи отображаются правильно, за исключением одного: главное навигационное меню больше не выделяет активную веб-страницу в списке архивов. [Примечание: есть много сообщений о том, как выделить отдельные пользовательские сообщения в подменю, чтобы они соответствовали родительским; Мне это не нужно, просто нужно, чтобы текущая область событий была правильно выделена в главном меню навигации!]
Я понял, что создал свою основную навигацию, которая включает области событий, с помощью wp_nav_menu и register_nav_menus. Таким образом, области событий, соответствующие пользовательским записям архива, изначально были созданы в виде Страниц, а основная навигация была настроена с помощью функции перетаскивания в меню WP. Wordpress правильно использует по умолчанию пользовательский шаблон записи archive-[событие] (и игнорирует существующую страницу с тем же именем), а навигационное меню функционально с точки зрения ссылок, но не выделяет ссылку на пользовательскую публикацию архива в навигаторе. Страницы в основной навигации работают правильно.
Когда я проверяю вывод в области событий, к навигации блога прикреплен класс "current_page_parent", но в другом месте нет "пункта текущего меню", который, я полагаю, подходит для пользовательских сообщений. Я полагаю, что если wp_nav_menu предназначен только для страниц, это имеет смысл, так как архивные записи верхнего уровня не будут распознаны, но я понятия не имею, как это исправить. Я собираюсь попробуйте хаки, но по возможности избегайте специфичных для идентификаторов или jQuery. Одной из идей было бы отказаться от шаблона архив-[событие] и использовать обычный шаблон страницы для списка, сохраняя при этом сообщение пользовательского типа с одним [событием]. Есть ли причина, по которой притворство таким образом не могло сработать? Спасибо за любой совет, надеюсь, мне не хватает очевидного/простого подхода.
3 answers
Я всегда считал это ошибкой, но если нет, то это довольно неприятно. Вам нужно исправить 2 вещи: во-первых, не выделять элемент верхнего уровня "Блог", а во-вторых, выделить соответствующий элемент верхнего уровня, под которым находится ваш отдельный CPT.
Могут быть и другие методы, но я поделюсь своим методом, который, к сожалению, нацелен на идентификаторы меню с помощью CSS.
В контейнер навигации добавьте условие, определяющее, когда навигационная система отображается на единый CPT:
<nav class="navsf<?php if (is_singular('news')) { echo ' fixhilite'; } ?>">
Затем вам нужно будет получить идентификаторы для пункта меню "Блог" и для родительского пункта меню CPT (в данном примере "Новости"). Допустим, для "Блога" это следующее:
<li id="menu-item-29" ...>
А для "Новостей" это:
<li id="menu-item-30" ...>
В вашем CSS вы можете настроить эти элементы таким образом, чтобы изменить цвета текста или фона, чтобы соответственно выделить/отменить выделение:
.navsf.fixhilite li#menu-item-29
.navsf.fixhilite li#menu-item-30
Ваша проблема, вероятно, решена уже давно. В любом случае, вот майское решение:
public static function WPFilter_UpdateNavMenuCSS($classes, $item) {
$pages = get_posts ( array (
'post_type' => 'page',
'meta_key' => '_wp_page_template',
'meta_value' => 'page-works.php' ) );
if (is_array ( $pages ) && count ( $pages ) > 0) {
$root_page = $pages [0];
if (is_singular ( self::id )) {
if (( int ) $root_page->ID == ( int ) $item->object_id) {
$classes [] = 'current_page_parent';
} else {
$key = array_search ( 'current_page_parent', $classes );
if ($key) {
unset ( $classes [$key] );
}
}
}
}
return $classes;
}
Просто измените этот метод в соответствии с вашими потребностями. Вы должны заменить page-works.php и я: идентификатор соответственно.
Для следующего вам необходимо зарегистрировать фильтр для вызова метода, определенного выше:
add_filter ( 'nav_menu_css_class', 'SimpleTheme\PostType\Portfolio::WPFilter_UpdateNavMenuCSS', 10, 2 );
Для этого решения требуется, чтобы у вас был пользовательский шаблон страницы для отображения списка вашего пользовательского типа публикации, и этот шаблон выбран для страницы, которую вы хотите определить как родительскую страницу.
Я предлагаю использовать jQuery, например:
<?php if(is_singular('your-custom-post-type')) : ?>
<script>
(function($) {
$(document).ready(function() {
$('#menu-item-20').addClass('current-menu-item');
});
})(jQuery);
</script>
<?php endif; ?>
Готово.