Nanotraktor

Там целая куча причин, на самом деле. Все которые я перебрал в процессе - описаны в статье по ссылке из моего предыдущего ответа. Попробуйте перебрать их по порядочку, вдруг поможет. Все ли там собраны - сказать не могу, т.к. новую версию CMS писали инопланетяне. Возможно какая-то негуманоидная расса. А я не настолько большой спец в этой области чтобы иметь возможность эффективно разбирать такие кульбиты как общение скриптов самих с собой через, хм, http по спецтокену. :)

Как раз наоборот. Если доступен IPv6 - автоматически используется он. Поэтому важно чтобы доменное имя было настроено корректно. :) Если на сервере где находится сайт доступен IPv6, то важно чтобы в настройках домена был прописан правильный IPv6-адрес. Уточните пожалуйста адрес сайта (можно в личку) - попробую глянуть. Вдруг повезло и ошибка аналогичная. Если ещё проще - расписал вот тут по шагам все известные мне варианты лечения этой ошибки (в качестве мелкой саморекламы :ph34r: ): http://www.sysmasters.net/kb/php-notice-undefined-variable-json-in-admincontrollersaleorder-php-on-line-2221/

Нашел причину. Причем очень для меня неожиданную. Откровенно говоря, руки приведшие к ошибке были не мои. Но криворукий баран не додумавшийся проверить этот момент сразу - я. У домена, направленного на сервер есть кроме прочего два набора адресных записей. Первые - традиционно типа "IN A" (IPv4) указывающие на сервер где лежит сайт. Вторые - типа "AAAA" (новый активно внедряемый протокол IPv6) которые тоже должны указывать на тот же сервер (важно чтобы на нём была поддержка IPv6, само собой). Так вот при направлении сайта на VDS-сервер произошло досадное недоразумение. Записи "А" были изменены, а записи "АААА" - нет (мало кто из обычных пользователей вообще придаёт значение абракадабре которая там написана в поле "Данные" :) ). Как результат - скрипты админки написанные инопланетянами-разработчиками используя Curl+API опенкарта пытаются получить нужные для работы данные. Но так как по-умолчанию IPv6 имеет больший приоритет по сравнению с IPv4 - для попыток соединения используются данные из неправильных "АААА" и запросы уходят сайту на старом сервере, где нет нужных данных/другой ключ API. Исходя из вышесказанного совет по исправлению ошибки: А потом уже делайте как обычно: Admin > System > Users > API --> создать пользователя API Admin > System > Settings > Edit > Option (вкладка) > Checkout (секция) --> выбрать этого пользователя и сохранить изменения. UPD. Ещё одно замечание для тех кто не в курсе - после изменения адресных записей домена как правило чтобы увидеть результат нужно подождать от получаса до 3-5 часов. Помните это.

Не сочтите за рекламу. Но проверял на https://www.ukraine.com.ua/ - опенкарт работает как часики. А на своём сервере, блин, точно то же самое - нет. phpinfo обоих сличал буквально с лупой. Формально с системными требования опенкарта вся сходится и между собой имеют минимальные различия. А дело именно в конфигурации веб-сервера - 200%. Но вот где и в чем - для меня загадка. Сегодня займусь, как и говорил, курлом - может быть он отрабатывает как-то неправильно при этом... Сильно сомневаюсь что это он виновать, то других предположений пока нет. UPD. Есть, но совсем "пальцем в небо". PHP собран с разными ключами на рабочем и нерабочем серверах. Если энтузиазма хватит - попробую пересобрать с ключами аналогичными рабочему. Спасибо, уже выяснил что кривизна тестового сервера аналогична остальным (и, возможно, коррелирует с кривизной моих рук :oops: ) и могу тестировать у себя. А даст это понимание причины ошибки. По крайней мере для меня - это важно. Если справлюсь с поиском - стану немножко умнее. Если не справлюсь - я уже накопал много интересного что возместит потраченное время. :) А денвер - это не показатель что что-то работает или нет. Полезная для разработки штука. Но для тестирования мало-мальски сложных вещей - малопригодный хлам.

Немножко не в тему, но всё равно интересно почему так. Вот обращаться из скриптов админки к скриптам сайта используя curl - это органические повреждения мозга у архитектора системы или имеет какие-то преимущества перед нормальной работой со скриптами/базой сайта напрямую? Всё ведь в одной корневой папки, всё имеет доступ к БД напрямую... А так - лишние ресурсы на соединение, лишняя вероятность ошибки. Не понимаю. К слову, проблемы при выполнении запроса вида http://test.com/admin/index.php?route=sale/order/api&token=19607b63557e80eaf22685f211cd5f0b&api=api/currency&store_id=0 (если я правильно понимаю - при запросе курса/списка валют? ). Завтра попробую заставить скрипт писать в лог то что получает курл от сайта. Почему-то кажется что собака зарыта именно в том что он или не получает ничего вообще, или при соединении возникает ошибка.

Я недостаточно опытен в этом. А сроки, увы, поджимают. Поэтому поступил по аналогии с первым случаем - переустановил ОС и поднял заново веб-сервер. Хотя это неправильно в корне, но хоть заработало. Если удастся на тестовом сервере воспроизвести ошибку - обязательно поэкспериментирую. Если камрад testing выделит поддомен/базу для тестов на проблемном хостинге (или сообщит его название) - будет ещё проще поискать причину.

Не работает. Точнее замена строки 2221 на правильную $this->response->setOutput(json_encode($json)); И добавление после 2154 (public function api() {) объявления переменной json: $json = array(); формально решают проблему с ошибкой "PHP Notice: Undefined variable: json in /admin/controller/sale/order.php on line 2221" и кодировкой пустого ответа в json. Но фактически работа с заказом не работает по прежнему никак. Просто не реагируя на кнопки и не сохраняя результаты на последующих шагах

Да, та же ерунда. По поводу php был неправ. Самое странное - что после переустановки ОС и установки ISPManager со всем фаршем автоматически всё заработало без проблем. В чем именно ошибка - так найти и не смог. :-/

А какая версия php у Вас? Так как у меня та же ошибка на сервере с php 5.4 (Debian 7) , рядом такой же, но CentOS 6, php 5.3 - и всё работает как часики. Но так как вопросом только занялся - детальной проверки ещё не проводил. Поэтому лишняя статистика - не помешает.

Спасибо, полезная информация!

На мой взгляд - искать где на сайте вводятся адреса (страница регистрации, личный кабинет, страница заказа (?) ) и проверять - фильтруются ли в соответствующих полях форм вводимые данные. Если нет - фильтровать не давая пользователям (и в идеале - администраторам) писать всякую фигню.

Извините что сразу не написал в продробностях. После редактирования файла admin/controller/sale/contact.php как рекомендовал многоуважаемый afwollis в предпоследнем сообщении включил логирование ошибок в настройках сайта и попробовал разослать письма вновь. Выловил вот такую ошибку: 2015-yy-zz 7:32:12 - processing.email: [email protected] 2015-yy-zz 7:32:12 - PHP Notice: Error: RCPT TO not accepted from server! in /var/www/username/data/www/sitename.com/system/library/mail.php on line 308 то есть, email-адрес был некорректный. Как результат - при попытке отправки сообщения почтовый сервер возвращал ошибку. После этого в разделе "Продажи" -- "Покупатели" -- "Покупатели" остаётся просто выполнить поиск по [email protected] и либо удалить такого пользователя, либо изменить email на корректный и повторить попытку. Если что-то не получится - пишите, попробую в порядке закрепления изученного материала помочь с этим вопросом. :)

Хотел ещё раз сказать спасибо. afwollis, ваш совет помог найти причину ошибки!

Большое спасибо, буду пробовать.

Возможно, есть какой-то мануал, тематическая заметка или ещё какое-то наставление как это грамотно и без ущерба CMS сделать?