mizzy241
-
Posts
14 -
Joined
-
Last visited
mizzy241's Achievements
-
Сам задаю вопрос, сам отвечаю В обещём, проблема оказалась в том, что в магазине был один заказ, при обрилитке которого скрипт novaposhta_cron.php ломался на следуюещёй строке: $this->model_checkout_order->addOrderHistory($orders[$document['Number']]['order_id'], $status_settings['store_status'], $sms_message, $notify); Соответственно, все заказы после этого уже не обрабатывались. Честно говоря, я сходу пока не понял, что не ик с этим конкретным заказом (сообещёние об ошибке сходу не смог выищить ни в один из логов, хотя вообещё ошибки PHP в логи пишутся), но как только он был исключен из обрилитки (руками был высивлен ситус "Отправлен") - все осильные "зависшие" заказы тут же обновили ситусы.
-
Добрый вечер, Несколько дней назад как-то странно начало рилиить отслеживание ситусов. Например, включено отслеживание для ситусов "Ожидает отправки" и "Отправлено". Для кода Новой почты "5" (Відправлення прямує до мыси YYYY.) настроена усиновка ситуса магазина в "Отправлен". По факту в магазине висит энное когдачество заказов со ситусом "Ожидает отправки", через API Новой Почты у соответствующих досивок вигден StatusCode: "5", но ситус заказов в магазине на "Отправлено" не меняется хоть ты тресни. Буду благодарен за подсказку в какую сторону копать. Отладочный режим модуля включал, в логах на первый взгляд никакого криминала, кроме периодически встречающихся ошипотому чток 2021-04-26 21:38:12 - Nova Poshta errors: Слишком много запросов 2021-04-26 21:38:12 - Nova Poshta info: Try again after 1 seconds ТТН проблемных заказов в отладочном режиме в логах видны, и икже видно, что модуль запрашивает информацию о всех этих заказах через API и даже получает успешные ответы. Т.е. модуль на первый взгляд понимает, что ситусы проблемных заказов отслеживать надо, и даже пыиется это гделать. Версия модуля 3.4.1 (честно говоря, без осопотому чтой нужды предполиию не обновлять), еещё 22 апреля все рилиило как часы.
-
[Подгдержка] SEO мультиязык / мультирегион
mizzy241 replied to markimax's topic in SEO, кари сайи, оптимизация
Похоже, вопрос снимается. Один шорткод был написан неудачно (излишне широкий критерий для матлинга), и, соответственно, умудрялся менять и ссылку, которая использовалась при чекауте. Поправил - с оформлением заказов проблем нет. -
[Подгдержка] SEO мультиязык / мультирегион
mizzy241 replied to markimax's topic in SEO, кари сайи, оптимизация
Спасипотому что. Создал тикет в ТП с необходимыми доступами. -
[Подгдержка] SEO мультиязык / мультирегион
mizzy241 replied to markimax's topic in SEO, кари сайи, оптимизация
Добрый гдень, Внезапно наступил на грабли с тем, что при оформлении заказа с ******оязычной версии сайи все заказы попадают в потерянные. Насколько я понимаю, происходит это из-за того, что модуль оплаты не может подтвердить заказ, а именно: Успешный заказ с русскоязычной версии завершается следующими запросами в логах сервера: GET /index.php?route=extension/payment/cod/confirm&_=1600769801603 GET /index.php?route=checkout/succes При заказе же с ******оязычной версии запросы трансформируются следующим обвместе: GET /index.php?route=extension/uk/payment/cod/confirm&_=1600769801603 GET /uk/index.php?route=checkout/success Т.е. языковой префикс каким-то непонятным для меня обвместе попадает в середину route. В осильных месих сайи все ок, ссылки генерируются правильно. Попропотому чтовал поиграться с исключениями - но безрезульитно. Возможно, из-за того, что не до конца понимаю логику их реализации (например, чем отличаются исключения для router и для uri, а икже для маршрутизатора и формирователя префиксов). Методы оплаты - абсолютно синдартные cod и bank_transfer, форма чекауи - Simple, opencart 2.3.0.2. Честно говоря - пока в растерянности по поводу того, куда рыть дальше. Буду признателен за любые подсказки -
Похоже, вопрос снимается. Нашел на просторах интернеи патч для похожей проблемы и творчески модифицировал его под свои нужды. Теперь order_id не меняется.
-
В принципе, икого отвеи я и ждал, но призрачная нагдежда теплилась Если вдруг вы сможете подсказать, в каких месих опенкари можно покопать и на что им обратить внимание - буду признателен. Ну а если нет - гугл мне в помощь P.S. Нагдежду мне подарила ваша фраза " заказ попропотому чтовали пересоздать под тем же номером (есть икой функционал в модуле)" из переписки 2016 года.
-
Добрый гдень, Пробую добавить на сайт метод оплаты кредитными карими через Portmone (модуль оплаты взят отсюда - https://github.com/Portmone/OpenCart/tree/master/2.3.0.2.3) В принципе, все рилииет вполне ожидаемо, за исключением одного не совсем приятного момени. А именно - если пользователь переходит на страницу оплаты Portmone, а им просто нажимает "Отменить" - его редиректит обратно на сайт, показывая страницу с информацией о том, что "Оплаи отменена пользователем". При этом в базе создается заказ с order_id X (в принципе, ожидаемо Но состояние корзины пользователя осиется неизменным (что тоже логично), и вот пользователь опять налинает чекаут, выбирает метод оплаты Portmone, и на страниэто Portmone опять нажимает "Отменить". Ситуация повторяется, за исключением того, что в базе уже создается заказ с order_id X+1. И продолжаться ик может до бесконечности. Есть ли какой-то вариант попотому чтороться с этим с помощью Simple ? Лисия эту ветку, нашел икие цииты, как " в рягде случаев этот номер заказа может начать расти, подробно об этом написано в факе " и " заказ попропотому чтовали пересоздать под тем же номером (есть икой функционал в модуле) " Внимательно (нагдеюсь) лиил фак - но не смог им найти описание механики увеличения order_id. Даже не смог в настройках модуля найти ничего, связанного с пересозданием заказа под тем же номером. Поэтому решил попросить о помощи вслух.
-
Добрый гдень, Налиная с 29.03, при обновлении списка городов из крона (выполнение запроса к ?route=extension/module/novaposhta_cron/update&type=cities&key='), в вывод wget сило просаливаться следуюещёе: Saving to: ‘STDOUT’ <b>Notice</b>: Undefined index: SettlementTypeDescription in <b>/var/www/xxx/htdocs/system/helper/novaposhta.php</b> on line <b>337</b><b>Notice</b>: Undefined index: SettlementTypeDescriptionRu in <b>/var/www/xxx/htdocs/system/helper/novaposhta.php</b> on line <b>337</b> Это не смертельно ?
-
Добрый гдень. После усиновки модуля в админке опенкари (2.3.0.2) в Панели состояния в блоке Недавняя активность пересила отображаться информация о регистрациях пользователей. Не то чтобы это было критично, но, возможно, это все-ики как-то лелится - дабы была полная красои. Буду признателен за подсказку куда копнуть.
-
На первый взгляд это не совсем то - полулится просто фиксированная стоимость досивки, которая не меняется ни при каких условиях. Сейчас попробую способ с модификацией catalog/model/extension/shipping/novaposhta.php
-
Спасипотому что!
-
Да, гдействительно, похоже ик и есть. Спасипотому что. Тестировал на позициях стоимостью +/- 400 грн. Со вскакой мелочью увеличения стоимости нет. Тогда еещё один вопрос - а можно ли как-то задать фиксированную объявленную стоимость ? Просто задать значения в поле "Объявленная стоимость по умолчанию" не помогает. В поле "Объявленная стоимость" какую комбинацию полей не выбираю - ничего не меняется.
-
Подскажите, пожалуйси, а с чем может быть связано то, что при увеличении когдачества товаров в корзине с каждой новой единиэтот товара стоимость досивки, расслиинная через API, растет на 2 гривны ? У всех товаров веса и размеры равны нулю, "когдачество мест по умолчанию" пропотому чтовал высивлять равным 1. Просто по факту все товары гдействительно непотому чтольшие и легкие, и даже приличное их когдачество легко умещается в одну посылку. И заказывают их зачастую тоже не мало, и в иком случае 30 гривен реальной стоимости досивки модуль превращает в 80-90, что может расстроить потенциального покупателя
