Как сделать такие шикарные ЧПУ для фильтров в каталоге?

Question

[Илья]

Приветствую всех.

Зачастую никто не заморачивается, что будет в УРЛ после site.ru/catalog/category (образно), когда юзверь понажимает инпутов фильтра и кнопку отфильтровать, допустим, а на этом сайте ребятки заморочились =). Посмотрите на примеры урлов с фильтром по некоторым характеристикам:

1. poe.trade/search/inariteriosius - мало чего выбрано
2. poe.trade/search/oremaumihahasi - много чего выбрано
3. poe.trade/search/imomasikosakom - еще один урл просто для примера

Не обращайте внимания на тематику сайта =)

Вот как системы понимают такие УРЛы? Можно ли научить этому Laravel 5.4 (не обязательно вот прям именно с такими кодовыми обозначениями урла фильтров). Как такое вообще можно реализовать? Хотя бы принцип.

Answer 1

[Алексей Уколов]

Нужно просто в каком-то хранилище (БД или Redis, например) сопоставить параметры запроса с уникальной строкой. При получении запроса получаем параметры из хранилища, вместо request()->get('foo') и работаем с ними как обычно.

Comments

[Илья]

У меня возникала мысль, что это делается через какой-либо middleware который воспринимает параметры стандартные, далее происходит стандартная фильтрация по ним, формирование нового урл, и 301 редирект на новый урл. Или нужно делать какой-то шифратор-дешифратор. Просто поидее во вьюхе форма тож должна понимать какие параметры реквеста ей были переданы и сделать соотвествующую форму с данными из реквеста (активные поля, данные в text полях) и т.д.

[Алексей Уколов]

При сабмите формы, конечно, стоит редирект - форма сабмитится как обычно, данные сохраняются, генерируется идентификатор и идёт редирект на "красивый" урл.

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

[Илья]

Зничит оставлю пока в голове этот вариант с "замучиванием" middlewares'ов. Хотя, надеюсь это не последний вариант такого рода реализации.

Answer 2

[D3lphi]

Стесняюсь спросить, чего тут шикарного? То что находится после poe.trade/search/ это просто идентификатор поискового запроса, который где-то у них хранится. При изменений параметров поиска, создается запись, например, в БД в которой и хранятся все эти параметры. Передавать это все в виде GET-запроса не очень, так как очень много разных параметров для фильтрации. При переходе по ссылке из хранилища достается запись с полученным идентификатором из url'а и производится фильтрация.

Comments

[Илья]

такие урлы в таком ОГРОМНЕЙШОМ фильтре встретишь, думаю, на 0.1% сайтов =) То есть судя по вашему ответу получается что нужно записать в базу все возможные варианты фильтрации? После, скажем, добавления новых, например, у какого либо товара появился новый параметр "thisisshit" ? "values: 1,0", нужно перегенерировать все варианты уже с этим новым параметром?

[Алексей Уколов]

нужно записать в базу все возможные варианты фильтрации?

Нет, конечно - просто полученная от пользователя GET-строка пишется в БД, если такой ещё нет там.

[Илья]

А если GET строки еще в базе нет, юзверь еще ниразу не выбирал такой набор характеристик в фильтрах, ему отдастся обычный GET?

[D3lphi]

Илья,

То есть судя по вашему ответу получается что нужно записать в базу все возможные варианты фильтрации?

Да что ты, черт побери, такое несешь? (c)

[dmitriy]

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

[Илья]

D3lphi, хых, справедливое замечание =) Возможно, просто только сейчас до меня дошло что Вы имели ввиду. Есть только одно уточнение, там тогда реально получается происходит редирект 301 на новый урл после отправки данных фильтра. Просто если выбрать что-то по характеристикам, нажать сабмит, урл сразу делается короткий. Этож тогда сколько надо вариантов хранить в базе, допустим на фильтр "цена" от 1-100000 - каждый раз новый вариант? а если числа с плавающей точкой. Э тож там какая база соберется ...

[Алексей Уколов]

А если GET строки еще в базе нет, юзверь еще ниразу не выбирал такой набор характеристик в фильтрах, ему отдастся обычный GET?

Да, блин, нет же - если строки в базе нет, она туда добавится и пользователь будет отправлен на url с идентификатором из БД вместо GET-параметров.

[Илья]

diamond, Все верно, по крайней мере в базе собралось уже больше 100000 значение характеристик. А смысл простой, цена проекта растет с такими урлами - это первое, а второе, ну очень хочется такие урлы =) это же супер компактно, минималистично, чем длиннющая строка в браузере, которая зачастую даже не индексируется поисковиком, у тут будет индекс, это 5-15% доп. потенциальных покупателей =)

[Илья]

Алексей Уколов, D3lphi, Простите за мой тупизм =). Про базу я понял. Остался вопрос про миллиарды такого рода записей в ней =) даже на текущем этапе с 5000 товаров и 100000+ значений характеристик. Без базы значит никак? Можно ли сделать это каким либо алгоритмом шифрования и дешифрования "налету"?

[D3lphi]

Илья,

Этож тогда сколько надо вариантов хранить в базе, допустим на фильтр "цена" от 1-100000 - каждый раз новый вариант? а если числа с плавающей точкой. Э тож там какая база соберется ...

Какая? Вам место на диске жалко? Добавляете к записи в БД поле, в котором хранится время создания записи и периодически "чистите" устаревшие. Реализуется это все элементарно.

[Илья]

D3lphi, То есть урлы "навечно" не сохранять ... Конечно это логично. Но тут теряется тогда весь смысл сия действия, ссылки нужны для индексации, нужны для трафика, ссылка в поисковике будет хранится N времени. Удалив ее мы получим 404 страничку. Из поиска она вылетит. Трафика не даст. А вдруг она была хорошая и давала много трафика (поисковики не предсказуемые, порой). А наш автобот сайта ее взял и удалил, посчитал ее старой. Конечно с другой стороны ссылка может стать не ликвидной сама по себе (допустим был размер у товарной пачки, а через год его не стало как и части товаров по данному фильтру) и в итоге по данной ссылке вылезет что-то вроде "ничего не найдено". Но в такой ситуевине, я тут подумал, что можно прикрепить к ссылке, результат фильтрации в виде plain/array/json?? списка айдишников товаров. Тогда результат выдаст хоть какой-то но результат (простите за тафтологию)

[Алексей Уколов]

даже на текущем этапе с 5000 товаров и 100000+ значений характеристик.

В базе хранятся поисковые запросы (наборы фильтров). Сколько уникальных поисковых запросов было, столько и записей.

[D3lphi]

Илья,

Но тут теряется тогда весь смысл сия действия, ссылки нужны для индексации, нужны для трафика, ссылка в поисковике будет хранится N времени. Удалив ее мы получим 404 страничку. Из поиска она вылетит. Трафика не даст. А вдруг она была хорошая и давала много трафика (поисковики не предсказуемые, порой).

Вы это из-за CEO собрались делать? То есть, вы действительно верите в то, что проиндексированная страница поиска как-то увеличит приток людей на ваш ресурс? Смешно.

Делайте, что считаете нужным. По техническим вопросам уже все обсуждено.

[Илья]

D3lphi, Дело в том что сайт работает уже 4 года и судя по метрике и гугл аналитике, с фильтров идет 5-15% трафика (и это еще без хорошей оптимизации страничек) Я понимаю ваше возмущение(мне самому проще сделать все стандартно и ниип...ца), но все это основано на реальных фактах. По этому появилась мысль как бы этот процент увеличить. Так как есть реальный результат. Не ругайтесь =) Спасибо за помощь =)

[Илья]

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

[ThunderCat]

Илья, мысль верная, более того, при 1000 посетителей новых фильтров создаваться будет вряд ли более 100. И чем больше уже будет записано, тем со временем их будет меньше. Много вариантов фильтрации людям не нужно, в реале пользователь выбирает 2-3 галочки и может слайдером побаловаться. Так что на самом деле, конечно же, записей будет на несколько порядков меньше всех возможных комбинаций фильтра.

[Yan-s]

Илья,

Можно ли сделать это каким либо алгоритмом шифрования и дешифрования "налету"?

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

[Илья]

Yan-s, я вот сам больше склоняюсь именно к определенному алгоритму, это будет и универсальнее и без лишних запросов в бд, так как на данный момент используется EAV, не хочу нагружать базу лишними запросами, ведь на странице помимо фильтров и прочего могут быть еще дополнительные слои со своими запросами. Кстати есть ли на эту тему какие либо шифраторы и дешифраторы? То есть получил строку, зашифровал, и в любой момент расшифровал в исходный вид? Как мне еще кажется можно обойтись даже без редиректов 301. Это тоже важный момент, не желательно их появление в процессе выдачи странички

[Yan-s]

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