Володя

вы используете модификатор, для корректной работы используйте оператор присутствия

{($key in list [1, 3, 42]) ? 'ключ найден' : 'не найден'}

{'site_url'|config|preg_replace:'!/$!':''}

нет

Пожалуйста!

нет, конечно. Данный случай описан для магазина в РФ. Главное привести номер к единому виду.
Поправил в заметке, спасибо!

— события msOnBeforeGetOrderCustomer, msOnGetOrderCustomer

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

нет, пользователь в любом случае создается.

в логах modx должна быть ругань на синтаксис, попробуйте как

'where' => '{ "createdby":[[!+modx.user.id]],"published":0 }',

Нужно удалить.

Запрос на смену доставки асинхронный. Пока выполняется один запрос, успевает выполнится следующий. При получении ответа от коннектора срабатывает выставление нужного способа доставки. Таким образом получается ситуация minishop2 заглючил.
Выход либо поставить прелоадер при смене доставки, заблокировав на время запроса какие либо действия пользователя, либо сделать запрос синхронным.

В этом компоненте предусмотрено что-то подобное?

нет, в текущей реализации нет работы с прокси. Вы можете расширить базовый класс rgContentGetter и добавить туда что угодно.

Писал свой парсер для Алиэкспресса, столкнулся с тем, что при попытке качать несколько товаров, они отдают страницу для авторизации.

Столкнулся с такой же проблемой в ходе тестирования компонента. Как выяснилось закрыты товары что лежат в каком либо магазине, но у такого товара всегда есть оригинальная страница с другим адресом. Так вот решилось небольшими костылями.
Кратко: Если попытка получить контент закончилась неудачей — редирект на мобильную страницу — она всегда доступна, там выдираем ссылку на оригинальную и парсим уже ее.
Конкретного заказчика устроило данное решение, на этом и остановились. А так если компонент будет популярен то допишу работу с проксями…

А рядом говорят, что не работала.

вот мой коммент modx.pro/news/15883#comment-99911 от 11 июля 2018, 12:31 — она работала.
не особо слежу за этим, но по моему и в начале этой недели она тоже работала.

не критично, просто не так давно она работала, сейчас нет…

при авторизации через vk на modx.pro выдает

{"error":"invalid_request","error_description":"Security Error"}

Возможно ошибка в tinycompressor?

Можно чуть подробнее разжевать, как сделать, чтобы появилась форма для ввода исходных данных для парсинга?

у вас старая версия minishop2, потому и нет ничего. Мой косяк, совсем забыл про это. Добавил в описание.
По поводу возврата средств за дополнение обратитесь в чат на сайте магазина.
Извините за данный недочет.

Спасибо!

давняя тема yandex.ru/search/?text=%D0%BC%D0%B5%D0%B3%D0%B0%D1%84%D0%BE%D0%BD%20%D0%BF%D0%BE%D0%B4%D1%81%D0%BE%D0%B2%D1%8B%D0%B2%D0%B0%D0%B5%D1%82%20%D1%80%D0%B5%D0%BA%D0%BB%D0%B0%D0%BC%D1%83&clid=2261451&banerid=0699003705%3ASW-a460a23c760b&win=332&lr=192

И после обработки, в части кода, который сформирован методом where() у нас получается вот что:

WHERE  ( `a`.`id` LIKE 0 AND `a`.`city` LIKE 0 AND `a`.`name` LIKE '%300%' AND `a`.`phone` LIKE 0 AND `a`.`mail` LIKE 0 AND `a`.`performer` LIKE 0 )

Для проверки использую $c->toSql().

в данном случае toSql не вариант для проверки, поясню на примере

первый запрос

$c = $modx->newQuery('modResource');
$c->select('id');

$c->where(array(
    'id:LIKE' => '%10%',
));
$c->prepare();

$total = $modx->getCount('modResource', $c);
print_r($c->toSQL() . PHP_EOL);
print_r($total . PHP_EOL);

даст нам

SELECT `id` FROM `modx_site_content` AS `modResource` WHERE `modResource`.`id` LIKE 0 
2

как видим запрос типа кривой, но результат выдал 2. Странно да? Уже повод задуматься…

Давай выполним второй запрос, минуя метод where

$c = $modx->newQuery('modResource');
$c->select('id');

$c->query['where'][] = new xPDOQueryCondition(array(
    'sql'         => '`modResource`.`id` LIKE \'%10%\'',
    'conjunction' => 'AND',
));
$c->prepare();

$total = $modx->getCount('modResource', $c);
print_r($c->toSQL() . PHP_EOL);
print_r($total . PHP_EOL);

результат

SELECT `id` FROM `modx_site_content` AS `modResource` WHERE `modResource`.`id` LIKE '%10%' 
2

Итог: в первом и втором запросе мы получили нужный результат. Так в чем же дело?

Фишка старого доброго (как говорит Иван Климчук) xPDO

ps. Вообщем не факт что твоя ошибка была в этом месте… совсем не факт. Просто при toSQL
выполняется parseBindings что приводит запрос к такому виду…

ты делаешь

$c->where($this->where);

что делает метод where ?

он всего лишь пишет в массив $this->query['where'] условия. Я тебе и предлагал туда записать условия напрямую в виде sql

В функции prepareQueryBeforeCount я формирую запрос. Формирую where через foreach:

если у вас prepareQueryBeforeCount, то почему

$this->where

а не

$c->where

на худой конец

$this->query['where']