я использую Меню перехода к представлениям с друпал 9.
Узлы помечены Версия ПО иерархическая таксономия по следующему образцу:
âââ фу
âââ 0.1.0
âââ 0.2.0
ââ бар
âââ 0.3.0
â âââ 0.3.1
âââ 0.4.0
âââ баз
âââ 0.1.0
âââ 0.2.0
— 0.3.0
План состоит в том, чтобы узлы пользовательского типа контента были помечены дочерним термином из приведенного выше списка (числовые значения), создавая список переходов, содержащий только узлы, помеченные родственными терминами, которые имеют одного и того же родителя (т. е. только документацию). страницы для разных версий одного и того же программного обеспечения).
Под /admin/структура/представления/представление/taxonomy_jump_menu/изменить, есть блочное отображение представления, которое в настоящее время возвращает весь словарь таксономии со всеми родительскими и дочерними элементами. Другими словами, меню перехода содержит ссылки на документацию для всех версий различного программного обеспечения.
Я надеялся, что в представлениях есть способ добавить контекстный фильтр, который мог бы определить термин таксономии TID текущего узла из URL-адреса, использовать его для определения непосредственного родительского TID TID (из которого должен быть только один) и создать меню перехода, содержащее все дочерние элементы родительского TID, за исключением самого родительского термина.
Конфигурация для этого представления состоит из сотен строк YAML, но вот выдержка (много ненужных строк удалено, но отступы сохранены):
зависимости:
конфигурация:
- таксономия.словарь.версия_программного обеспечения
модуль:
- таксономия
- пользователь
- views_jump_menu
идентификатор: таксономия_jump_menu
label: 'Меню перехода по таксономии'
модуль: просмотры
описание: ''
тег: ''
base_table: таксономия_term_field_data
base_field: прилив
отображать:
По умолчанию:
Показать варианты:
запрос:
тип: views_query
стиль:
тип: jump_menu
строка:
тип: поля
поля:
parent_target_id:
идентификатор: parent_target_id
таблица: таксономия_term__parent
поле: parent_target_id
отношения: нет
тип_группы: группа
исключить: правда
прилив:
идентификатор: прилив
таблица: таксономия_term_field_data
поле: прилив
отношения: нет
тип_группы: группа
исключить: ложь
изменить:
изменить_текст: правда
текст: '/taxonomy/term/{{ tid }}'
имя:
идентификатор: имя
таблица: таксономия_term_field_data
поле: имя
отношения: нет
тип_группы: группа
исключить: ложь
фильтры:
положение дел:
значение: «1»
таблица: таксономия_term_field_data
поле: статус
plugin_id: логический
entity_type: таксономия_термин
поле_объекта: статус
идентификатор: статус
разоблачать:
оператор: ''
operator_limit_selection: ложь
список_операторов: { }
группа 1
видео:
идентификатор: видео
таблица: таксономия_term_field_data
поле: видео
стоимость:
версия_программного обеспечения: версия_программного обеспечения
entity_type: таксономия_термин
поле_объекта: видео
plugin_id: пакет
разоблачать:
operator_limit_selection: ложь
список_операторов: { }
группа 1
сортирует: { }
title: 'Меню перехода по таксономии'
отношения: { }
аргументы: {}
группы_фильтров:
оператор: И
группы:
1: И
Есть много других источников, но я пытаюсь включить только существенные детали!
Я не думаю, что этот вопрос имеет дублирующийся ответ на этом форуме. Самое близкое, что я нашел, это этот вопрос который относится к меню, а не к таксономии (хотя, возможно, моя проблема в том, что я должен использовать здесь меню таксономии), и этот нерешенный вопрос который не содержит достаточно подробностей, чтобы понять, является ли он актуальным.
Я также проверил очереди задач для модуля contrib, но это действительно кажется ограничением самих представлений, которые находятся в ядре.
я пытался добавить Настроить контекстный фильтр: Термин таксономии: Родительский термин к представлению, но это неожиданно создает меню перехода, содержащее Только родительские термины:
âââ фу
ââ бар
âââ баз
На данный момент я начинаю думать, что будет намного проще написать реализацию ловушки, которая будет изменять запрос, но это сложная тема для исследования в Интернете. (Мои поисковые запросы выдают много нерелевантных очередей задач, восходящих к Drupal 5.)
Итак, чтобы свести все это к ответу на вопрос, что реализация хука лучше всего подходит для этой задачи?
я склоняюсь к использованию hook_views_query_alter() изменить $запрос сам объект (внутри $ запрос-> где) на основе этот комментарий, но я в довольно глубокой воде здесь.
