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

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

Еще раз. Метод 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

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

Запросов не было

Да как будто бы неоднократно проговаривались, обсуждались нюансы, на которые нужно обратить внимание. И в чате мы часто вспоминаем mSearch.

Из последнего — вот. И это по верхам еще прошлись.

Мы рассматриваем различные варианты монетизации. Спасибо за ваш пример.

Конечно, мы не можем просить сделать его opensource

Очень даже можем! Пора признать что кобыла пока не сдохла, но уверенно стареет, что пора слазить с нее и двигаться дальше. Почему бы не оставить mSearch2 сообществу для его развития. Тем более эпоха MODX2 идет к завершению.
Пусть будет платным mSearch3 для MODX3
Пусть будет бесплатная платформа для дальнейшего развития и улучшения. Аля miniShop2. Вполне допускаю существование платных модулей улучшающих поиск и фильтрацию поверх mSearch2.

В общем верю — что проекту это пойдет на пользу.

@Leonid Krylov обрати внимание, пожалуйста, на ситуацию.

Здравствуйте. Отвечаю вам по порядку.
Для начала вы используете MODX3, а компонент предназначен для MODX2 (правда в описании нигде об этом не сказано). Автору нужно указать это в магазине.
Далее вы конечно можете пожаловаться в магазин как на качество компонента, так и на отсутствие ответа в поддержке. Для этого вы можете написать в support@modstore.pro, либо написать в виджет чата на сайте.
Ну и по закону вы имеете право на возврат денег, в случае если компонент вам не подошел.

Если сервис российский, сервера внутри страны, а сам он внушает юридическое доверие почему бы с ним не работать.
На рынке есть отличные сервисы подборок и рекомендаций, сервисы внешнего поиска с подключаемыми на сайт виджетами, CRM различные и т.п. И ничего… зависят от них. Съезжать никто не собирается.

Я понял это по вот такой строчке

\core\src\Revolution\modParser.php

Пространство имен появилось только в MODX3

pdoTools для MODX3 также есть и работает, но там другие классы. Кроме того сервисы в MODX3 вызываются по другому.
Итого вот такой код

$pdo = $modx->getService('pdoTools');
foreach($array as $arr){
    $out .=  $pdo->parseChunk('userChunk', $arr);
}

мы можем преобразовать примерно вот так

use ModxPro\PdoTools\Fetch;
/** @var Fetch $pdoFetch */
$pdoFetch = $modx->services->get(Fetch::class);
foreach($array as $arr){
    $out .=  $pdoFetch->getChunk('userChunk', $arr);
}

Потому что вы используете MODX3, а код который вам выше показали для MODX2

Для работы с SQL запросами MODX предусматривает насколько путей.
Самый простой «переходный» вот такой

$sql = 'Тут чистый SQL';
$modx->exec($sql);

Более расширенный вариант

$sql = "SELECT * FROM modx_users WHERE active = 1";
// Вариант 1.
$statement = $modx->query($sql);
$users = $statement->fetchAll(PDO::FETCH_ASSOC);
foreach ($users as $user) {
    print $user['username'] .'
';
}
// Вариант 2. Если не нужно зачитывать данные в массив
foreach ($modx->query($sql) as $user) {
    print $user['username'] .'
';
}

Больше примеров вы можете посмотреть здесь
modzone.ru/blog/2016/02/04/database-queries-using-pdo/

Это то, что касается чистых SQL запросов. Но компоненты и Ядро MODX используют конструктор запросов и XPDO. Это несколько сложнее и требует чтения документации