Views в Drupal: как строить быстрые и предсказуемые списки

В Drupal Views можно за час собрать каталог материалов, список товаров или редакторский отчёт, но результат часто ломается на очевидных вещах: связь дублирует строки, фильтр скрывает нужные записи, а страница с десятью элементами отправляет в базу тяжёлый запрос. Ниже — практический порядок работы с Views в Drupal 10 и 11: как выбрать основу представления, где использовать обычные и контекстные фильтры, как ловить дубли и что проверить перед публикацией.

Начинайте не с экрана Views, а с результата

Views строит запрос к сущностям Drupal — материалам, пользователям, терминам таксономии или другим типам данных. Поэтому первый вопрос звучит не «какой фильтр нажать», а «одна строка результата чему соответствует».

Для каталога это обычно один материал или один товар. Для списка авторов — один пользователь. Если в представлении одновременно нужны материал и несколько связанных терминов, количество строк может вырасти: одна запись материала появится столько раз, сколько у неё подходящих терминов.

До настройки зафиксируйте четыре вещи:

• какой тип сущности лежит в основе списка;
• какое поле уникально идентифицирует строку и будет ссылкой на объект;
• кто увидит страницу и какие записи ему нельзя показывать;
• какие параметры посетитель задаёт сам, а какие приходят из URL или контекста страницы.

Это экономит время: Views не придётся переделывать после обнаружения, что список строился от терминов, а не от материалов.

Четыре приёма, которые определяют качество представления

1. Выбирайте базу по смыслу строки

При создании View Drupal предлагает тип данных, например Content или Users. Выбирайте тот тип, который должен появляться в результате по одному разу. Для ленты публикаций это Content, а не Taxonomy terms. Для страницы авторов — Users, даже если в карточке нужно показать связанные материалы.

Сразу добавьте поля, которые действительно выводятся: заголовок, дату, изображение, ссылку, статус публикации. Поля, нужные только для фильтрации, не обязательно показывать пользователю.

2. Разделяйте фильтры по назначению

Фильтр ограничивает выборку по постоянному правилу. Например, опубликованный материал типа Article. Такой фильтр должен быть в каждом display, который не должен показывать черновики.

Открытый фильтр передаёт управление посетителю. Он подходит для поиска по заголовку, выбора раздела или диапазона дат, но не заменяет проверку доступа.

Контекстный фильтр получает значение из контекста — чаще всего из аргумента URL, ID пользователя или текущего термина. Он удобен для страницы автора или раздела: один display обслуживает много адресов, вместо отдельного View для каждого раздела.

Не превращайте один экран в универсальный конструктор со всеми возможными полями. Чем больше условий и связей, тем труднее понять, почему конкретная запись исчезла.

3. Добавляйте связи только для конкретного поля

Relationship позволяет обратиться из основной сущности к связанной: от материала к автору, от заказа к пользователю, от товара к термину. Но каждая связь может изменить SQL-запрос и увеличить число строк.

Если связь нужна только для фильтра, не выводите её поля без необходимости. Если одна основная запись повторяется, сначала проверьте, не добавили ли вы связь с многозначным полем. Опция агрегации может убрать дубли, но она меняет запрос и способ группировки, поэтому включать её вслепую нельзя.

4. Настраивайте display как независимый контракт

У View может быть страница, блок, feed и другие display. Они используют общую основу, но настройки фильтров, сортировки, пагинации и доступа могут отличаться. Проверьте, не наследует ли новый display лишнее условие от базового.

Практичный минимум для публичной страницы:

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

Что выбрать: обычный, открытый или контекстный фильтр

Когда что выбирать

Выбирайте обычный фильтр, если условие относится к самой модели данных и не меняется от посетителя к посетителю. Открытый фильтр нужен, когда пользователь действительно знает, что искать: строка поиска, категория, дата. Контекстный фильтр лучше подходит для маршрутов вроде страницы автора или раздела, где значение уже есть в адресе.

Если фильтров становится больше пяти, вынесите часть логики в отдельные display или пересмотрите модель данных. Views не должен компенсировать неясную структуру контента.

Главная проверка Views — не то, что список появился на экране, а то, что каждая строка означает ровно одну нужную сущность.

Что ломается чаще всего

Дубли строк

Самая частая причина — связь с многозначным полем: несколькими терминами, изображениями или связанными объектами. Откройте предварительный просмотр, добавьте идентификатор основной сущности и сравните повторяющиеся строки. Если связь нужна только для ограничения выборки, проверьте настройки, которые не выводят связанные поля и не размножают результат.

Пустой результат после добавления фильтра

Проверьте, к какой сущности относится поле, активен ли нужный display и не требует ли фильтр обязательного значения. Контекстный фильтр также может получать аргумент не из того сегмента URL. Для теста временно задайте конкретное значение по умолчанию и сравните результат.

Черновики видны посетителю

Убедитесь, что в View есть условие публикации и что просмотр сущности разрешён текущей роли. Сам факт, что редактор видит запись в административном интерфейсе, не означает, что её должен видеть анонимный пользователь.

Список работает, но страница тормозит

Сначала включите логирование запросов на тестовой среде и посмотрите, какой View выполняется дольше всего. Затем уменьшите число полей, уберите ненужные связи, ограничьте количество результатов и проверьте пагинацию. Не делайте вывод о производительности по одному локальному просмотрю: замеряйте на объёме данных, близком к рабочему, и с той же ролью пользователя.

Изменения не видны сразу

Причиной может быть кэш View или кэш страницы. Для диагностики временно сократите время кэширования на тестовой среде, а после проверки верните рабочую стратегию. Полностью отключать кэш на продакшене как постоянное решение не стоит.

Проверка перед публикацией

1. Откройте страницу гостем и пользователем с минимальной нужной ролью.
2. Проверьте пустой результат, одну запись, много записей и страницу за пределами последней страницы.
3. Добавьте сущность с несколькими значениями многозначного поля и убедитесь, что она не дублируется без причины.
4. Проверьте URL с отсутствующим, неверным и корректным контекстным аргументом.
5. Сравните результат в каждом display, особенно если блок и страница используют один View.
6. Измерьте запрос на тестовой копии базы и отдельно проверьте, не раскрывает ли список запрещённые поля.

Сноска. Display — отдельное представление одного View: например, страница или блок со своими настройками вывода. Relationship — связь с другой сущностью, через которую Views получает поля и условия фильтрации.

Что делать дальше

После публикации поставьте в мониторинг время ответа страницы, количество строк в результате и долю пустых ответов по контекстным URL. При росте базы повторите замер на копии production-данных, а не на демонстрационном сайте. Следующим шагом обычно становится аудит связей и фильтров: именно они чаще всего превращают простой список в дорогой запрос.