Евгений Шеронов

Поправлю, поля ресурса лучше доставать так:

{$id|resource:'pagetitle'}

Так как через ajax нет объекта $_modx->resource.

В будущем немного оптимизирую)
Допишу где-нибудь)

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

В нашем случае простая формула: 2^n — 1 (2^10 — 1) = 1023 уникальных значения для одинарных, двойных, тройных, ..., десятерных запросов)

Если всего 3 бренда, то 2^3 — 1 = 7 возможных страниц.
1. reebok
2. nike
3. adidas
4. reebok,nike
5. reebok,adidas
6. nike,adidas
7. reebok,nike,adidas

От количества собранных значений очень сильно зависит (геометрическая прогрессия).
При 15 значениях — уже 32767 записей получится)

Здравствуйте :)
Такой функционал есть в сниппете sfMenu.
Он умеет сортировать как по количеству просмотров SEO-страниц, так и по количеству товаров.

В тексте про хлебные крошки не совсем верно расписал. Они есть уже давно)
Не было виртуально вложенных хлебных крошек — вот это добавилось в обновлении.

P.S. Не забывайте прописывать шаблон для названия страниц в правиле. По нему ещё при сохранении формируются названия, которые используется как в меню, так и в крошках.

Выбирать в фильтре все интересующие бренды — это то понятно.
От того что вместо адреса /catalog/adidas-nike-reebok показывается catalog/?brand=1,2,3 фильтрация результатов не меняется, по идее клиент может даже не замечать смены url.

Здесь больше другой вопрос, нужны ли подобные заголовки «Купить кроссовки Adidas, Nike и Reebok»?
Если человек выберет всевозможные бренды, то вообще не красиво будет смотреться.

В целом я решил, что можно сделать с этим функционалом.
Скорее всего будет просто кнопка в словаре или в поле, которая позволит сформировать из значений поля — двойные, тройные и так далее, но с таким предупреждением:
«Из 10 значений поля Бренд получится 45 двойных значений в словаре. Соответственно ссылок будет ещё больше, умножится на количество использования поля в правилах».

И тройные можно будет сформировать, там будет 120 дополнительных записей)
Но нужны ли такие страницы для SEO? Или это уже на откуп вебмастеров?

Управление колонками для отображения — вообще теперь must have для любого компонента)

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

P.S. «Обновление от 19.10.2019» немного из будущего)

Я как раз про это и говорю)
Что по 3 параметрам, хоть по 10 разным составляйте страницы.
На вашем примере это по 1 параметру из 3 полей:
«Оттенок двери» + «Материал покрытия» + «Конструкция».

Только как Вы смогли выбрать конкретно на этом сайте?)
У меня больше чем 1 параметр не получается выбрать)
А понял, это наверно dev-версия.

А так, ссылки в фильтрах через SeoFilter тоже можно сделать, если сильно захотеть, но это менее удобно, чем чекбоксы)

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

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

Правило из разных полей можно с самого появления компонента создавать.
Разные поля(фильтры) — это как раз цвет(красный) + материал(металлическая) + тип(глухая).
И урл примерно получается такой (/catalog/dveri/krasnye/metallicheskie/gluhie)

А здесь же речь шла о том, чтобы автоматически обрабатывать много значений одного фильтра. Чтобы получались страницы такого плана: «Купить красные, зеленые, синие и фиолетовые металлические глухие двери» (/catalog/dveri/krasnye-zelenye-sinie-fioletovye/metallicheskie/gluhie).
Вам такое нужно?)

А менять URL, мета-теги, заголовки и другие тексты тоже всегда можно индивидуально для каждой SEO-страницы.

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

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

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

Извините, если дальше нагрублю, но мне тут вся ситуация напомнила один сайт, где при нажатию на «Добавить в корзину», прилетает фея (шевеля крыльями), хватает картинку товара и улетает с ней до корзины, но я же не прошу этот вычурный функционал добавить в miniShop2, хотя наверное моей бабушке бы понравилось)

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

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

Давайте немного обсудим?
Просто уже несколько раз обговаривал с несколькими людьми, но до дела так и не дошло)

Нашёл свои старые вопросы:
1) Выбранные параметры в url должны идти через разделитель (по умолчанию дефис)?
2) Значения для подстановки в текстах идти через запятую? (соответственно, тоже можно будет поменять)
2.1) Причём последнее из значений должно иметь собственный разделитель, чтобы через " и " разделять.
3) Такую функцию нужно включать при добавлении нового поля?
Или же при добавлении поля в правило?
4) Так как страниц будет много, то они не будут формироваться и храниться в таблице. (для 10 цветов возможно 1023 различные комбинации url-адресов)
4.1) Отсюда следует, что ссылки на такие «множественные» страницы сформировать не получится.
5) Роботы умеют ходить по таким страницам (метрика и вообще клики по фильтрам), соответственно, чтобы не попало десятки тысяч подобных страниц: «Белые, красные, зелёные и синие телефоны, планшеты, ноутбуки», это дело нужно как-то ограничивать. Выставлять noindex, nofollow для всех таких страниц?
6) SEO-практичность таких страниц отсутствует. Почти нет запросов, где ищут что-то одно перечисляя цвета, характеристики. «Красные и синие телефоны», «iPhone 7 64gb, 128gb, 256gb»
7) В основном, весь этот функционал лишь для красоты адреса для клиента? Ведь даже текст выглядеть будет нечитабельно, при большом количестве выбранных значений.
(ну и подобное будет работать чуть дольше, так как нужно будет пытаться динамически разделять адрес, а там даже в псевдониме слова могут быть дефисы, находить все значения, сделать подсчёт)

Я бы ещё предложил просто автоматизировать «двойные значения», но это будет просто кнопка в словаре или в поле «Перемножить значения для Цветов» (при 10 цветах умноженные на 10 цветов получается лишь 45 уникальных пар). Но зато на такие страницы можно будет сделать ссылки (если они будут иметь результаты).

Настройка session_cookie_domain или session_cookie_path.
В настройки контекстов можете их тоже добавить.

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

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

Про множественные значения я имел ввиду то, что человек может выбрать сразу галочками два и более пункта в одном поле(фильтре):
-дома до 50 кв.м.
-дома от 50 кв.м. до 100 кв.м (чуть поправил для примера)

И вот в вашем примере релевантной страницей было бы «Дома до 100 кв.м» (заходя на такую страницу должно отметиться две галочки). А вот с гаражами и другими boolean типами в этом смысла бы не было.

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

Но вообще по вашему примеру(из картинки, где 5 фильтров) правил добавить нужно не мало.
5 (для каждого одиночного правила)
+10 двойных правил (Дома до 150кв.м с гаражом, Двухэтажные дома с подвалом)
+10 максимум тройных правил (Дома до 150кв.м с гаражом и подвалом).
А в правилах из четырёх полей не было бы какой-то пользы. Получился бы слишком низкочастотный запрос) (но там было бы ещё 5 правил и для всех 5 полей всего 1 правило).
= 25 правил для 5 фильтров на странице (до 3 полей)

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

А вообще ускорить это дело немного можно, копируя добавленные правила.
Если есть идеи, как это можно ускорить или упростить — напишите)

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

Начните проверять cookie, адрес страницы выставления, и если в браузере запрещены куки, то и сессии работать не должны.

Это хорошая идея и похожа в реализации на скрещивание нескольких значений одного поля.

Есть у кого-нибудь ещё возможные примеры применения по автоматизации слайдеров?
Чтобы руками не вписывать значения, формировать диапазоны автоматически или сохранять двойные, но одиночные значения: «50,50» по каким-то условиям)

с Tagger разобрались :)
в целом каких-то серьёзных проблем там нет.
При добавлении поля в ключ для класса Tagger рекомендую добавлять id группы тегов.

Тогда да, определённо нужно задействовать настройку seofilter_hidden_tab.

Там появятся два поля, куда можно добавить сколько угодно значений. При редактировании для значений можно открыть окошко, где будет ACE подключён.
Там бы я прописывал поля так: «h1||Buy phones». Если же других языков больше двух, то ещё как нибудь сперва язык через разделитель: «title:eng||Заголовок страницы для англ языка».

И в плагине получать эти свойства, получать ключ языка из локализатора (из сессии?) и заменять значения, отбросив приставки «title:eng» и прочие.

Вкладка появится как раз у правил. Только у SEO-страниц в самой вкладке не появляются эти поля, но при интеграции с FrontendManager при быстром редактировании свойства есть.

Я до сих пор не пользовался Localizator-ом, а что и как там нужно сделать?)
Чтобы тексты можно было на разных языках привязать к SEO-страницам?
Сейчас я добавил настройку для открытия 3го таба для правил (активирует properties так называемые).
Теперь можно туда ввести данные и уже с помощью нового события на плагин sfOnReturnMeta подменить заголовки языка по умолчанию, на те введённые в properties)

А вообще, напишите мне в поддержку, если выдадите доступ — попробую проверить эту теорию.

И да, забыл написать в топике, что в этом обновлении добавил вызов события onWebPageInit, чтобы корректно работал компонент cityFields)

У вас на странице не подключен js-скрипт от mSearch2.
Две причины — либо настройка очищена системная, либо MinifyX как-то режет.
Можете добавить скрипт в ручную (или в MinifyX прописать):

<script type="text/javascript" src="/assets/components/msearch2/js/web/default.js"></script>

Вот это решение должно подойти modstore.pro/packages/ecommerce/msproductscomposerselection
Нужно будет один раз настроить, а потом менеджер сможет легко управлять фильтрами на разных страницах.

Системная настройка seofilter_url_suffix — впишите туда слэш )

А зачем передавать текст закодировано? Если в ТВ поле текст в json-формате, то так в mySql не будет работать поиск и вроде даже по LIKE %json_текст%.
Вроде бы нет стандартных ТВ полей, где текст преобразуется в JSON. MIGX поле?
Если да, то смотрите в сторону поиска по JSON полям, тут вроде даже примеры были.