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

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

Насчет того, влияет ли последовательность выбора характеристик в фильтре. Вы правы, что не влияет. Но это если говорить о фильтре для покупателя. Ему не важно, сначала он выберет что хочет красную футболку а потом добавит что хочет еще и белые, или наоборот.
Но чаще всего наши СЕО специалисты требуют, чтобы фильтр не был только инструментом для пользователя но был и СЕО инструментом и тут начинается такое… Иногда бывают требования, чтобы урл страницы изменялся так, в какой очередности человек кликает в фильтре. К примеру если сначала на красный а потом на белый, то урл чтобы был
site.com/filter/red-white/
а если сначала на белый а потом на красный, то
site.com/filter/white-red/
и не смотря на то, что оба запроса вернут один и тот же товар, но например это позволит «порадовать» клиента, и показать ему товары сначала красные, а потом уже белые, тоесть «первое слово главнее второго)».
И получается что от очередности выбора характеристики напрямую зависит то, сколько данных нужно кешировать.

В данном случае комбинаций будет 3*3*3 = 27, без учета последовательностей. Да и не будет зависимости от последовательности для БД. Так что всего лишь 27+1 разных запросов закэшировать просто. 1 -й это без фильтра вовсе — тоже кэшируется.

Спасибо большое, заработало!

Думаю, нужно исходить из того какие тормоза. это 1 сек или 10 сек?
по 2му пункту — я выставляю кеширование БД и как раз для часто используемых вариантов — будет профит.
3. кешировать после изменения менеджером какого то свойства — тоже такая себе затея. это нужно делать если хотя бы 1 день никто лазить туда не будет. и то сомнительное удовольствие для шаред хостингов.
Учитывая что магазины у меня не сильно велики, то без кеша БД или кеш по загрузке (включается в MODX настройке) вполне для 5..10 к товаров уместен.
Если товаров более 10к стоит думать об оптимизации, если фильтрация улетает за 2...3 секунды ожидания.

[[++site_url]][[*uri]]

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

[[++site_url]] возвращает ссылку на главную страницу сайта, а мне надо на текущую, только что тестил и с любой формы любой страницы вижу ссылку на главную
А [*uri] на текущую страницу, но как вы правильно сказали только на часть ссылки и еще и текстом

Думаю, что [*uri] возвращяет вам лишь часть полного урл, в котором отсутствует host
Тоесть не site.com/news/
а /news/
изза чего почтовая программа не воспринимает это как url и отображает как текст.
Попробуйте превратить это в полный url добавив впереди системную настройку [[++site_url]] (не уверен что правильно написал, уже давно не использую этот синтаксис)

Еще вопрос из той же серии. Простите, но просто хочу понять ход ваших мыслей.
Вы пишите что начали использовать typescript.
Вы реально ощутили необходимость в строгой типизации данных? Прям поняли, что неудобно работать на чистом js, возникают ошибки изза смены типа переменной?
Или же это просто «плыву по течению» и «модно, стильно, молодежно»?
Или к этому толкают правила компании в которой работаете?

ps. прочел внимательнее и понял, что на изучение ts вас толкнул выбор nest.js

Верно.

У меня вопрос, философский. Как раз вчера над ним размышлял и возможно вы поможете.
Вопрос наверное можно сформулировать так — откуда берутся стеки технологий?
Поясню, что я имею ввиду.
Если спросить у разработчика php какую базу данных он использует, 99 процентов ответят что mysql.
Врядли они смогут ответить на вопрос — почему.
Если спросить разработчика на python то ответ будет Postgress.
Если у разработчика на node js — ответ будет Mongo.
Хотя каждая из этих систем может работать с любой из этих баз данных.
Хотелось бы услышать ваш опыт — работая на php вы наверняка использовали mysql, а перейдя на nodejs выбрали mongo. Почему?
Просто потому что как в опыте с «обезьянками в запертой комнате» — здесь так принято?
Или вы провели для себя сравнительный анализ между возможными базами и выбрали mongo как лучшую?
Ведь mongo относится к группе nosql баз данных и чтобы работать с ней — нужно кардинально перестроить голову и мысли в ней, она очень отличается по характеру от mysql.

slim, composer, orm doctrine, twig, php-di

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

Здравствуйте. У вас получилось решить эту проблему? Столкнулся с тем же(

Мини-сериал! Жду след. серию))

Наверное только тем, что для MODX я этого делать не умею)
Ну и в моем мировозрении это несколько странно. Систему нужно либо принимать как она есть или не принимать совсем.
Хотя несколько раз я делал нечто подобное, если клиенты уж совсем психовали — делал отдельные страницы для управления некоторыми данными, которые не были связаны с админкой и «закрыты» теми или иными способами. Но это скорее исключение из правил.
Плюс мне «удобно думать» в концепции MVC, а в MODX она очень искажена на мой взгляд.
Как то вот комфортно мне в той микросреде, которую я вокруг slim себе создаю — slim, composer, orm doctrine, twig, php-di, классический mvc, поддержка стандартов psr-7, middleware и psr-15, стараюсь использовать чистый js и parcel (кстати отличная альтернатива излишне замороченному webpack)

А чем принципиально отличается разработка админки под slim от разработки простой админки под MODX?

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

Вы правы. Специфика работы той фирмы в которой я «программист» — это не разработка сайтов. Основной упор делается на СЕО продвижение, поэтому к нам приходят (ну или мы ищем) уже готовые сайты, на которые все махнули рукой разработчики, а заказчики недовольны прибылью от сайта. В данном контексте программист получается лишь придатком, цель которого исполнять бесчисленные и иногда бессмысленные идеи наших сео специалистов. Сайты приходят разные, сделанные на чем угодно, поэтому и работать приходится со всем подряд.
Но все же в 30 процентах случаев мы делаем заказчику новый сайт. И тогда я уже стараюсь хоть примерно (как правило заказчик сам понятия не имеет что ему нужно да и сео специалисты тоже) пытаюсь провести анализ и выбрать инструмент. Если это что то очень простое и на всю разработку дается 4-5 дней, то делаю на modx или opencart. Если позволяет время и я вижу, что проект по моим меркам средний или выше среднего по сложности — выбираю slim.
Наверное есть и вторая причина, почему выбираю не modx. Я не умею делать на нем красивые админки. Когда в админке работают наши контент менеджеры, то они привыкли к админке modx. Но если в админке будет работать заказчик — они все поголовно жалуются, что сложно, ничего не понятно, какие-то ресурсы…
А slim позволяет разработать свою админку, лаконичную и понятную.
Почему именно slim — наверное люблю минимализм. Смотрел в сторону laravel и понял что он мне не приятен именно тем, что в нем многое уже реализовано. Разговаривал с одним своим коллегой, просил его рассказать что такое storage в laravel, потому что сам не очень понял. Он сказал — а зачем ты пытаешься понять, вот же в документации написано — пишешь вот это, вызываешь такой то метод и все. Я так не люблю, мне такой подход не нравится.
Как раз в данную минуту разрабатываю личный кабинет для клиентов компании воздушного такси.