Сложные взаимосвязи и контекстные фильтры. Возможно ли?

20 сентября 2020 в 14:53

Есть тип материала «Клиника» (список больших сетевых клиник). Есть тип материала «Клиника в городе» (адрес клиники в конкретном городе), которая через поле Entity Reference «Название клиники» ссылается на материал «Клиника». Есть тип материала «Услуга клиники» (МРТ, УЗИ, Рентген и т.д.), которая тоже через поле Entity Reference «Название клиники» ссылается на материал «Клиника». Все эти типы материала имеют общий словарь таксономии «Название клиники».

Есть еще один тип материала «Услуга в городе», который, как и «Клиника в городе», имеет термин таксономии «Город». Схема на картинке.

Необходимо, чтобы при создании материала «Услуга в городе» (УЗИ в Калиниграде), на странице выводился блок Views с услугами УЗИ клиник, которые находятся в этом городе.

У меня не получилось через контекстные фильтры Has taxonomy term ID и взаимосвязи вывести услуги. Не понимаю пока, как связать в представлении услуги клинии с городом. Какие будут версии? Спасибо.

Комментарии

"Необходимо, чтобы при создании материала"
именно при создании или вывести на странцие возданного материала?
Если 2-е, то viewftield и views_field_view должны помочь. Но вот по схеме я не соображу что к чему.

21 сентября 2020 в 20:31

Вывести на странице созданного материала.
По схеме указано какие типы материалов связаны между собой через Entity Reference и термины таксономии, где мат. -- материалы, такс. -- термины таксономии, стрелочки -- Entity Reference поля. По модулям посмотрю, спасибо.

22 сентября 2020 в 13:35

Посмотрел эти модули, но не понял, чем они мне могут помочь. У меня не стоит проблема как вывести блок в ноде, у меня проблема как правильно сформировать этот блок. Чтобы в блоке выводились услуги клиник, которые есть в конкретном городе. А услуги клиник, которых нет - не выводились. При этом услуги и города между собой не связаны никакими полями или терминами, как на схеме.

22 сентября 2020 в 22:04

На странице города список клиник можете вывести? Вот в этом списке вместо поля названия клиники выведите услуги, которые она предоставляет. А чтоб не повторялись или группировку применять или какой-то хитрый контитриб.

22 сентября 2020 в 22:53

На странице города список всех клиник могу вывести, связав это через RELATIONSHIPS поле Название Клиники: Entity Reference и отфильтровав контекстным фильтром по термину таксономии Город. Я получу список клиник в конкретном городе. Например:
Клиники в Калининграде
Василек
Ромашка
..............
Но услуги (МРТ, УЗИ...) - это отдельные типы материалов. Как я могу продолжить связь, чтобы получить такой список?
Пример:
МРТ в Калининграде
МРТ от клиники Василек (ссылка на услугу)
МРТ от клиники Ромашка (ссылка на услугу)
...............

23 сентября 2020 в 0:17

Если надо:
МРТ от клиники Василек (ссылка на услугу)
МРТ от клиники Ромашка
значит нет проблем.

Услуга она к клинике ведь привязана? Значит вы можете сделать еще одну связь по полю ссылки на услуг от клиники.

"МРТ в Калининграде" - это уровень группировки в настройках списка views.

23 сентября 2020 в 2:00

Прикол, всё точь в точь, как в соседней теме. И точно так же, как в соседней теме, здесь как минимум одно поле таксономии лишнее - таксономия "Название книги" не нужна. Как я вижу структуру:
1. Тип ноды "Клиника", которая сеть.
2. Тип ноды "Филиал клиники", у него связь через Entity Reference на клинику из первого пункта.
3. Словари таксономии "Услуги" и "Города".
4. Материал "Услуга в городе" можно и не создавать, я обычно такие страницы делаю через вьюху с двумя аргументами, но если хотите материал, то пожалуйста.

Настройки вьюхи для вывода клиник по услуге и городу будут такие:
- вывести тип материала "Филиал клиники"
- Контекстный фильтр по городу. В него передать значение по умолчанию "ID термина таксономии из URL" и обязательно поставить галочку "загрузить значение аргумента со страницы материала", а аналогичную галочку для термина таксономии убрать.
- Контекстный фильтр по услуге - то же самое.
Всё.

PS: Таксономию "Название клиники" в принципе можно и оставить, она тут не мешает, хотя факт, что она не нужна.

23 сентября 2020 в 9:35

Всем спасибо за участие в обсуждении темы. Вчера методом экспериментов пришел к такому решению своего вопроса. Структура материалов и связи без изменений, поскольку они уже есть и там тысячи опубликованных страниц.
- Тип материала: Клиника в городе.
- CONTEXTUAL FILTERS: Has taxonomy term ID, Load default filter from node page, that's good for related taxonomy blocks, выбираем словарь Город.
- а) Добавляем RELATIONSHIPS: Entity Reference: Referenced Entity
- б) Добавляем RELATIONSHIPS: Entity Reference: Referencing Entity и делаем Relationship на а)
Все нужные на поля (название услуги, цена, описание...) делаем с Relationship б)
- Подстраиваю под себя FILTER CRITERIA, чтобы не выводились лишние типы материалов
Получаем блок, который выводит нужную нам услугу всех клиник которые есть в конкретном городе.
Выглядит сложно, еще не знаю как будет по запросам к БД, но результат как я хотел.

23 сентября 2020 в 11:11

gun_dose wrote: Таксономию "Название клиники" в принципе можно и оставить, она тут не мешает

Если не считать того, что:
- при создании новой клиники надо не забыть одновременно создать и материал, и термин
- при удалении клиники надо не забыть удалить и материал, и термин
- при редактировании клиники (например смена названия) нужно не забыть отредактировать и материал, и термин
Действительно совершенно не мешает Wink

23 сентября 2020 в 15:45

Термин здесь создается при создании материала, это поле тег. Под эту таксономию еще много чего подвязано. Остальные пункты бывают настолько редко, что не создают никаких проблем.

23 сентября 2020 в 15:57

buldozer_kpi wrote: Термин здесь создается при создании материала, это поле тег

То есть при создании материала Клиника нужно не забыть продублировать поле Название в поле тег? А при удалении Клиники (ну закрылась - с кем не бывает) термин так и останется висеть в базе навечно и светиться во всех списках и подсказках?

buldozer_kpi wrote: Под эту таксономию еще много чего подвязано.

Именно это и называется ошибкой проектирования.

buldozer_kpi wrote: Остальные пункты бывают настолько редко, что не создают никаких проблем.

Это никак не оправдывает негодного проектирования.

23 сентября 2020 в 16:06