Николай Савин

Хорошо посмотрю на досуге. Спасибо.

Очень просто. Отключаем системную настройку

ms2_register_frontend

css

Тот код, что я вам написал — был всегда. Он не поменялся и является более корректным.
А вот старый код более не работает, начиная с 4 да. По идее его вообще не нужно было использовать в компоненте, так как мой вариант проще, быстрее в написании и до сих пор работает.

Корректнее было бы перевести как сущности, но штуковины как то по-русски больше звучит ))

Получается так. Добавлю.

Вот вызов плагина

$response = $this->ms2->invokeEvent('msOnCreateOrder', array(
                'msOrder' => $msOrder,
                'order' => $this,
            ));

Как можно заметить в плагине есть обе переменные. msOrder это объект заказа, order — это сам класс обработчик заказа

У меня два вопроса.
Первый — Зачем вообще после возвращения со страницы оплаты что то делать? Это может быть актуально разве что для цифровых товаров, которые после оплаты должны быть доступны для скачивания.

Второй вопрос — я потерял нить разговора. У вас вопрос какой бы изначально? В чем затык?

Я вам выше дал ссылку на исходный код платежки от Робокассы.
Посмотрите как устроена она. Это самый свежий компонент.

Кажется мы друг друга не очень понимаем.

Еще раз. Метод receive не используется клиентом, администратором и т.п.
Он нужен для того чтобы Банк в фоновом режиме сообщил сайту о совершенной оплате. Никаких редиректов там нет и быть не может.

Смену статуса оплаты по URL в данном случае использовать нельзя, потому что зная нужную комбинацию — мошенник может подтвердить оплату, не производя ее.
Опирайтесь ТОЛЬКО на автоматическую служебную информацию от банка.

receive это метод, который реагирует запрос из вне. Обычно банк после оплаты дергает файл

/assets/components/minishop2/payment/имя_платежки/имя_платежки.php

В этом файле «по вкусу» происходит валидация входящего от банка запроса и затем вызывается метод receive, основная задача которого — поменять статус заказа на оплачено. Запрос на проверку успешной оплаты производится также «по вкусу». Многие платежки просто слепо доверяют входящим данным.

Для фронта, в случае этого метода ничего не происходит, так как он является служебным API методом.

Как его тригерить — посмотрите в том же Paypal или например Робокасса

Откройте плагин msTelegram и попробуйте заменить строчку

$contacts = $modx->getObject('msOrderAddress', array('id'=> $msOrder->address));

на следующий код

$contacts = $msOrder->Address;

Значит нужно смотреть журнал ошибок сервера.

Ну ей как бы никто и не занимался.

Scheduler работает через крон.
То есть раз в минуту он запрашивает наличие задач в очереди и если такая есть, запускает задачу в работу.
Таким образом если условный интернет-магазин ставит в очередь несколько задач

• Письмо менеджеру
• Письмо Клиенту
• Заказ в CRM
• СМС клиенту

То эти задачи будут выполнены в течение 4 минут по очереди.

Но можно конечно делать и по другому. Ставить в задание не одну простую задачу, а пул задач. Что-то вроде — выполнить все процедуры касающиеся Заказа.

А еще @Дима Сайт показывал как можно дергать CRON чаще, например каждые 10 секунд. Но у меня пока не получилось повторить (не особо и старался).

Как 1.4.1? Вот только в прошлой статье 1.0.0 было вроде.

С версии 1.4.1 сниппет вывода информации о скидках на конкретный товар удалён. Вместо него добавлен процессор.

Честный semver подразумевает смену мажорной версии в таких случаях. Хотя ты конечно хозяин

Откуда взялся MIGX?
Есть же встроенный механизм присвоения категорий опциям.
Используйте его.
Как обойти проблему с вариативностью названий я вам написал.

В Minishop2 4.0.0 поле 'msOrder.address' удалено.
Если оно требуется в компоненте — значит компонент более не будет работать. Ему нужно обновление.

Можно вместо названия писать ключи лексиконов.
Далее в каждой категории добавлять к лексикону какой-то префикс или суффикс. В этом случае на один ключ можно получить множество именований.
Примерно по такому принципу работают заголовки фильтров в mFilter2

Спасибо за подробное разъяснение.