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 или фасеты?
Спасибо.
Комментарии
Я решаю эту задачу с https://www.drupal.org/project/views_selective_filters
Возможно есть что то лучше?
Понятно, что надо привыкать к фасетам, но первый случай мне и ваш совет пригодится.
https://vimeo.com/15556855
Фасеты и есть готовое решение для этой задачи. Попробуйте сделать по любому мануалу из интернета, там шагов много, но в принципе все они простые.
Просмотр мануалов не дал мне как раз представления, можно ли связать поля двух сущностей. Везде рассматривался индекс по материалу.
Возможно, я недостаточно долго в них копаюсь.
Если что - есть готовый solr-хостинг для этого дела, http://www.ra-don.ru/solr-hosting . Там же могут помочь и с настройкой фасетов если есть необходимость.
Делать фасеты поверх mysql не очень хорошая затея, да, есть https://www.drupal.org/project/search_api_db , но это если у вас товаров мало, вариантов мало. Если за тысячу товаров и куча фильтров - нужен solr или elastic .
Проект пока не такого масштаба, чтобы прибегать к помощи solr-хостинга. Но учту на будущее.
А кто объяснит зачем такой тяжелый модуль использовать для такой тривиальной и простой задачи? В чем преимущества? Еще и использовать отдельный сервер... И можно ли при такой реализации организовать вывод фильтров с множественным выбором с чекбоксами?
Магазин на 10000 товаров, 100 категорий и 30 фильтров - задача действительно тривиальная. Но обычный вьюс с раскрытыми фильтрами её уже не тянет. А фасеты даже на сёч апи дб, без всяких солров и эластиков уже дают прирост производительности в разы.
Дада! Благодарю за ответ. К вопросу о тривиальности - то сейчас большинство магазов с большим ассортиментом
А вот насчет роста производительности - это большой плюс! Что раньше не навели на этот модуль? Я там в соседних темах как раз интересовался ))) Уже свой код понаписывал!))) Кста - уже даже прикрутил jquery для сброса группы фильтров выводимых в отдельном блоке. ))) Вчера весь день убил. А тут смотрю можно все это реализовать фасетами!
Насколько я понял из описания в интернете - то можно организовать и множественный выбор. Ща буду пробовать! Спасибо.
Не стоит считать это тривиальной задачей,
подобный "поиск" как правило становиться центральным местом на ресурсах содержащих большой номенклатурный ряд товаров.
тема интересная и глубокая,
тут и иерархические фильтры и зависимые и нечеткий поиск и стоп слова и синонимы и пр.
все это упирается в производительность.
видео выше - просто пинок в нужном направлении,
смотрите, читайте доки 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 имел в виду популярность задачи, любой мелкий магазин на запуске нуждается в подобных функциях ) Так что мне тоже показалось, что должно быть все проще и с готовыми решениями.
Как понимаю, главный плюс фасетов в производительности.
Воспользоваться сейчас услугами solr-хостинга нет возможности, вопрос нагрузки пока не стоит, нужна реализация функционала.
Если не сложно, может быть, найдется пример, где используется facet search со связью двух сущностей? (Поиск по полям товара и его дисплея одновременно ) Насколько я понимаю, выборки-связи это вообще не к фасетам, их главная функция поиск и индексирование.
В настройках полей индекса жмите снизу "добавить связанные поля", там будет всё.
Да! Все работает как надо! Этож надо! Неделю промучился с вьюсными фильтрами, а тут за пол дня все готово! Эх.. столько времени потерял
Единственный остался вопрос:
При множественном выборе чекбоксами выбор происходит при каждом клике по чекбоксу. Кто то настраивал так чтоб отключить эту функцию а применять фильтр по кнопке "применить" ? То есть сделал выбор нескольких чекбоксов и потом уже нажимаешь "применить"? Или это уже все таки придется самому допиливать?
В этом простом случае последовательность позволяет избежать недопустимого выбора.
Так-же при каждом применении фильтра идет пересчет кол-ва результатов.
Попробуйте аякс - может так будет веселей)
Совершенно верно. Остаётся добавить, что фасеты по сути не галки и не кнопки, а ссылки, поэтому по клику происходит переход.
Просто просмотрите внимательно видео из моего комента выше.
На 2:00 в индекс добавляют поля связанных сущностей.
Этот скринкаст полностью описывает тривиальную часть настройки связки search_api search_api_db facetapi
В простых случаях этого достаточно - дальше доки, коих завались, и сюда на форум с конкретными вопросами)
Спасибо
Не пойму связи - с множественным применением фильтра и "недопустимого" выбора. )
Если есть к продукт с атрибутами 3-ех фильтров, а второй продукт с 4-мя, то будет как раз доступно эти 4 значения. Если выбираем 4 значения, то в запросе к БД и будет передано 4 значения сразу. Первый продукт отфильтровывается и выводится только второй. То есть пока не вижу "недопустимости". Ща начнем что то думать
Пример. На сайте есть белые жигули и красные астон мартины. Соответственно, в фильтрах цвета и марки по два значения. Вы выбираете красные и жигули и ничего не найдено.
Вот блин... а вот это проблема.
Так ведь правильно. Красных же нет. Вполне релевантный ответ.
Нужны жигули - вибираем "жигули" и видим какие есть жигули.
Просто много общался с пользователями - всех бесит при выборе одного значения перезагрузка всей страницы. Меня к стати тоже
Это не правильно. Когда фильтров много, юзер может потратить до 10 минут, чтобы вдумчиво раскинуть галки, а на выходе получит с большой долей вероятности пустоту. А чтобы перезагрузка не бесила, есть ajax facets, а ещё нужно принять меры по нормальной скорости отклика сайта.
Лан, это все вопросы философии и дизайна
Решение почти нашел. Правда в dev версии. Почти все получается. Осталась проблема - нужно некоторые фасеты выводить в одном блоке. Это возможно?
Спасибо большое! Видео и правда помогло разобраться!
Осталась только одна проблема, поиск прекрасно работает с нодами, а когда я в качестве Entity type выбираю Commerce Product - не ищет даже по заголовку. Или это я что-то не догоняю на ночь глядя.
Это отдельная тема - организация связки product и product_display в commerce.
Вы столкнетесь с таким вопросом как права не привилегированных ролей для просмотра полей сущности product.
Пока не разобрались на собственном опыте(после этого можно усложнить как угодно), пользуйте следующий принцип:
На стороне продукта должны быть поля необходимые для складского и бухг. учета (sku, цена, склад и пр.) они не доступны паблику,
на стороне дисплея - те которые показываем пользователям (в том числе анонимам).
Т.е., нет критической необходимости добавлять в поисковый индекс сущности с ограниченными правами просмотра.
Просто попробуйте так (хотябы по первой) - увидите это может покрыть массу типовых задач при малом кол-ве проблем безопасности.
Так-же рекомендую поставить и изучить оригинальный дистр. коммерца - он будет отличным примером.
У меня в индексах сейчас сейчас только Title самого товара, связки нет.
В этом фишка коммерца, он так работает - для паблика дисплей, для учета продукт.
Повторюсь, для погружения проще глянуть на оригинальный дистр:
https://www.drupal.org/project/commerce_kickstart
Что-то вы оба не то говорите. Постоянно засовываю в продукт кучу полей и нет проблем ни с индексом, ни с правами.
вот это вообще полнейшая ересь. В продукте должны быть все те поля, которые влияют на цену и складской учёт, независимо от их публичности/скрытости. Если торговать шмотками, то атрибут размера идёт в продукт, если буксировочными тросами, то атрибут длины идёт в продукт и т.д.
для особо одаренных тролят переведу на вульгар:
витрина - display_product, учет - product)
Очень неоднозначное разделение. Размер майки - это витрина или учёт?
всему свое время и место.
здесь ты видишь двух участников которым интересны но мало знакомы обсуждаемые темы.
зачем их путать или усложнять на входе?
или давать готовые но субъективные решения.. зачем? лучший опыт - это свой.
но обрисовать изначальный принцип от которого стоит начать - это дело.
Значит, у меня проблема в какой-то ерунде, которую я с ходу не вижу. (Поиск пустой)
Если не влияет на цену, то витрина же. Не привязано к уникальному товару.
совершенно верно, а если влияет - sku же))
А индексация нормально проходит?
Индекс полный?
Почему это не привязано? Складской учёт у всех размеров разный. Более того, это опция, обязательная при оформлении заказа.
Да! Если имеется в виду "Index status". Индексируется без ошибок.
Поля отмечены только эти:
UPD. Причиной был HTML-фильтр почему-то.
Ну так опция будет обязательной у дисплея(карточки) при заказе. Она не вилияет на цены, значит несколько разных товаров с уникальными характеристиками не требуется. Хотя, если это нужно для учета - да.
Именно поэтому все атрибуты, необходимые для указания при заказе, обычно хранят в продукте, реже в line item.
Касаемо вашего вопроса - отмотайте скроллом ту страницу со скрина в самый низ. До упора. И там найдёте филдсет, а в нём селект,
а в нём яйцо, а в яйце иголка,а в нём связанные поляникогда не возникало необходимости класть так продукт в индекс
всегда - дисплей
кто так делает -проблем меньше.
для продукта на старте достаточно ску и цены соотв., а всу остальную лабуду в дисплей с любыми мыслимыми комбинациями - и ее же в поисковый индекс.
так у любой комбинации всегда актуальная цена и фактический склад - по сути больше ничего не нужно.
если нужно в отчете - тянем из дисплея
если нужны хитрые вьюсы для админов на базе продукт - это обычные вьюсы коммерцевых сущностей, не индекса.
не стоит лишний раз давать анонимам непосредственный просмотр сущностей коммерца.
Даже слайдер цены не делал что ли?
ЗЫ: на самом деле в индекс можно класть очень много интересных вещей, например одно и то же поле проиндексировать дважды - как строку и как фуллтекст, можно делать агрегированные, составные поля. А можно вообще написать своих плагинов агрегации и делать совершенно немыслимые вещи. И что круто - вычисления производятся только во время добавления ноды в индекс, что значительно снижает нагрузку на сервер во время поиска или выборки. Вся эта магия на вкладке фильтры. Думаю когда-нибудь написать статью об этом.
А как это мешает работать с ценой прилетевшей через связь?
хорош меня удивлять)
З:Ы:
На самом деле эластик офигенная система если ее использовать вне друпалклика
https://www.elastic.co/products/elasticsearch
попробуй на досуге))
Какую связь во вьюхе по индексу?
Есть такая необходимость.
Допустим, есть дисплей - определенная модель футболки.
Она может быть трёх размеров -S/M/L и двух цветов - черный/белый.
При этом к дисплею привязаны продукты:
- SKU: xxxSW, размер: S, цвет: белый,
- SKU: xxxMW, размер: M, цвет: белый,
- SKU: xxxMB, размер: M, цвет: черный,
- SKU: xxxLB, размер: L, цвет: черный,
То есть, отсутствуют белая футболка размера L и черная футболка размера S.
Не важно, по какой причине - их не производят, они не пользуются спросом и их не завозят, ну или они просто закончились - самый реалистичный вариант.
Важно то, что пробросив в индекс дисплея поля продукта Цвет и Размер - мы получим там такие значения:
Цвет: [белый, черный]
Размер: [S,M,L]
И если покупатель отфильтрует дисплеи в разделе каталога "Футболки" по белому цвету и размеру L - он увидит этот дисплей, несмотря на то, что продукта с требуемым сочетанием атрибутов там нет.
И только зайдя на страницу этой модели (дисплея) - покупатель поймёт, что ему морочат голову: есть варианты белого цвета и есть варианты размера L, но нет требуемого варианта с сочетанием цвета-размера.
Конверсия опять пойдёт по тихой грусти.
Интересный пример. А какой выход из ситуации?
Строить индекс по продуктам, группируя их по display_id
При этом, есть ограничение на одно значение.
Нельзя, чтобы товар лежал сразу в нескольких дисплеях.
Точнее - лежать-то он там может, но один из дисплеев должен быть primary, по нему товары можно группировать.
Другие дисплеи можно использовать для разного рода промо-станиц, вне каталога.
А можно подробнее? Как в индекс добавить поле, не являющееся полем сущности или его производной? И как в таком случае делать вьюсы?
hook_entity_property_info
Я делал свой style plugin для вывода дисплеев.
Бонусом - многие значения, требующие сложной логики при расчете - подтягиваются из индекса, куда они до этого были положены как entity property.
Но, возможно, есть менее костыльно-ориентированный метод.
Индексация кастомных значений в Search API.
Ну тут понятно - повесить на продукт ещё одно свойство - nid родительской ноды, через hook_entity_presave вычислить его. Но потом нужно в индекс продуктов засунуть поля нод - сами собой они не появятся в связанных, но можно написать плагин фильтра для Search API, который позволит добавлять поля ноды в индекс. В итоге трудоёмкость задачи возрастает в разы. Однако есть тут ещё один подводный камень - корзинки не хотят выводиться во вьюхах по индексам, самый простой путь их вывести - это выводить тизеры, однако поскольку у нас индекс не по нодам, а по продуктам, то опять упираемся в непонятно что.
Это понятно. А как индекс, в который попадают не все поля может повлиять на безопасность данных? SKU можно не добавлять.
Здесь вы, видимо, имели в виду вопрос идеалогии коммерц:
У меня просто сам запрос к этому поиску: чтоб выводились товары с уже "выбранными" атрибутами. Поэтому мне кажется более рациональным искать сразу по товарам, а не дисплеям.
Вы сами себя загоняете в рамки. Имейте в виду две вещи:
1. В дисплее можно мышкой накликать показ нужных полей товара, при этом не давая никому прав на просмотр продукта.
2. Вьюсы строятся по дисплэям. По товарам вьюс может быть нужен только админам. Но добавлять поля товара в индекс или вьюс - совершенно нормальная практика, в индексах через связанные поля, в простых вьюсах через релэйшены.
ЗЫ: лишние поля в индекс добавлять не надо, чтобы не переливать их из пустого в порожнее.
Предположим, я смогу предустановить атрибуты товаров, которые вылезут в поиске, чтобы они шли в корзину уже с ними. Пока что не знаю, как это сделать. Но ведь поиск идет только по полям товара, они и попадают в индекс. Нормально ли для индекса выбирать сначала дисплей, а за ним тянуть поля связанных товаров? Получается, что дисплей тут служит чем-то вроде интерфейса для посетителя, сам по себе не несет информационного смысла.
Нормально. Всё так и задумано - юзер видит сетку из дисплеев, переходит на страницу дисплея. А продукт - это накипь, выросшая на кнопке корзины.
А можно, пожалуйста, немного ссылок на какой то материал по агрегации? Замучился с объединением нескольких фасетов в один блок. Подозреваю можно как то через агрегацию, но информации нормальной ни как найти не могу. Скачал уже модуль
https://www.drupal.org/project/searchapimultiaggregate
Но он делает не совсем то что мне нужно (думал переделать). Выводит все значения агрегированных полей вместе. Мне нужно чтоб значения выводились по группам в одном блоке. Но ни как не могу въехать как этот модуль вообще работает. Возможно как раз плагином можно это все решить? Но хоть какую то инфу о том как пишутся плагины для этой цели?
у меня сейчас вот так получается с агрегацией
А надо так
Всю инфу получил сам методом тыка и отладки кода. А вам, вполне вероятно, нужно сделать кастомный блок, в котором программно объединить содержимое двух фасетных блоков.
http://www.img.studioviza.ru/Shotjrmo9.png
Подскажите, плиз, как достучаться к protected объектам. Ни как не въеду.
к FacetapiFacet::$adapter через $this->facet->getAdapter() дохожу. Дальше ни как.
Либо
Cannot access protected property SearchApiFacetapiAdapter::$facets
либо
Call to undefined method SearchApiFacetapiAdapter::getFacets()
А зачем?))
Мне получить заголовок фасета. То есть имя поля (к примеру поле field_class имеет имя "Класс")
Вот его мне нужно получить при формировании формы и засунуть в '#title' =>
Там полный массив
facet:protected->adapter:protected->facets:protected['field_class']->facet:protected['lable']
Вот туда хочу добраться
Вроде как наверно можно функцией facetapi_adapter_load но не могу найти описание как она работает
Фуф..... добрался! Это жесть! Ни где в инете не нашел описания как работает facetapi_adapter_load и как открывать доступ к объектам. Даже не знаю как догадался.... Реально - жесть! )))))
Подскажите плиз еще по фасетам (если кто знает
)
Нужно получить путь к странице поиска. Может есть функция специальная?
Можно через всякие
facetapi_adapter_load
getEnabledFacets и прочее, а потом весь полученный массив парсить, но это это же столько лишних процессов!!!! Может есть какая то штатная функция для этого?
facetapi_get_facet_info($searcher); - ни чего нужного не выдает.
Смотря где и зачем, например в theme_facetapi_link_inactive эта переменная есть.
И ещё зависит от того, что подразумевается под страницей поиска, т.к. для фасетов страницей поиска является любая страница, выводящая выборку по индексу.
О! Болльшое спасибо , посмотрю эту переменную! Мне вот ка раз эта страница и нужно, к которой привязана выборка. Та которая передается в форме как [#path] =>
Мне для формирования как раз пути формы. Можно взять из друпаловской функции current_path но боюсь что так возможна не совсем корректная работа. ))) Все бьюсь над модулем по объединению форм в одну realm
Почти все готово, сейчас только мучаюсь с корректной обработкой прежних и новых запросов. )))
--- CUT---
Прошу прощения. разобрался в вопросе. Это особенность браузеров обрабатывать так представление формы.
А если все-таки строить индекс по продуктам, почему не выводятся фасеты с их полями? Блок не отображается. Что это за проблема?
И нет части настроек. Например, если отметить в фильтрах "Search API ranges"
у индекса по дисплеям появились настройки Search API ranges (можно выбрать числовые поля) - скрин 1
у индекса по продуктом нет - скрин 2
Все-таки, как ни выкручиваюсь, мне нужен поиск по продуктам, с учетом задачи.
Где именно не выводятся? На странице с вьюхой? А вьюха что выводит?
какой тип у этого поля в индексе?
Поле 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". Но не оно нужно.
В случае индекса по продукту - у поля единичное значение (у товара - одна цена), а в случае дисплея - множественное (к дисплею может быть привязано несколько товаров, и у каждого - своя цена).
Чтобы найти минимальное и максимальное значения - надо, чтобы поле имело множественные значения.
Поэтому в индексе по товару к полю цена этот фильтр не применяется.
Если ничего не путаю, то на такие поля ползунок вешается просто в настройках отображения фасета без обработки фильтрами Search API ranges
Да. Search api ranges - для другого: построить диапазон из множественных значений.
А можно как то в блоке Current search blocks, когда отображаются значения в группах (по field_) - сортировать группы? Ну то есть передать вес как то этим группам.
А как во вьюс сделать показ всех цен вариантов продукта?
Когда прописываешь связь то пишет :
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-ый год. Проверять на новой версии вьюса кажется бессмысленно. неужели ни кто не решал эту проблему больше?
Цены всех товаров выводить во вьюхе по дисплеям? С точки зрения дизайна крайне сомнительно. Я делал просто кнопку, которая по нажатию дёргала аяксом вьюху с модификациями товара и выводил её в фансибокс.
Тоже вариант. Просто у конкурентов как раз выводятся все цены. Для пользователя вроде бы и удобно. Но с другой стороны... надо подумать еще
UPD
Ха! Сейчас посмотрел конкурентов - они убрали все цены. )))) Видимо не совсем востребованна данная функциональность
UPUPD
А не... есть. у них тупо сделано. Если выбираешь категорию - то с одной ценой, если применяешь фильтр - то все цены. Движок у них не помню какой, но какой то специализированный для магазов, на подобии Дзен карта... что то такое
Никогда не надо равняться на конкурентов при разработке сайта, иначе будет полный колхоз. Нужно равняться только на самых лучших в мире и думать своей головой.
А вычисляете один или несколько вариантов продуктов через пхп код? С помощью Views PHP ?
Вьюс пхп - модуль для дураков. Сделал простую вьюху с контекстным фильтром и передаю в неё значения поля продукт.
А на странице поиска? в самой выдаче поиска при применении фасетных фильтров, выдается список товаров. В этом списке как определить один вариант или два? Чтобы можно было делать кнопку "больше вариантов" или же эту кнопку не показывать. Можно как то такое реализовать малыми силами?
UPD
Нашел возможность показывать счетчик вариантов! Наверно здесь копать?
И надеюсь крайний вопрос:
А для сортировки по цене - необходимо индексировать поле price????
Да, все поля для сортировок и фильтров должны быть проиндексированы
Понял! СПАСИБО!
Прошу прощения, но прошу совета.
Настроил все таки показ на странице поиска вывода всех вариантов продукта из
Администрирование » Магазин » Товары » Типы товаров » Товар
Управление отображением - строка.
То есть из "строки".
Но чтоб предоставить только необходимую покупателю информацию - поубирал из отображения все лишнее и оставил только необходимый минимум.
Для дизайна прячу эту инфу под спойлером.
Так вот вопрос в том что не помешает работе магазина то, что я в этом отображении позакрывал административные строки.
Вообще не пойму для чего это отображение "Строка"?
Заранее спасибо
Если тема жива,
а можно как-то вычислить свое значение, используя поля индекса, чтобы в итоге получить еще одно поле?
Агрегация не об этом.
(Если что, у меня проблема с конвертацией валют, в индекс попадают значения в той валюте, в которой они лежат в БД. Внятного решения не вижу).
hook_entity_property_info_alter
А можно для агрегации и свой плагин написать, который будет делать что хочешь.
Спасибо, смотрю.
Блин.... помогите, плиз, еще раз... спасите!!! ))
Ни как не пойму как организовывается сортировка?
Делал на странице поиска во вьюс как обычно, в сортировке - раскрыть для посетителей
Но тогда при выбирании сортировки - фасетные фильтры сбиваются. Подозреваю что не так делается сорировка здесь. Но ни как не могу понять - как же?
Ни чего не пойму с сортировкой. Она что, так и должна работать???
Получилось пока добиться корректного вывода (малыми усилиями) через Better Exposed Filters и только в выводе в виде ссылок. И то пришлось патчить сам модуль. Не пойму зачем в нем рабочий путь берется из
$this->view->get_path()
Поменял просто на current_path()
Все ок. Но мне кажется это не совсем корректно. Должно же быть штатное решение? Уж это ведь точно тривиальная задача.
разверни этот дистр https://www.drupal.org/project/commerce_kickstart
он может стать неплохим рабочим примером.
Спасибо, но времени нет. Нужно срочно уже проект сдавать ))))
Хоть просто намекните куда копать? Потому как только с Better Exposed Filters работает корректно
Ок, поставил.... ради этой функции ставить целый модуль??? Это разумно?
там search_api_sorts работает,
а использовать или посмотреть как написанно - дело хозяйское)
Та да, яж вот уже поставил kickstart и смотрю. Поэтому и спрашиваю - разве разумно ради такой простой функции ставить целый модуль? Хотя так подумал - возможно для search_api как раз эффективней будет работать на прямую
Спасибо
https://www.drupal.org/sandbox/pl2/1438442
или
https://www.drupal.org/project/facetapi_pretty_paths
первый сохранит гет параметры
второй, превратит их в чпу. но, тут лучше ставить дев версию + несколько патчей возможно придется накатывать.
Спасибо! теперь думаю как лучше. Что то кикстартер как то так ужасно сделан. Как 20 век на дворе.
а кикстартер вам абсолютно ничего не даст
dgastudio,
хотел еще раз поблагодарить за модуль решающий проблему передачи гет параметров в вьюс сортировку!!!!
Пытался все решить без дополнительных модулей, хочу как поменьше модулей ставить, но в данном случае единственно оптимальное решение предложенное вами! СПАСИБО!