Как поменять статус заказа в OpenCart?
В базовом наборе в системе OpenCart есть некоторый набор статусов заказа. В зависимости от конкретного этапа выполнения заказа, он может принимать один из этих статусов. Просмотреть и настроить статусы заказов вы можете в администраторской части сайта.
Просмотреть статусы заказов можно по такому пути:
System > Localisation > Order Statuses
Система > Локализация > Статусы заказа
В моём примере используется OpenCart версии 2.3, в других версиях пути могут отличаться, поэтому это стоит так же учитывать. У самих товаров статусы так же выставляются в администраторской части сайта, при просмотре и редактировании полей заказа. Не всегда бывает удобно менять статусы заказов в ручном режиме. Часто бывает необходимость смены статуса заказа программно, по какому-либо событию.
В данной заметке мы рассмотрим простой пример смены статуса заказа из контроллера.
class ControllerCheckoutPayengine extends Controller < public function index() < // подключаем модель checkout/order $this->load->model('checkout/order'); // меняем статус заказа на Processing (т.е. статус с 2) $this->model_checkout_order->addOrderHistory($order_id, 2); > > Название метода, и самого класса контролера в вашем случае может отличаться, всё что нужно знать для смены статуса, это ID заказа, а также ID нужного статуса. Предварительно следует подключить класс модели checkout/order, после чего посредством метода класса addOrderHistory() задать новый статус заказа. Метод addOrderHistory() в нашем примере принимает два основных параметра $order_id – номер заказа и $order_status_id – ID статуса заказа.
Скрипт класса расположен по такому пути:
\catalog\model\checkout\order.php
Рассмотрев содержимое файла, можно заметить, что есть дополнительные параметры при обращении к методу addOrderHistory(). Полный список аргументов выглядит таким образом:
addOrderHistory($order_id, $order_status_id, $comment = '', $notify = false, $override = false)
Значение этих параметров:
$oder_id – ID заказа;
$order_status_id – ID статуса заказа;
$comment – текст почтового сообщения;
$notify – по умолчанию false, позволяет отправлять пользователю уведомления о смене статуса;
$override – по ум. false, флаг защиты от переопределения статуса (насколько я правильно понял).
Таким образом используя данный метод в контролерах и моделях можно задавать нужные статусы для заказов. Довольно часто это бывает необходимо при реализации интеграции с платёжными системами. В тот момент, когда клиент производит оплату заказа онлайн, и сервис возвращает данные об успешной транзакции.
Кстати в сети была найдена интересная особенность доработки параметра $comment метода addOrderHistory(). По умолчанию данные из этой переменной принимаются и отправляются в виде plain-text. Если мы захотим отправить письмо в виде HTML текст, то соответственно письмо уйдет как листинг HTML. Однако преобразовав спец символы в HTML-сущности, мы можем реализовать отправку письма в виде HTML. Для этого достаточно в самом начале метода добавить строку:
$comment = html_entity_decode($comment);
После этого в самом письме мы можем наблюдать отображение письма в HTML. Этот момент не совсем относится к теме данного поста, но всё же я решил его затронуть, т.к. речь идет об использовании параметров метода addOrderHistory().
На этом всё, всем всего доброго!
Работа с заказом через админку OpenCart, взгляд изнутри
Разрабатывая модуль для OpenCart, мне понадобилось добавить дополнительное поле к товарам заказа. Но прежде необходимо изучить как устроена работа с заказом через админку. Как оказалась схема не простая и немного запутанная, но это с первого взгляда.
Данные о товарах заказа хранятся в таблице order_product , где товары с заказами связаны по id ( order_id , product_id ). К слову информация о заказе хранится в нескольких таблицах order_ .
Интерфейс
Перейдем в админке «Продажи-Заказы» и выберем любой заказ на редактирование.
Страница редактирования заказа состоит из 5 вкладок, в каждую из которых можно попасть только из предыдущей (нажимая кнопку «Продолжить»), при этом при переходе на некоторые вкладки происходят ajax запросы, на основании ответов которых происходит заполнение вкладки.
Если js в браузере отключен — редактирование заказа будет недоступно. Попасть на произвольную вкладку нельзя.
Перейдем в admin/view/teplate/sale/order_form.tpl (OpenCart 2.3). Здесь можно увидеть что изначально весь интерфейс статический, однако при переходе на вкладку «Товары» (клик по #button-customer внутри генерирует клик #button-refresh где и происходит изменение интерфейса) следует серия ajax запросов, в результате которых на вкладке меняется интерфейс.
Интерактивный интерфейс строится посредством javascript.
Изменение заказа
Перейдем на вкладку «Товары».
При попытке изменить количество позиции посылается ajax запрос с route=api/cart/add . В файле catalog/controller/api/cart.php в методе add используется объект $this->cart класса Cart (корзина), а именно его метод add . Если взглянуть на код метода, то не трудно понять что новые данные о товарах записываются в таблицу cart , но нигде нет записи в таблицы order_ .
В таблице cart есть столбец session_id , значение которого привязывается к текущему юзеру, и является ключом данных в массиве $_SESSION . То есть данные в таблице cart временные и существуют только на период существования сессии юзера.
Подробнее о том что здесь вообще происходит, можно прочитав предыдущие статьи про ajax запросы в OpenCart и про один из способов решения проблемы с доступом к API OpenCart.
Работа с заказом через админку осуществляется через корзину — данные сохраняются в корзину (таблица cart ), но не сохраняются в данные заказа (таблицы order_ )
Сохранение изменений заказа
На странице редактирования заказа перейдем в последнюю вкладку «Итого», пролистаем вниз и нажмем кнопку «Сохранить».
Просматривая консоль браузера можно увидеть запрос route=api/order/edit . Переходим в catalog/controller/api/order.php и смотрим немаленький метод edit , где заполняется массив order_data данными заказа ( $this->cart->getProducts() ).
Небольшой кусок кода, показывающий что данные о товарах заказа берутся из корзины:
// Products $order_data['products'] = array(); foreach ($this->cart->getProducts() as $product) < $option_data = array(); //. $order_data['products'][] = array( 'product_id' =>$product['product_id'], 'name' => $product['name'], 'model' => $product['model'], 'option' => $option_data, 'download' => $product['download'], 'quantity' => $product['quantity'], 'subtract' => $product['subtract'], 'price' => $product['price'], 'total' => $product['total'], 'tax' => $this->tax->getTax($product['price'], $product['tax_class_id']), 'reward' => $product['reward'] ); >Почти в конце метода есть сохранение изменений через модель checkout/order в таблицу order_product :
$this->model_checkout_order->editOrder($order_id, $order_data);А еще ниже в этом методе есть добавление истории заказа:
$this->model_checkout_order->addOrderHistory($order_id, $order_status_id);На этом можно было бы остановится . но дальше будет интереснее 🙂
Посмотрим таблицу товаров заказа order_product :
А теперь взглянем на таблицу корзины cart где хранятся данные редактируемого заказа:
Становится безумно интересно, как данные из корзины ( cart ), сопоставляются с данными в заказе ( order )? Ведь просматривая таблицу корзины и товаров заказа между ними не видно никакой связи. Более того нет никакой связи между товарами этих двух таблиц!
На самом деле все просто, запрос сохранения заказа api/order/edit передает:
А теперь посмотрим внутрь модели checkout/order в метод editOrder и увидим там следующее:
$this->db->query("DELETE FROM " . DB_PREFIX . "order_product WHERE order_id = '" . (int)$order_id . "'"); $this->db->query("DELETE FROM " . DB_PREFIX . "order_option WHERE order_id = '" . (int)$order_id . "'");Нет никакого сопоставления товаров из корзины с товарами из заказа: данные из заказа удаляются и записываются новые данные из корзины.
Дерзко, резко, быстро понятно, но неудобно для добавления дополнительных полей в заказ.
Кстати, OpenCart занимает лидирующее место среди eCommerce на рынке России по мнению BuiltWith. Значит решение вполне годное и нам разработчикам остается лишь придумывать как с этим жить 🙂
Сохранение изменений заказа через админку осуществляется на основании данных корзины редактирования заказа, а корзина привязывается к сессии текущего администратора.
Итог
Схема не совсем очевидная, с первого взгляда может показаться запутанной. Однако, при детальном изучении становится понятна концепция, суть которой простота управления данными. Не могу сказать что мне такое решение нравится, но ясно то, что оно вполне рабочее.