2 минуты назад
Попробуй сейчас.
22 июня 2026, 23:07
Стоит подумать и добавить, так как 100% потребуется как-то модифицировать данные из 1С. Частый кейс это не соответствие категорий на сайте и категорий...
21 июня 2026, 17:50
Уже можно обновляться
20 июня 2026, 17:54
Только что столкнулся с таким на modx3, ранее 1 раз видел на modx 2.8 — не было времени и мотивации разбираться.
Но проблема есть и она старая.
Кл...
20 июня 2026, 13:08
С обновлением проблема ушла — отлично
19 июня 2026, 23:14
Обновление компонента
История изменений MaxNotify 3
1.2.0-pl
добавлен канал max в Центр уведомлений miniShop3;добавлена отправка из Центра дл...
19 июня 2026, 21:05
Копать надо в браузере. На вкладке сеть, если ответ 500, тогда в логи сервера.
16 июня 2026, 15:00
Последний FormIt + последний FetchIt = белый экран
Последний pdoTools + последний MODx v3 = белый экран
16 июня 2026, 10:40
Есть внешняя ссылка на сайт посмотреть?
15 июня 2026, 19:12
Благодарю) сижу ломаю голову, все сайты положил
Всего 125 982 комментария
на феноме наверное будет так
В компоненте не нашел метода editMessage.
Я таких человечков в рамках данного сообщества очень немного
Но чаще всего наши СЕО специалисты требуют, чтобы фильтр не был только инструментом для пользователя но был и СЕО инструментом и тут начинается такое… Иногда бывают требования, чтобы урл страницы изменялся так, в какой очередности человек кликает в фильтре. К примеру если сначала на красный а потом на белый, то урл чтобы был
site.com/filter/red-white/
а если сначала на белый а потом на красный, то
site.com/filter/white-red/
и не смотря на то, что оба запроса вернут один и тот же товар, но например это позволит «порадовать» клиента, и показать ему товары сначала красные, а потом уже белые, тоесть «первое слово главнее второго)».
И получается что от очередности выбора характеристики напрямую зависит то, сколько данных нужно кешировать.
по 2му пункту — я выставляю кеширование БД и как раз для часто используемых вариантов — будет профит.
3. кешировать после изменения менеджером какого то свойства — тоже такая себе затея. это нужно делать если хотя бы 1 день никто лазить туда не будет. и то сомнительное удовольствие для шаред хостингов.
Учитывая что магазины у меня не сильно велики, то без кеша БД или кеш по загрузке (включается в MODX настройке) вполне для 5..10 к товаров уместен.
Если товаров более 10к стоит думать об оптимизации, если фильтрация улетает за 2...3 секунды ожидания.
А [*uri] на текущую страницу, но как вы правильно сказали только на часть ссылки и еще и текстом
Тоесть не 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.
Ну и в моем мировозрении это несколько странно. Систему нужно либо принимать как она есть или не принимать совсем.
Хотя несколько раз я делал нечто подобное, если клиенты уж совсем психовали — делал отдельные страницы для управления некоторыми данными, которые не были связаны с админкой и «закрыты» теми или иными способами. Но это скорее исключение из правил.
Плюс мне «удобно думать» в концепции MVC, а в MODX она очень искажена на мой взгляд.
Как то вот комфортно мне в той микросреде, которую я вокруг slim себе создаю — slim, composer, orm doctrine, twig, php-di, классический mvc, поддержка стандартов psr-7, middleware и psr-15, стараюсь использовать чистый js и parcel (кстати отличная альтернатива излишне замороченному webpack)