Поведение странного перенаправления в Magento на OnePage Checkout - PullRequest
4 голосов
/ 04 апреля 2011

Мой Magento Verison - 1.4.1.1

У меня две проблемы:

1) Когда я прохожу различные этапы оформления Onepage (регистрация, выставление счетов, доставка и оплата)вкладки), иногда во время этого процесса меня перенаправляют на страницу корзины.Нет ошибок, нет исключений, в var / report не создается отчет.Я не знаю, как его отладить.Нет ли журналов, которые я могу найти?

2) В том же процессе Onepage Checkout после нажатия на кнопку «разместить заказ» (последний шаг), иногда он перенаправляет на страницу корзины, отправляет электронное письмо о том, чтоПорядок завершился неудачно с сообщением:

Перед этой операцией необходимо собрать итоговые значения.

Чтобы решить эту проблему, я прокомментировал эту строку в prepareRecurringPaymentProfiles в файле magento/app/code/core/Mage/Sales/Model/Quote.php, который решил проблему:

throw new Exception("Quote totals must be collected before this operation.");

Я не знаю, связаны ли эти 2 проблемы или нет.Но у меня сейчас нет 2-й проблемы, а 1-ая довольно часто.В чем может быть причина и как ее решить?

дальнейшее обновление - я проверил трассировку firebug, это 500 внутренняя ошибка сервера, которая иногда возникает на любом этапе проверки одной страницыЯ смог покопаться в функциях savebillingaction, saveshippingaction в onepagecontroller.php и обнаружил, что ошибка возникает, когда $ this-> getRequest () -> isPost () пусто, если оно равно 1, тогда оно идет вперед и переходит к следующемуВ противном случае он перенаправляет в корзину. Нет, я не знаю, почему это не 1 или потому, что ajax не может отправлять данные поста, но я проверил запрос XHR, Ajax отправляет данные поста каждый раз (проверяется с расширением firebug).Может ли кто-нибудь сказать мне, что я мог бы сделать дальше для устранения неполадок.Где я могу найти эти Ajax Calls?У Shipping.phtml (любой step.phtml) внизу находится JS. Как он вызывает функцию сохранения действия OnePagecontroller?

Ответы [ 5 ]

1 голос
/ 15 мая 2015

Поскольку это внутренняя ошибка сервера, попробуйте получить доступ к журналу ошибок сервера.Скажу вам, где проблема.У меня была такая же проблема в 1.7.0.В моем примере проблема была в /app/code/core/Mage/Usa/Model/Shipping/Carrier/Fedex.php

0 голосов
/ 31 января 2016

У меня была та же проблема в моем магазине Princessly:

  1. Требуется от 20 до 130 секунд или даже больше, чтобы " Отправка информации о заказе ... " прошла и перенаправила на платежный шлюз, такой как PayPal, если вообще, после нажатия кнопка Разместить заказ , последний шаг оформления одной страницы.

  2. Если это не произойдет, то, скорее всего, из-за истечения времени ожидания слишком много времени, оно перенаправит обратно в корзину , оставив покупателю пустую корзину и В ожидании оплаты заказ, ИЛИ, это даст исключение:

    Итоговые значения должны быть собраны до этой операции.

    Поскольку, очевидно, что-то истекло по тайм-ауту, и сценарий заканчивается до сбора итоговых сумм (что является моей теорией), таким образом отправляя электронное письмо Ошибка платежной транзакции электронное письмо.

После 12 часов исследований и отладки я наконец нашел виновника и решение.

Magento по умолчанию включает RSS-уведомления и уведомления о новых заказах, поэтому каждый раз, когда нажимается Разместить заказ (ресурсы «продажи / заказ» сохраняются), кэш обновляется, поэтому RSS публикуется. Очистка кэша может быть очень дорогой для Magento. Поэтому решение простое. Просто отключите RSS-уведомление для сохранения ресурсов «продажи / заказ».

Найдите / app / code / core / Mage / Rss / etc / config.xml и найдите этот блок:

<sales_order_item_save_after>
    <observers>
        <notifystock>
            <class>rss/observer</class>
            <method>salesOrderItemSaveAfterNotifyStock</method>
        </notifystock>
    </observers>
</sales_order_item_save_after>
<sales_order_item_save_after>
    <observers>
        <ordernew>
            <class>rss/observer</class>
            <method>salesOrderItemSaveAfterOrderNew</method>
        </ordernew>
    </observers>
</sales_order_item_save_after>

Просто удалите или закомментируйте его и обновите кэш Magento в System => Cache Management => Выбрать все => Submit.

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

0 голосов
/ 02 мая 2013

Для всех, кто сталкивается с вопросом «Итоговые данные должны быть собраны до этой операции». ошибка, проверьте ваши журналы Apache на причину внутренней ошибки 500 сервера. Если это что-то вроде этого:

mod_fcgid: read data timeout in 40 seconds
Premature end of script headers: index.php
process 26126 graceful kill fail, sending SIGKILL

.. PHP слишком долго не отвечает. Обычно это действие saveOrder для одной страницы / оформления заказа, потому что оно довольно тяжелое и часто требует подключения к сторонним сервисам (платежные шлюзы, сервисы рассылки, такие как mailchimp и т. Д.). Эти вызовы сторонних сервисов могут занять некоторое время, в зависимости от состояния сети, и могут быть причиной тайм-аута PHP.

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

New Relic - хороший инструмент для мониторинга этих вызовов (и хороший инструмент для мониторинга вашего магазина Magento в целом).

0 голосов
/ 06 августа 2014

На всякий случай, если кто-то получит «Итоговые данные должны быть собраны до этой операции».ошибка, и ни одно из этих решений не решает их конкретной проблемы, я упомяну, что у меня была проблема с этим:

skin / frontend / base / default / js / opcheckout.js

var params = Form.serialize(payment.form);

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

0 голосов
/ 04 апреля 2011

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

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

  1. Вы установили эту систему на более низкую версию, а затем обновили ее?Если да, то как?
  2. Используете ли вы какие-либо расширения, которые изменяют часть сайта, посвященную продажам / оформлению заказа?
  3. Переопределили ли вы какие-либо из моделей, связанных с этой частью сайта?
  4. Вы изменили JS или HTML для оформления заказа?

Если это так, вам следует проверить эти изменения на наличие ошибок.Если нет, попробуйте включить тему по умолчанию для сайта и проверить снова.Если ошибка исчезнет, ​​возникнет проблема с темой, которую вы используете.Если это все еще появляется, проблема в коде.

В этом последнем случае используйте Firebug, чтобы проверить, что запрашивающие страницы с ошибками приводят к тому, что Magento отправляет команды «перенаправления» обратно во внешний интерфейс.Если это не так, это может быть какая-то ошибка JS, но более вероятно, что вы где-то попали в систему с недопустимыми данными, из-за которых Magento задыхается во время проверки.

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

Надеюсь, это поможет!

...