22 мая 2026, 21:53
Разумно. Все поля подряд не хочу добавлять в чанк. Практика показывает, что полей очень много, содержимое может быть объемным и появление подсказок мо...
22 мая 2026, 18:30
Это changelog разросся. Не помещается в базе данных mariaDB (mysql почему то съедает и не морщится) Выпустил Версию. 1.11.1 с решением этой проблемы.
22 мая 2026, 09:51
Твой бот стримит всё что происходит в терминале? И умеет выполнять слэш команды для агентов типа /status /btw? А ещё нет ли проблемы разрастания входя...
21 мая 2026, 14:43
спасибо
19 мая 2026, 10:31
Помогло, спасибо
19 мая 2026, 04:04
Сделал новую версию с табами и возможностью запуска сразу для всех вариантов.
Сначала содержимое для технического ресурса откуда будет запускаться вы...
18 мая 2026, 17:30
Взял в работу
18 мая 2026, 13:46
Исправление уже готово github.com/modx-pro/MiniShop3/pull/271
Всего 125 920 комментариев
MiniShop3 — это бесплатный open source, без техподдержки. Вся работа тут происходит на энтузиазме по мере свободного времени и настроения.
Вы всегда можете предложить свое видение реализации и исправление найденных ошибок через механизм pull request, либо заказать доработку у программистов.
Кстати, глянул на новые тарифы — 0.8% за отправку чека, меня впечатлило))
Я когда оформлял эквайринг — меня отправили на нее www.sberbank.ru/ru/s_m_business/bankingservice/yookassa.
Вообще у нас есть центр уведомлений, где вы можете задать Email шаблоны для каждого статуса покупателю и менеджеру (в том числе файловые). Можно сделать отложенную отправку с настраиваемой задержкой отправления. Можно использовать телеграм и sms каналы отправки данных. Можно использовать события.
Документация docs.modx.pro/components/minishop3/interface/notifications
Подскажите еще один момент! нам надо куда то пристроть код отправки уведомления на почту администратора, в момент появления нового заказа. Куда лучше всего приютить строчку, чтобы не ломать существующие классы, заменой своими, или их правкой? с учетом того что файлы могут обновляться с пакетами.
У меня на сайте рабочем на MODX REVO 2.8.8 + Minishop 3.0.7 заметил вот что —
для многих товаров требуется указание от 10 до 30 опций — по факту заполняют не все. Причем тут пришлось делать конфигуратор, а для него еще создать штук 20 опций.
А по факту у меня часто не все опции заполняются. И получается многие записи хранятся пустые. Т.е. на каждый товар создается запись вида product_id — key опции с пустым value. А можно же не хранить пустые опции? Не знаю почему и как, но вызывает сомнение что так надо было делать.
Всего на рабочем проекте будет более 100 000 товаров (будет больше).
В итоге в таблице ms2_product_options на текущий момент уже вбито 35 000 строк, а когда зальем все товары со всеми опциями, то там будет просто жесть как много строк с пустыми значениями.
Коль, расскажи, схема базы данных (особенно в опциях товара) не менялась? На этом стоит уточнять внимание, ибо существующие компоненты могут её использовать.