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

Выше посмотри. Здесь же в комментариях несколько раз писал уже

А где собственно запись ответа в лог? Нужно же после запроса еще ответ в лог записать, чтобы посмотреть ошибку

Верно заметил. Сообщество, а не детский сад. Здесь нянечек нет. Не нравится — не используй. Сделай сам.

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

на 130 с лишним скачиваний — он почему то у тебя одного не работает. Тебе не кажется, что проблема не в компоненте, а где то еще?

С какой задачей? Перебрать массив опций и проверить их на пустоту? Это основа PHP: циклы и условия. Если ты не знаешь как делать подобные вещи — то лучше обратись в раздел работа.

Ну как я и сказал. Если у свойства товара пустое значение — RetailCRM вернет ошибку.

Можно ли сделать какое-то условие, если модификация пустая не учитывать ее?
Ответить

Можно — разрешаю.

Насколько я понял, у тебя что то не то с модификациями. Может просто пустые.
Попробуй, распечатай перед отправкой массив с данными, может что-то будет более ясно.

$modx->log(1, print_r($orderData, 1));

Вот после этой строки в плагине

$response = $modRetailCrm->request->ordersCreate($orderData, $site);

можно включить логгирование

$modx->log(1, print_r($response, 1));

Мне очень нравится как API RetailCRM возвращает ошибки. Все предельно понятно

Хотя бы плюсик к статье поставьте вместе со спасибо,
По существу Не уверен что такая доработка плагина нужна. Вы пока второй на 130 загрузок, кто такое спрашивает.

Вообще при выгрузке нужно указывать идентификатор товара в поле ExternalID
Если Вы этого не делали, тогда отдельного специального поля для связи товаров в различных системах нет.

В таком случае, можно перед передачей заказа в RetailCRM, получить идентификаторы товара, используя поиск по товарам в CRM

Для этого в плагине, там где начинается перебор товаров заказа, можно добавить дополнительный поисковый запрос в RetailCRM

$store_response = $modRetailCrm->request->storeProducts(array('name' => $product['article']), 1, 20);  
if($store_response->getStatusCode() == 200){
        $product_id = $store_response['products'][0]['offers'][0]['id'];
  }
$orderData['items'][$key]['offer']['id'] = $product_id;

Здесь вы ищите на складе RetailCRM товар, у которого наименование совпадает с артикулом в minishop2. Если такой товар найден получаем его id.
Разумеется фокус сработает, если указанные данные у товаров в разных системах один и тот же.
Никто не мешает искать по другим общим параметрам.

Важно также понимать, что эти дополнительные запросы занимают время и заказ передается дольше, а клиент в этот момент сидит и смотрит на экран корзины.

В конце плагина есть закомментированная строчка записи результата в лог. Нужно раскомментировать и посмотреть какая будет ошибка

Да, почему бы и нет. Правильнее было бы не TV использовать, а добавить новое свойство товара. Это уменьшит время оформления заказа. Ну и подставляйте новый идентификатор в массив товаров, поле externalID, в плагине

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

Нет не правильно.
Если товар в CRM не создан, то заказ все равно создается на основе присылаемых данных (название, цена, опции)
Если товары в базе CRM уже есть, то достаточно послать идентификатор товара, а все данные подтянутся из базы

Видишь какую тему больную поднял. По любому нужно что то придумать в ядре

Я что то упустил?
Разве на данный момент, метод getCustomerId() не регистрирует пользователя в обязательном порядке? Если да, регистрирует — то по идее уведомление пользователю обязательно должно быть. Это как минимум хороший тон, а местами и соответствие законодательству.

Если нет, не обязательна регистрация — то КОГДА ЭТО СЛУЧИЛОСЬ черт побери?

Твой вариант может и проще и правильнее. Но уж точно это не то решение, которое будет работать из коробки при минимуме затрат.
А вообще я же не претендую на максимальную точность. Просто рассказал о том, как я сделал, показал возможное решение вопроса, и примерно дал понять в какую сторону думать, при кастомизации.

Боюсь Володя не пропустит, вон ругаться уже начал

Думаешь быстрее будет? Все равно же запрос в базу. Или это ближе к Join чем к запросу?