Фасетный (?) фильтр товаров.

Аватар пользователя lo_sinclair lo_sinclair 29 января 2017 в 1:35

Добрый день.
Задача: сделать фильтр для магазина, наподобие того, что в яндекс-маркете.
Так, чтобы при выборе одних параметров, другие параметры скрывались или становились неактивными.
Для примера, выбираем монитор: есть фильтр по цене (от - до) и по размеру диагонали (чекбоксы)
1) 17 д. [ ]
2) 19 д. [ ]
3) 27 д. [ ]
Выбираем цену до 7000 - 2-й и 3-й чекбокс становится неактивным, т.к. нет мониторов с диагональю больше 17 дюймов и стоимостью <= 7000

Не имею опыта с facet search, но, скорее всего должен использоваться должен именно этот вариант. Во Views Exposed filter нет возможности отфильтровать ненужные значения. Вопрос в том, что в магазине мне нужно брать поля из двух сущностей Product и его дисплей, и по ним делать фильтр, наподобие того как во Views можно добавить связь Product - product display и вытянуть нужные поля. Есть ли готовые решения, как это сделать с помощью фасетов?
Если нет, то что получится быстрее в разработке, помучать exposed filter или фасеты?
Спасибо.

Комментарии

Аватар пользователя lo_sinclair lo_sinclair 29 января 2017 в 18:29

Понятно, что надо привыкать к фасетам, но первый случай мне и ваш совет пригодится. Smile

Аватар пользователя gun_dose gun_dose 29 января 2017 в 11:40

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

Аватар пользователя lo_sinclair lo_sinclair 29 января 2017 в 18:30

Просмотр мануалов не дал мне как раз представления, можно ли связать поля двух сущностей. Везде рассматривался индекс по материалу.
Возможно, я недостаточно долго в них копаюсь.

Аватар пользователя adubovskoy adubovskoy 29 января 2017 в 11:47

Если что - есть готовый solr-хостинг для этого дела, http://www.ra-don.ru/solr-hosting . Там же могут помочь и с настройкой фасетов если есть необходимость.
Делать фасеты поверх mysql не очень хорошая затея, да, есть https://www.drupal.org/project/search_api_db , но это если у вас товаров мало, вариантов мало. Если за тысячу товаров и куча фильтров - нужен solr или elastic .

Аватар пользователя lo_sinclair lo_sinclair 29 января 2017 в 18:30

Проект пока не такого масштаба, чтобы прибегать к помощи solr-хостинга. Но учту на будущее.

Аватар пользователя tmp tmp 29 января 2017 в 13:26

А кто объяснит зачем такой тяжелый модуль использовать для такой тривиальной и простой задачи? В чем преимущества? Еще и использовать отдельный сервер... И можно ли при такой реализации организовать вывод фильтров с множественным выбором с чекбоксами?

Аватар пользователя gun_dose gun_dose 29 января 2017 в 13:29
1

Магазин на 10000 товаров, 100 категорий и 30 фильтров - задача действительно тривиальная. Но обычный вьюс с раскрытыми фильтрами её уже не тянет. А фасеты даже на сёч апи дб, без всяких солров и эластиков уже дают прирост производительности в разы.

Аватар пользователя tmp tmp 29 января 2017 в 13:45

Дада! Благодарю за ответ. К вопросу о тривиальности - то сейчас большинство магазов с большим ассортиментом Wink
А вот насчет роста производительности - это большой плюс! Что раньше не навели на этот модуль? Я там в соседних темах как раз интересовался ))) Уже свой код понаписывал!))) Кста - уже даже прикрутил jquery для сброса группы фильтров выводимых в отдельном блоке. ))) Вчера весь день убил. А тут смотрю можно все это реализовать фасетами!
Насколько я понял из описания в интернете - то можно организовать и множественный выбор. Ща буду пробовать! Спасибо.

Аватар пользователя multpix multpix 29 января 2017 в 14:01
1

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

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

видео выше - просто пинок в нужном направлении,
смотрите, читайте доки https://www.drupal.org/node/1250878
изучите таблицу вариантов бэкенда https://www.drupal.org/node/1254698

если у вас планируется нагрузка - тут солр без вариантов на первом месте.

на нашем форуме(и не только) есть хорошие материалы по серч апи и солр, используйте поиск)
https://www.google.com/search?q=drupal.ru+solr
https://www.google.com/search?q=drupal.ru+search+api

Аватар пользователя tmp tmp 29 января 2017 в 14:06

Благодарю! Кажется как раз то что надо! Вот черт... а я с фильтрами иьюса возился всю недели добавляя свои костыли и дополнительные модули модернизируя! ))) Жесть. теперь на фасеты надо весь сайт перевести. Хорошо что версия в бекапе осталась без этих всех модулей . )))

От самых трудных решений к самому простому... ))) Вот почему так у меня происходит? Нахожу когда решение самым трудным путем - находится тут же самый легкий )))

Аватар пользователя lo_sinclair lo_sinclair 29 января 2017 в 18:43

Спасибо за ответы! Вникаю в суть.

Мне на самом деле нужно самое быстрое решение на данный момент.
Насчет "тривиальности", я думаю, tmp имел в виду популярность задачи, любой мелкий магазин на запуске нуждается в подобных функциях ) Так что мне тоже показалось, что должно быть все проще и с готовыми решениями.

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

Если не сложно, может быть, найдется пример, где используется facet search со связью двух сущностей? (Поиск по полям товара и его дисплея одновременно ) Насколько я понимаю, выборки-связи это вообще не к фасетам, их главная функция поиск и индексирование.

Аватар пользователя gun_dose gun_dose 29 января 2017 в 19:42
1

В настройках полей индекса жмите снизу "добавить связанные поля", там будет всё.

Аватар пользователя tmp tmp 29 января 2017 в 20:15

Да! Все работает как надо! Этож надо! Неделю промучился с вьюсными фильтрами, а тут за пол дня все готово! Эх.. столько времени потерял Sad

Единственный остался вопрос:
При множественном выборе чекбоксами выбор происходит при каждом клике по чекбоксу. Кто то настраивал так чтоб отключить эту функцию а применять фильтр по кнопке "применить" ? То есть сделал выбор нескольких чекбоксов и потом уже нажимаешь "применить"? Или это уже все таки придется самому допиливать? Smile

Аватар пользователя multpix multpix 29 января 2017 в 20:22

В этом простом случае последовательность позволяет избежать недопустимого выбора.
Так-же при каждом применении фильтра идет пересчет кол-ва результатов.

Попробуйте аякс - может так будет веселей)

Аватар пользователя gun_dose gun_dose 29 января 2017 в 20:34

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

Аватар пользователя multpix multpix 29 января 2017 в 20:24
1

lo_sinclair wrote:

Просмотр мануалов не дал мне как раз представления, можно ли связать поля двух сущностей.

Просто просмотрите внимательно видео из моего комента выше.
На 2:00 в индекс добавляют поля связанных сущностей.

Этот скринкаст полностью описывает тривиальную часть настройки связки search_api search_api_db facetapi

В простых случаях этого достаточно - дальше доки, коих завались, и сюда на форум с конкретными вопросами)

Аватар пользователя tmp tmp 29 января 2017 в 20:35

multpix wrote:

В этом простом случае последовательность позволяет избежать недопустимого выбора.

Так-же при каждом применении фильтра идет пересчет кол-ва результатов.
Попробуйте аякс - может так будет веселей)


Спасибо Smile Так понимаю ни кто не решал этот вопрос Smile
Не пойму связи - с множественным применением фильтра и "недопустимого" выбора. )
Если есть к продукт с атрибутами 3-ех фильтров, а второй продукт с 4-мя, то будет как раз доступно эти 4 значения. Если выбираем 4 значения, то в запросе к БД и будет передано 4 значения сразу. Первый продукт отфильтровывается и выводится только второй. То есть пока не вижу "недопустимости". Ща начнем что то думать Smile

Аватар пользователя gun_dose gun_dose 29 января 2017 в 20:44
1

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

Аватар пользователя tmp tmp 29 января 2017 в 20:36

gun_dose wrote:

фасеты по сути не галки и не кнопки, а ссылки, поэтому по клику происходит переход.


Вот блин... а вот это проблема.

Аватар пользователя tmp tmp 29 января 2017 в 20:55

gun_dose wrote:

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


Так ведь правильно. Красных же нет. Вполне релевантный ответ. Smile
Нужны жигули - вибираем "жигули" и видим какие есть жигули.
Просто много общался с пользователями - всех бесит при выборе одного значения перезагрузка всей страницы. Меня к стати тоже Smile

Аватар пользователя gun_dose gun_dose 29 января 2017 в 21:39

Это не правильно. Когда фильтров много, юзер может потратить до 10 минут, чтобы вдумчиво раскинуть галки, а на выходе получит с большой долей вероятности пустоту. А чтобы перезагрузка не бесила, есть ajax facets, а ещё нужно принять меры по нормальной скорости отклика сайта.

Аватар пользователя tmp tmp 29 января 2017 в 21:44

Лан, это все вопросы философии и дизайна Wink
Решение почти нашел. Правда в dev версии. Почти все получается. Осталась проблема - нужно некоторые фасеты выводить в одном блоке. Это возможно? Smile

Аватар пользователя lo_sinclair lo_sinclair 30 января 2017 в 1:13

Спасибо большое! Видео и правда помогло разобраться!
Осталась только одна проблема, поиск прекрасно работает с нодами, а когда я в качестве Entity type выбираю Commerce Product - не ищет даже по заголовку. Или это я что-то не догоняю на ночь глядя.

Аватар пользователя multpix multpix 30 января 2017 в 1:33

Это отдельная тема - организация связки product и product_display в commerce.
Вы столкнетесь с таким вопросом как права не привилегированных ролей для просмотра полей сущности product.

Пока не разобрались на собственном опыте(после этого можно усложнить как угодно), пользуйте следующий принцип:
На стороне продукта должны быть поля необходимые для складского и бухг. учета (sku, цена, склад и пр.) они не доступны паблику,
на стороне дисплея - те которые показываем пользователям (в том числе анонимам).

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

Просто попробуйте так (хотябы по первой) - увидите это может покрыть массу типовых задач при малом кол-ве проблем безопасности.

Так-же рекомендую поставить и изучить оригинальный дистр. коммерца - он будет отличным примером.

Аватар пользователя gun_dose gun_dose 30 января 2017 в 7:41

Что-то вы оба не то говорите. Постоянно засовываю в продукт кучу полей и нет проблем ни с индексом, ни с правами.

Аватар пользователя gun_dose gun_dose 30 января 2017 в 10:15

multpix wrote:

для паблика дисплей, для учета продукт

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

Аватар пользователя multpix multpix 30 января 2017 в 11:02

для особо одаренных тролят переведу на вульгар:
витрина - display_product, учет - product)

Аватар пользователя multpix multpix 30 января 2017 в 11:43

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

но обрисовать изначальный принцип от которого стоит начать - это дело.

Аватар пользователя lo_sinclair lo_sinclair 30 января 2017 в 21:03

gun_dose wrote:

Что-то вы оба не то говорите. Постоянно засовываю в продукт кучу полей и нет проблем ни с индексом, ни с правами.

Значит, у меня проблема в какой-то ерунде, которую я с ходу не вижу. (Поиск пустой)

gun_dose wrote:

Очень неоднозначное разделение. Размер майки - это витрина или учёт?


Если не влияет на цену, то витрина же. Не привязано к уникальному товару.

Аватар пользователя multpix multpix 30 января 2017 в 21:07

lo_sinclair wrote:

Если не влияет на цену, то витрина же. Не привязано к уникальному товару.

совершенно верно, а если влияет - sku же))

А индексация нормально проходит?
Индекс полный?

Аватар пользователя gun_dose gun_dose 30 января 2017 в 21:28

lo_sinclair wrote:

Если не влияет на цену, то витрина же. Не привязано к уникальному товару

Почему это не привязано? Складской учёт у всех размеров разный. Более того, это опция, обязательная при оформлении заказа.

Аватар пользователя lo_sinclair lo_sinclair 30 января 2017 в 21:49

multpix wrote:

А индексация нормально проходит?

Индекс полный?

Да! Если имеется в виду "Index status". Индексируется без ошибок.
Поля отмечены только эти:

UPD. Причиной был HTML-фильтр почему-то.

Аватар пользователя lo_sinclair lo_sinclair 30 января 2017 в 21:35

gun_dose wrote:

lo_sinclair написал:

Если не влияет на цену, то витрина же. Не привязано к уникальному товару

Почему это не привязано? Складской учёт у всех размеров разный. Более того, это опция, обязательная при оформлении заказа.


Ну так опция будет обязательной у дисплея(карточки) при заказе. Она не вилияет на цены, значит несколько разных товаров с уникальными характеристиками не требуется. Хотя, если это нужно для учета - да.

Аватар пользователя gun_dose gun_dose 30 января 2017 в 21:49

Именно поэтому все атрибуты, необходимые для указания при заказе, обычно хранят в продукте, реже в line item.

Касаемо вашего вопроса - отмотайте скроллом ту страницу со скрина в самый низ. До упора. И там найдёте филдсет, а в нём селект, а в нём яйцо, а в яйце иголка, а в нём связанные поля

Аватар пользователя multpix multpix 30 января 2017 в 21:51

никогда не возникало необходимости класть так продукт в индекс
всегда - дисплей
кто так делает -проблем меньше.

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

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

не стоит лишний раз давать анонимам непосредственный просмотр сущностей коммерца.

Аватар пользователя gun_dose gun_dose 30 января 2017 в 22:01

Даже слайдер цены не делал что ли?

ЗЫ: на самом деле в индекс можно класть очень много интересных вещей, например одно и то же поле проиндексировать дважды - как строку и как фуллтекст, можно делать агрегированные, составные поля. А можно вообще написать своих плагинов агрегации и делать совершенно немыслимые вещи. И что круто - вычисления производятся только во время добавления ноды в индекс, что значительно снижает нагрузку на сервер во время поиска или выборки. Вся эта магия на вкладке фильтры. Думаю когда-нибудь написать статью об этом.

Аватар пользователя multpix multpix 30 января 2017 в 22:44

А как это мешает работать с ценой прилетевшей через связь?
хорош меня удивлять)

З:Ы:
На самом деле эластик офигенная система если ее использовать вне друпалклика
https://www.elastic.co/products/elasticsearch
попробуй на досуге))

Аватар пользователя Andruxa Andruxa 1 февраля 2017 в 22:27

multpix wrote:
никогда не возникало необходимости класть так продукт в индекс

Есть такая необходимость.
Допустим, есть дисплей - определенная модель футболки.
Она может быть трёх размеров -S/M/L и двух цветов - черный/белый.
При этом к дисплею привязаны продукты:
- SKU: xxxSW, размер: S, цвет: белый,
- SKU: xxxMW, размер: M, цвет: белый,
- SKU: xxxMB, размер: M, цвет: черный,
- SKU: xxxLB, размер: L, цвет: черный,

То есть, отсутствуют белая футболка размера L и черная футболка размера S.
Не важно, по какой причине - их не производят, они не пользуются спросом и их не завозят, ну или они просто закончились - самый реалистичный вариант.

Важно то, что пробросив в индекс дисплея поля продукта Цвет и Размер - мы получим там такие значения:
Цвет: [белый, черный]
Размер: [S,M,L]
И если покупатель отфильтрует дисплеи в разделе каталога "Футболки" по белому цвету и размеру L - он увидит этот дисплей, несмотря на то, что продукта с требуемым сочетанием атрибутов там нет.
И только зайдя на страницу этой модели (дисплея) - покупатель поймёт, что ему морочат голову: есть варианты белого цвета и есть варианты размера L, но нет требуемого варианта с сочетанием цвета-размера.
Конверсия опять пойдёт по тихой грусти.

Аватар пользователя Andruxa Andruxa 1 февраля 2017 в 23:01

Строить индекс по продуктам, группируя их по display_id
При этом, есть ограничение на одно значение.
Нельзя, чтобы товар лежал сразу в нескольких дисплеях.
Точнее - лежать-то он там может, но один из дисплеев должен быть primary, по нему товары можно группировать.
Другие дисплеи можно использовать для разного рода промо-станиц, вне каталога.

Аватар пользователя gun_dose gun_dose 1 февраля 2017 в 23:12

А можно подробнее? Как в индекс добавить поле, не являющееся полем сущности или его производной? И как в таком случае делать вьюсы?

Аватар пользователя Andruxa Andruxa 1 февраля 2017 в 23:45

gun_dose wrote:
Как в индекс добавить поле, не являющееся полем сущности или его производной?

hook_entity_property_info

gun_dose wrote:
И как в таком случае делать вьюсы?

Я делал свой style plugin для вывода дисплеев.
Бонусом - многие значения, требующие сложной логики при расчете - подтягиваются из индекса, куда они до этого были положены как entity property.

Но, возможно, есть менее костыльно-ориентированный метод.

Аватар пользователя gun_dose gun_dose 5 февраля 2017 в 18:03

Ну тут понятно - повесить на продукт ещё одно свойство - nid родительской ноды, через hook_entity_presave вычислить его. Но потом нужно в индекс продуктов засунуть поля нод - сами собой они не появятся в связанных, но можно написать плагин фильтра для Search API, который позволит добавлять поля ноды в индекс. В итоге трудоёмкость задачи возрастает в разы. Однако есть тут ещё один подводный камень - корзинки не хотят выводиться во вьюхах по индексам, самый простой путь их вывести - это выводить тизеры, однако поскольку у нас индекс не по нодам, а по продуктам, то опять упираемся в непонятно что.

Аватар пользователя lo_sinclair lo_sinclair 30 января 2017 в 22:07

multpix wrote:

никогда не возникало необходимости класть так продукт в индекс

всегда - дисплей

кто так делает -проблем меньше.

multpix wrote:

не стоит лишний раз давать анонимам непосредственный просмотр сущностей коммерца.

Это понятно. А как индекс, в который попадают не все поля может повлиять на безопасность данных? SKU можно не добавлять.

Здесь вы, видимо, имели в виду вопрос идеалогии коммерц:

multpix wrote:

В этом фишка коммерца, он так работает - для паблика дисплей, для учета продукт.>

У меня просто сам запрос к этому поиску: чтоб выводились товары с уже "выбранными" атрибутами. Поэтому мне кажется более рациональным искать сразу по товарам, а не дисплеям.

Аватар пользователя gun_dose gun_dose 30 января 2017 в 22:09

lo_sinclair wrote:

Поэтому мне кажется более рациональным искать сразу по товарам, а не дисплеям.

Вы сами себя загоняете в рамки. Имейте в виду две вещи:
1. В дисплее можно мышкой накликать показ нужных полей товара, при этом не давая никому прав на просмотр продукта.
2. Вьюсы строятся по дисплэям. По товарам вьюс может быть нужен только админам. Но добавлять поля товара в индекс или вьюс - совершенно нормальная практика, в индексах через связанные поля, в простых вьюсах через релэйшены.

ЗЫ: лишние поля в индекс добавлять не надо, чтобы не переливать их из пустого в порожнее.

Аватар пользователя lo_sinclair lo_sinclair 30 января 2017 в 23:16

gun_dose wrote:

Вы сами себя загоняете в рамки. Имейте в виду две вещи:

1. В дисплее можно мышкой накликать показ нужных полей товара, при этом не давая никому прав на просмотр продукта.

2. Вьюсы строятся по дисплэям. По товарам вьюс может быть нужен только админам. Но добавлять поля товара в индекс или вьюс - совершенно нормальная практика, в индексах через связанные поля, в простых вьюсах через релэйшены.

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

Аватар пользователя gun_dose gun_dose 30 января 2017 в 23:28

Нормально. Всё так и задумано - юзер видит сетку из дисплеев, переходит на страницу дисплея. А продукт - это накипь, выросшая на кнопке корзины.

Аватар пользователя tmp tmp 31 января 2017 в 0:08

gun_dose wrote:

А можно вообще написать своих плагинов агрегации и делать совершенно немыслимые вещи. .


А можно, пожалуйста, немного ссылок на какой то материал по агрегации? Замучился с объединением нескольких фасетов в один блок. Подозреваю можно как то через агрегацию, но информации нормальной ни как найти не могу. Скачал уже модуль

https://www.drupal.org/project/searchapimultiaggregate

Но он делает не совсем то что мне нужно (думал переделать). Выводит все значения агрегированных полей вместе. Мне нужно чтоб значения выводились по группам в одном блоке. Но ни как не могу въехать как этот модуль вообще работает. Возможно как раз плагином можно это все решить? Но хоть какую то инфу о том как пишутся плагины для этой цели?

у меня сейчас вот так получается с агрегацией

фф

А надо так

ааа

Аватар пользователя gun_dose gun_dose 30 января 2017 в 23:56

Всю инфу получил сам методом тыка и отладки кода. А вам, вполне вероятно, нужно сделать кастомный блок, в котором программно объединить содержимое двух фасетных блоков.

Аватар пользователя tmp tmp 30 января 2017 в 23:57

gun_dose wrote:

Всю инфу получил сам методом тыка и отладки кода. А вам, вполне вероятно, нужно сделать кастомный блок, в котором программно объединить содержимое двух фасетных блоков.


Smile Понял, спасибо. Wink

Аватар пользователя tmp tmp 1 февраля 2017 в 12:32

Подскажите, плиз, как достучаться к protected объектам. Ни как не въеду.
к FacetapiFacet::$adapter через $this->facet->getAdapter() дохожу. Дальше ни как.
Либо
Cannot access protected property SearchApiFacetapiAdapter::$facets

либо

Call to undefined method SearchApiFacetapiAdapter::getFacets()

Аватар пользователя tmp tmp 1 февраля 2017 в 12:50

Мне получить заголовок фасета. То есть имя поля (к примеру поле field_class имеет имя "Класс")
Вот его мне нужно получить при формировании формы и засунуть в '#title' => Smile

Там полный массив

facet:protected->adapter:protected->facets:protected['field_class']->facet:protected['lable']

Вот туда хочу добраться Smile
Вроде как наверно можно функцией facetapi_adapter_load но не могу найти описание как она работает

Аватар пользователя tmp tmp 1 февраля 2017 в 13:33

Фуф..... добрался! Это жесть! Ни где в инете не нашел описания как работает facetapi_adapter_load и как открывать доступ к объектам. Даже не знаю как догадался.... Реально - жесть! )))))

Аватар пользователя tmp tmp 5 февраля 2017 в 15:40

Подскажите плиз еще по фасетам (если кто знает Smile )

Нужно получить путь к странице поиска. Может есть функция специальная?
Можно через всякие
facetapi_adapter_load
getEnabledFacets и прочее, а потом весь полученный массив парсить, но это это же столько лишних процессов!!!! Может есть какая то штатная функция для этого?
facetapi_get_facet_info($searcher); - ни чего нужного не выдает. Sad

Аватар пользователя gun_dose gun_dose 5 февраля 2017 в 18:06
1

Смотря где и зачем, например в theme_facetapi_link_inactive эта переменная есть.

И ещё зависит от того, что подразумевается под страницей поиска, т.к. для фасетов страницей поиска является любая страница, выводящая выборку по индексу.

Аватар пользователя tmp tmp 5 февраля 2017 в 21:37

gun_dose wrote:

Смотря где и зачем, например в theme_facetapi_link_inactive эта переменная есть.
И ещё зависит от того, что подразумевается под страницей поиска, т.к. для фасетов страницей поиска является любая страница, выводящая выборку по индексу.


О! Болльшое спасибо , посмотрю эту переменную! Мне вот ка раз эта страница и нужно, к которой привязана выборка. Та которая передается в форме как [#path] =>
Мне для формирования как раз пути формы. Можно взять из друпаловской функции current_path но боюсь что так возможна не совсем корректная работа. ))) Все бьюсь над модулем по объединению форм в одну realm Smile
Почти все готово, сейчас только мучаюсь с корректной обработкой прежних и новых запросов. )))

Аватар пользователя tmp tmp 7 февраля 2017 в 0:06

--- CUT---
Прошу прощения. разобрался в вопросе. Это особенность браузеров обрабатывать так представление формы. Smile

Аватар пользователя lo_sinclair lo_sinclair 6 февраля 2017 в 22:24

А если все-таки строить индекс по продуктам, почему не выводятся фасеты с их полями? Блок не отображается. Что это за проблема?
И нет части настроек. Например, если отметить в фильтрах "Search API ranges"
у индекса по дисплеям появились настройки Search API ranges (можно выбрать числовые поля) - скрин 1
у индекса по продуктом нет - скрин 2

Все-таки, как ни выкручиваюсь, мне нужен поиск по продуктам, с учетом задачи.

Аватар пользователя Andruxa Andruxa 7 февраля 2017 в 0:33

lo_sinclair wrote:
у индекса по продуктом нет - скрин 2

какой тип у этого поля в индексе?

Аватар пользователя lo_sinclair lo_sinclair 7 февраля 2017 в 0:43

Andruxa wrote:

какой тип у этого поля в индексе?

Поле Price » Сумма (десятичная) - commerce_price:amount_decimal - Десятичное число.
Так же как у дисплея.

А если извратиться для интереса и выбрать поле через дисплей этого товара:
A bridge to node referenced by field_product » Product » Price » Сумма (десятичная) - field_product_node:field_product:commerce_price:amount_decimal
То оно появляется в "Search API ranges". Но не оно нужно.

Аватар пользователя Andruxa Andruxa 7 февраля 2017 в 10:04

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

Quote:
Search API ranges
Adds the minimum and maximum values of selected numeric fields.

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

Аватар пользователя gun_dose gun_dose 7 февраля 2017 в 10:09
1

Если ничего не путаю, то на такие поля ползунок вешается просто в настройках отображения фасета без обработки фильтрами Search API ranges

Аватар пользователя Andruxa Andruxa 7 февраля 2017 в 10:14
1

Да. Search api ranges - для другого: построить диапазон из множественных значений.

Аватар пользователя tmp tmp 11 февраля 2017 в 1:58

А можно как то в блоке Current search blocks, когда отображаются значения в группах (по field_) - сортировать группы? Ну то есть передать вес как то этим группам.

Аватар пользователя tmp tmp 11 февраля 2017 в 13:28

А как во вьюс сделать показ всех цен вариантов продукта?
Когда прописываешь связь то пишет :
This is a multi-valued relationship, which is currently not supported. Only the first related entity will be shown.

Соответственно выводится только цена первого варианта.

Пока нашел решение с модулем https://www.drupal.org/project/views_field_view
Но это подгрузка во вьюсе еще одного вьюса.... боюсь что системе будет полный ппц.
Есть еще патчи вьюса за 12-ый год. Проверять на новой версии вьюса кажется бессмысленно. неужели ни кто не решал эту проблему больше?

Аватар пользователя gun_dose gun_dose 11 февраля 2017 в 14:10
1

Цены всех товаров выводить во вьюхе по дисплеям? С точки зрения дизайна крайне сомнительно. Я делал просто кнопку, которая по нажатию дёргала аяксом вьюху с модификациями товара и выводил её в фансибокс.

Аватар пользователя tmp tmp 11 февраля 2017 в 14:33

gun_dose wrote:

Цены всех товаров выводить во вьюхе по дисплеям? С точки зрения дизайна крайне сомнительно. Я делал просто кнопку, которая по нажатию дёргала аяксом вьюху с модификациями товара и выводил её в фансибокс.


Тоже вариант. Просто у конкурентов как раз выводятся все цены. Для пользователя вроде бы и удобно. Но с другой стороны... надо подумать еще Smile

UPD
Ха! Сейчас посмотрел конкурентов - они убрали все цены. )))) Видимо не совсем востребованна данная функциональность Smile

UPUPD
А не... есть. у них тупо сделано. Если выбираешь категорию - то с одной ценой, если применяешь фильтр - то все цены. Движок у них не помню какой, но какой то специализированный для магазов, на подобии Дзен карта... что то такое

Аватар пользователя gun_dose gun_dose 11 февраля 2017 в 15:44

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

Аватар пользователя tmp tmp 11 февраля 2017 в 19:00

А вычисляете один или несколько вариантов продуктов через пхп код? С помощью Views PHP ?

Аватар пользователя gun_dose gun_dose 11 февраля 2017 в 19:13
1

Вьюс пхп - модуль для дураков. Сделал простую вьюху с контекстным фильтром и передаю в неё значения поля продукт.

Аватар пользователя tmp tmp 11 февраля 2017 в 19:37

gun_dose wrote:

Вьюс пхп - модуль для дураков. Сделал простую вьюху с контекстным фильтром и передаю в неё значения поля продукт.


А на странице поиска? в самой выдаче поиска при применении фасетных фильтров, выдается список товаров. В этом списке как определить один вариант или два? Чтобы можно было делать кнопку "больше вариантов" или же эту кнопку не показывать. Можно как то такое реализовать малыми силами? Smile

UPD
Нашел возможность показывать счетчик вариантов! Наверно здесь копать? Smile

Аватар пользователя tmp tmp 11 февраля 2017 в 20:29

И надеюсь крайний вопрос:
А для сортировки по цене - необходимо индексировать поле price????

Аватар пользователя tmp tmp 12 февраля 2017 в 22:01

Прошу прощения, но прошу совета. Smile

Настроил все таки показ на странице поиска вывода всех вариантов продукта из

Администрирование » Магазин » Товары » Типы товаров » Товар

Управление отображением - строка.
То есть из "строки".
Но чтоб предоставить только необходимую покупателю информацию - поубирал из отображения все лишнее и оставил только необходимый минимум.
Для дизайна прячу эту инфу под спойлером.
Так вот вопрос в том что не помешает работе магазина то, что я в этом отображении позакрывал административные строки.

Вообще не пойму для чего это отображение "Строка"?
Заранее спасибо

Аватар пользователя lo_sinclair lo_sinclair 14 февраля 2017 в 21:59

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

(Если что, у меня проблема с конвертацией валют, в индекс попадают значения в той валюте, в которой они лежат в БД. Внятного решения не вижу).

Аватар пользователя gun_dose gun_dose 14 февраля 2017 в 22:55
1

hook_entity_property_info_alter

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

Аватар пользователя lo_sinclair lo_sinclair 15 февраля 2017 в 18:50

gun_dose wrote:

hook_entity_property_info_alter
А можно для агрегации и свой плагин написать, который будет делать что хочешь.

Спасибо, смотрю.

Аватар пользователя tmp tmp 22 февраля 2017 в 17:03

Блин.... помогите, плиз, еще раз... спасите!!! ))
Ни как не пойму как организовывается сортировка?
Делал на странице поиска во вьюс как обычно, в сортировке - раскрыть для посетителей
Но тогда при выбирании сортировки - фасетные фильтры сбиваются. Подозреваю что не так делается сорировка здесь. Но ни как не могу понять - как же? Smile

Аватар пользователя tmp tmp 22 февраля 2017 в 18:48

Ни чего не пойму с сортировкой. Она что, так и должна работать???
Получилось пока добиться корректного вывода (малыми усилиями) через Better Exposed Filters и только в выводе в виде ссылок. И то пришлось патчить сам модуль. Не пойму зачем в нем рабочий путь берется из
$this->view->get_path()

Поменял просто на current_path()

Все ок. Но мне кажется это не совсем корректно. Должно же быть штатное решение? Уж это ведь точно тривиальная задача.

Аватар пользователя tmp tmp 22 февраля 2017 в 20:20

multpix wrote:

разверни этот дистр https://www.drupal.org/project/commerce_kickstart

он может стать неплохим рабочим примером.


Спасибо, но времени нет. Нужно срочно уже проект сдавать ))))

Хоть просто намекните куда копать? Потому как только с Better Exposed Filters работает корректно

Аватар пользователя tmp tmp 22 февраля 2017 в 21:17

Ок, поставил.... ради этой функции ставить целый модуль??? Это разумно?

Аватар пользователя tmp tmp 22 февраля 2017 в 21:29

multpix wrote:

там  search_api_sorts работает,

а использовать или посмотреть как написанно - дело хозяйское)


Та да, яж вот уже поставил kickstart и смотрю. Поэтому и спрашиваю - разве разумно ради такой простой функции ставить целый модуль? Хотя так подумал - возможно для search_api как раз эффективней будет работать на прямую Smile
Спасибо

Аватар пользователя dgastudio dgastudio 22 февраля 2017 в 21:38
1

https://www.drupal.org/sandbox/pl2/1438442
или
https://www.drupal.org/project/facetapi_pretty_paths

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

Аватар пользователя tmp tmp 22 февраля 2017 в 21:44

dgastudio wrote:

https://www.drupal.org/sandbox/pl2/1438442

или

https://www.drupal.org/project/facetapi_pretty_paths
первый сохранит гет параметры

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


Спасибо! теперь думаю как лучше. Что то кикстартер как то так ужасно сделан. Как 20 век на дворе. Smile

Аватар пользователя tmp tmp 25 февраля 2017 в 16:20

dgastudio,
хотел еще раз поблагодарить за модуль решающий проблему передачи гет параметров в вьюс сортировку!!!!
Пытался все решить без дополнительных модулей, хочу как поменьше модулей ставить, но в данном случае единственно оптимальное решение предложенное вами! СПАСИБО!