3 часа назад
Не нужно меня поддерживать в данном конкретном случае. Прошу убрать лишнее
Опыт по переносу MODX2 на MODX3 и Minishop3 2
3 часа назад
В общем убил целый день, но… так у меня ничего и не вышло.
не могу зарегистрировать класс.
содержание самого файла my_msorderhandler.class.php:
...
Кастомизация minishop'a 9
4 часа назад
Вот тебе моё мнение, через полгода-год заказчикам будем всё равно на чём ты будешь делать сайт, гораздо больше их будет волновать вопрос: умеешь ли ты...
Вопрос по будущему MODX и стратегии развития. 1
7 часов назад
Компонент очень нужный и мне кажется будет востребован.
У меня тут задача стоит сделать что-то подобное на сайте на движке на MODX 2.8 — там есть ста...
ms3Variants - Реализация вариантов одного товара в MiniShop3 4
8 часов назад
тут пришла мысль что никто не захочет просто так делиться своим опытом за бесплатно. Можно было бы сделать статьи и кейсы платными? Типа хочешь прочит...
Предложение по развитию сообщества: Создание каталога портфолио/реализованных кейсов на MODX с демо ... 1
Сегодня в 10:08
Добрый день! Я этот компонент давно делал, и еще лет 5 не возвращался к нему… он работоспособен, все в этом плане нормально (ну по крайней мере с php ...
msProductKits - удобное управление товарами-комплектами (наборами товаров) 29
Вчера в 10:22
Вижу, спасибо.
Ошибочно решил, что если есть в документации minishop2, то в старых версиях есть и сам код не посмотрел.
Предыдущий идентификатор статуса при событии 'msOnChangeOrderStatus' 4
Вчера в 09:27
Привет, Алексей.
1. Как определяем ботов
Проверка идёт по User-Agent в ms3rv_is_bot() (helpers.php). Используется regex по типичным маркерам краул...
ms3RecentlyViewed - Недавно просмотренные товары для MiniShop3 2
17 февраля 2026, 10:07
Здравствуйте, компонент куплен, на основной домен ставится, на dev. не ставится,
Could not generate encryption key
Vehicle 04b9f528f736384b46f71324...
[msProductRemains] Компонент учёта остатков товара 179
Всего 125 657 комментариев
Осадочек обоснованный — решение рабочее, но есть несколько моментов, которые стоит обдумать:
Что смущает в текущем фиксе
1. Изменение логики метода.
Оригинальный код при отсутствии сессии возвращал []. Теперь он создаёт сессию. Это может сломать логику в других местах SendIt, которые рассчитывают на пустой ответ как сигнал «сессии нет, нужно что-то сделать».
2. setcookie() без проверки заголовков
Если заголовки уже отправлены — будет ещё один warning.
Минимальный и безопасный фикс
Если цель — просто убрать warning без изменения логики:
Это сохраняет оригинальное поведение: нет куки → нет сессии → пустой массив. Создание сессии должно происходить там, где это предусмотрено архитектурой компонента.
Что бы я сделал
Посмотрел бы, где в SendIt сессия создаётся штатно. Скорее всего есть отдельный метод типа createSession() или это происходит при первой отправке формы. Вот там и должна быть логика создания + установки куки.
Твой фикс работает, но ты фактически добавил fallback-создание сессии в метод, который был рассчитан только на чтение. Если форма авторизации/регистрации работает корректно — можно оставить, но я бы откатился к минимальному варианту и понаблюдал.
Если посетитель находится на главной — они от нее и выводятся.
Блоки в лендинге. должны выводиться аналогично меню.
А в чанке section_tpl уже указывайте [[+id]], [[+alias]], [[+pagetitle]] и т. д. — они будут забираться от выводимых ресурсов
Передача ссылки на оплату заказа или редирект на платежную систему
как это сделать — поясните кто нибудь!
твой способ не работает
Сейчас выдаётся ошибка доступа и вместо страницы оплаты идёт переадресация на страницу ошибки оплаты.
Будет ли обновление компонента?
Версия минишоп была 2.5 и обновления дальше 2.5 не видит. И установлена она была с modx.com, а не modstore. Сменил на modstore — предлагает обновления.
Обновлю, посмотрю модуль будет работать или нет
Потом была проблема, что sendit меня опозновал как бота при тестах и просил перегрузить страницу. Видите ли слишком прямо я курсор вожу по экрану)
Недавно я опять нашел 500 ошибку, когда выбираешь населенный пункт, в котором нет пвз и выбираешь пвз доставку, то в консоли появляется 500 ошибка при аякс запросе.
И соответственно, если человек ушел со страницы оф. заказа в тот момент, когда у него появилась такая ошибка, то при след заходе в оф заказа падает сразу в 500. Очистка кеша/истории браузера помогает (не просто ctrl+f5).
Я пока склонялся к идее, что это чисто мои проблемы (в оф заказа много разных модулей добавлено...) и сейчас буду тестить максимально чистый вариант, без всего лишнего. Но первым делом проверю смену версии php, вдруг правда поможет.
И в демке на сайте такой проблемы нет, там при отсутствии пвз пишется текст, что его нет, всплывают сообщения сендит и в консоли 500 не наблюдается.
Здесь можно потестить отправку — толковый сервис
А вообще правила общие просты:
1. Отправляем через smtp
2. Убеждаемся, что домен, с которого отправляем, не в списках «спам» (см. сервисы разные в интернете)
3. Настраиваем DKIM и SPF записи для домена
если так:
то не срабатывает ползунок — слайдер