nogocuHoBuk

Скачал модуль для 2.3-3.0 - обнаружил ряд существенных недостатков из-за отсутствующих базовых минимумов - ограничения по сумме, дефолтный статус заказа (вместо статуса 0, и, как следствие "Потеря" заказа), настройка статусов для возврата. Внёс небольшие изменения в код модуля. Изменённые файлы: upload/admin/controller/extension/payment/mono.php – контроллер настроек модуля (админка). upload/admin/model/extension/payment/mono.php – модель модуля (админка). Файлы языков админки: upload/admin/language/en-gb/extension/payment/mono.php и upload/admin/language/uk-ua/extension/payment/mono.php. Шаблоны страницы настроек (админка): upload/admin/view/template/extension/payment/mono.tpl (OC 2.3) и upload/admin/view/template/extension/payment/mono.twig (OC 3.0). upload/catalog/controller/extension/payment/mono.php – контроллер оплаты на стороне магазина (каталог). upload/catalog/model/extension/payment/mono.php – модель оплаты на стороне магазина (каталог). Файлы языков каталога: upload/catalog/language/en-gb/extension/payment/mono.php и upload/catalog/language/uk-ua/extension/payment/mono.php. Удалённые файлы: В новой версии отсутствуют служебные файлы macOS (.DS_Store) из папок upload/ и upload/admin/ – их удаление не влияет на работу модуля (просто очистка архива). Детальный обзор изменений по каждому файлу 1. Файл: admin/controller/extension/payment/mono.php Изменения в коде: В контроллере админской части были добавлены новые поля настроек в массив $form_inputs для сохранения настроек модуля. $this->prefix . "mono_sort_order", + $this->prefix . "mono_order_default_status_id", $this->prefix . "mono_order_success_status_id", + $this->prefix . "mono_order_reversed_status_id", $this->prefix . "mono_order_cancelled_status_id", $this->prefix . "mono_order_process_status_id", $this->prefix . "mono_order_hold_status_id", $this->prefix . "mono_destination", $this->prefix . "mono_use_holds", + $this->prefix . "mono_fiscalization_code_field", + $this->prefix . "mono_total", + $this->prefix . "mono_totalmax", ]; Пояснения: Добавлены новые настройки статусов заказа: mono_order_default_status_id – ID статуса нового заказа (статус, который будет присваиваться заказу сразу после оформления, до оплаты). Это нужно для определения начального статуса заказа (предотвращает попадание неоплаченных заказов в “потерянные”). mono_order_reversed_status_id – ID статуса для возврата средств (статус, в который переводится заказ при возврате платежа). Этот новый статус используется при обработке возвратов, чтобы явно пометить заказ как возвращённый (см. изменения логики возврата ниже). Добавлено поле mono_fiscalization_code_field – настройка для фискализации. Ранее в языке эта переменная была, но не сохранялась; теперь она добавлена в список сохраняемых настроек. Влияние: обеспечивает сохранение значения поля "код фискализации" (если используется интеграция с фискальным сервисом). Добавлены поля ограничения суммы: mono_total и mono_totalmax – минимальный и максимальный порог суммы заказа для отображения данного способа оплаты. Назначение: позволить админу задать диапазон сумм, при котором метод оплаты Plata by mono доступен. Эти значения будут проверяться на стороне каталога (см. изменения в модели каталога) и ограничивать использование метода при слишком маленькой или большой сумме заказа (поддержка ограничения мин/макс суммы оплаты). Все перечисленные поля добавлены в $form_inputs, что означает, что при сохранении настроек модуля OpenCart будет их учитывать и сохранять в базе данных. Без этих добавлений новые настройки не сохранялись бы. 2. Файл: admin/model/extension/payment/mono.php Изменения в коде: В модели админской части внесены изменения в структуру таблицы логов и форматирование закомментированного кода. $this->db->query(" CREATE TABLE IF NOT EXISTS `" . DB_PREFIX . "monopay_logs` ( + `id` INT(11) NOT NULL AUTO_INCREMENT, `key` TEXT NOT NULL DEFAULT '', `value` TEXT NOT NULL DEFAULT '', `module_version` VARCHAR(50) NOT NULL DEFAULT '', `timestamp` TIMESTAMP NOT NULL DEFAULT NOW(), + PRIMARY KEY (`id`) ) ENGINE = MyISAM ... "); Пояснения: Добавлен первичный ключ id в таблицу monopay_logs: теперь при создании таблицы логирования monopay_logs добавляется поле id INT(11) NOT NULL AUTO_INCREMENT и объявляется как PRIMARY KEY. Это изменение вводит уникальный идентификатор для каждой записи лога. Зачем: наличие первичного ключа id упрощает управление записями (например, удаление или выбор конкретных записей) и улучшает структуру таблицы. Ранее таблица не имела явного PK, теперь логическая целостность выше; на работу модуля это напрямую не влияло, но является улучшением базы данных. 3. Файлы языков админки (admin/language/en-gb и uk-ua) В языковых файлах админской части (английском и украинском) добавлены новые переменные текста для новых настроек (минимальная/максимальная сумма и новые статусы заказа). Изменения в коде (en-gb): $_['entry_geo_zone'] = 'Geographic area'; +$_['entry_order_default_status'] = 'New order status'; $_['entry_order_success_status'] = 'Paid order status'; +$_['entry_order_reversed_status'] = 'Order status after refund'; $_['entry_order_process_status'] = 'Order status in processing'; $_['entry_order_cancelled_status'] = 'Canceled order status'; $_['entry_order_hold_status'] = 'Status for hold'; ... $_['entry_hold'] = 'Hold mode'; +$_['entry_total'] = 'Lower order amount threshold'; +$_['entry_totalmax'] = 'Upper threshold of order amount'; $_['entry_fiscalization_code_field'] = 'Value for "code" parameter if fiscalization is activated (...'; Изменения в коде (uk-ua): $_['entry_geo_zone'] = 'Географічна зона'; +$_['entry_order_default_status'] = 'Статус нового замовлення'; $_['entry_order_success_status'] = 'Статус сплаченого замовлення'; +$_['entry_order_reversed_status'] = 'Статус замовлення після повернення коштів'; $_['entry_order_process_status'] = 'Статус замовлення в обробці'; $_['entry_order_cancelled_status'] = 'Статус відміненного замовлення'; $_['entry_order_hold_status'] = 'Статус замовлення, що знаходиться в холді'; ... $_['entry_hold'] = 'Режим холдів'; +$_['entry_total'] = 'Нижній поріг суми замовлення'; +$_['entry_totalmax'] = 'Верхній поріг суми замовлення'; $_['entry_fiscalization_code_field'] = 'Значення для параметру "code", якщо фіскалізацію активовано (...'; Пояснения: Новые языковые переменные для статусов: entry_order_default_status – добавлена строка для названия поля «Статус нового заказа» (англ. "New order status", укр. "Статус нового замовлення"). entry_order_reversed_status – строка для «Статус заказа после возврата средств» (англ. "Order status after refund", укр. "...після повернення коштів"). Эти строки используются в интерфейсе настроек для новых опций выбора статуса по умолчанию и статуса при возврате. Без них названия новых настроек не отображались бы в форме. Новые переменные для лимитов суммы: entry_total – метка поля «Нижний порог суммы заказа» (минимальная сумма заказа для доступности метода). entry_totalmax – метка «Верхний порог суммы заказа» (максимальная сумма заказа для использования метода). Эти текстовые переменные отображаются рядом с соответствующими полями ввода в настройках модуля, позволяя администратору понять, что означают новые поля Минимальная сумма и Максимальная сумма для оплаты Plata by mono. Все новые языковые константы добавлены без удаления старых – то есть, расширяют существующий набор настроек. Это обеспечивает корректное отображение новых опций в панели администрирования на соответствующих языках. 4. Шаблоны настроек (admin/view/template/extension/payment/mono.tpl и .twig) В шаблонах страницы настроек модуля (как для OpenCart 2.3 – файл .tpl, так и для OpenCart 3.0 – файл .twig) добавлены новые поля ввода и выпадающие списки для вновь введённых настроек. Также незначительно поправлен формат HTML в одном месте. Изменения в коде (mono.tpl - фрагменты): ... <!-- Новые поля Минимальной и Максимальной суммы --> +<div class="col-xs-12"> + <label ... for="input-total"> <?php echo $entry_total ;?> </label> + <input type="text" name="mono_total" value="<?php echo $mono_total ;?>" ... id="input-total"/> +</div> +<div class="col-xs-12"> + <label ... for="input-totalmax"> <?php echo $entry_totalmax ;?> </label> + <input type="text" name="mono_totalmax" value="<?php echo $mono_totalmax ;?>" ... id="input-totalmax"/> +</div> +<div class="col-xs-12"> + <label ... for="input-order-status"> <?php echo $entry_order_default_status ;?></label> + <select name="mono_order_default_status_id" id="input-order-status"> + <?php foreach($order_statuses as $order_status) { ?> + <option value="<?php echo $order_status['order_status_id'] ;?>" <?php echo $order_status['order_status_id'] == $mono_order_default_status_id ? 'selected' : '' ;?> ><?php echo $order_status['name'] ;?></option> + <?php } ?> + </select> +</div> ... <!-- Поле выбора статуса оплаченного заказа (существующее) --> <label ...><?php echo $entry_order_success_status ;?></label> <select name="mono_order_success_status_id" ...> <?php foreach($order_statuses as $order_status) { ?> - <option value="<?php echo $order_status['order_status_id'] ;?>" <?php echo $order_status['order_status_id'] == $mono_order_success_status_id ? 'selected' : '' ;?> ><?php echo $order_status['name'] ;?></option> + <option value="<?php echo $order_status['order_status_id'] ;?>" ... ><?php echo $order_status['name'] ;?></option> <?php } ?> </select> ...</div> +<div class="col-xs-12"> + <label ... for="input-order-status"> <?php echo $entry_order_reversed_status ;?></label> + <select name="mono_order_reversed_status_id" id="input-order-status"> + <?php foreach($order_statuses as $order_status) { ?> + <option value="<?php echo $order_status['order_status_id'] ;?>" <?php echo $order_status['order_status_id'] == $mono_order_reversed_status_id ? 'selected' : '' ;?> ><?php echo $order_status['name'] ;?></option> + <?php } ?> + </select> +</div> (Аналогичные изменения присутствуют в версии шаблона .twig – добавлены те же поля с использованием синтаксиса Twig. Отличия в .twig файле идентичны по логике: добавлены блоки с {{ entry_total }}, {{ entry_totalmax }}, {{ entry_order_default_status }}, {{ entry_order_reversed_status }} и соответствующие поля формы payment_mono_total, payment_mono_totalmax, payment_mono_order_default_status_id, payment_mono_order_reversed_status_id.) Пояснения: Поле “Минимальная сумма заказа” (mono_total): Добавлен новый input (текстовое поле) для ввода минимального порога суммы. Метка поля берётся из entry_total. Назначение: позволяет администратору указать минимальную сумму заказа, при которой Plata by mono становится доступен. Если сумма заказа меньше этого значения, метод оплаты не будет предложен покупателю (логика реализована в модели каталога). Поле “Максимальная сумма заказа” (mono_totalmax): Добавлен input для ввода максимального порога суммы заказа (метка entry_totalmax). Назначение: аналогично, но для верхнего предела – если сумма заказа превышает указанное значение, метод Plata by mono не появится при оформлении. Это реализует ограничение мин/макс суммы оплаты. Выпадающий список “Статус нового заказа” (mono_order_default_status_id): Добавлен новый <select> с опциями статусов заказа, позволяющий выбрать статус, который будет присваиваться заказу сразу после оформления (до оплаты). Метка поля – entry_order_default_status. Зачем: ранее заказ мог создаваться без явного статуса ожидания оплаты, что могло приводить к тому, что неоплаченный заказ оказывался в категории "Потерянные заказы". Теперь администратор может задать конкретный статус (например, "Ожидание оплаты") для новых заказов по Plata by mono до получения оплаты. Это изменение связано с улучшением логики отображения заказа до оплаты, предотвращая потерю заказов. Выпадающий список “Статус после возврата” (mono_order_reversed_status_id): Ещё один <select> для выбора статуса, в который перейдёт заказ в случае возврата средств по платежу. Метка – entry_order_reversed_status. Назначение: дать возможность указать специальный статус для возвращённых/отменённых платежей (например, "Возврат средств" или "Отмена платежа"). Этот статус будет использоваться модулем при обработке веб-хука возврата от Monobank, вместо прежней логики (см. изменения в контроллере каталога). Таким образом, модуль поддерживает новый статус заказа для возврата средств. Шаблон .tpl и .twig синхронизированы – изменения дублированы для обеих версий движка шаблонов, чтобы в OpenCart 2.3 (TPL) и OpenCart 3.0 (Twig) интерфейс настроек модуля был одинаковым и содержал новые поля. 5. Файл: catalog/controller/extension/payment/mono.php В контроллере платежного модуля на стороне магазина (catalog) произошли изменения в логике обновления статусов заказа при возврате платежа, а также добавлено присвоение статуса при создании инвойса (оформлении заказа перед оплатой). Кроме того, незначительно отформатированы некоторые комментарии. Изменения в коде (основные фрагменты): @@ ... функція обработки callback (webhook) ... @@ - if ($order['order_status_id'] == $this->config->get($this->prefix . 'mono_order_success_status_id')) { - $this->model_checkout_order->addOrderHistory($order_id, $this->config->get($this->prefix . 'mono_order_success_status_id'), - $this->language->get('text_status_refund')); - } else if ($order['order_status_id'] == $this->config->get($this->prefix . 'mono_order_hold_status_id')) { - $this->model_checkout_order->addOrderHistory($order_id, $this->config->get($this->prefix . 'mono_order_cancelled_status_id'), - $this->language->get('text_status_hold_cancelled')); - } + $comment_reversed = $this->language->get('text_status_refund'); + if ($order['order_status_id'] == $this->config->get($this->prefix . 'mono_order_hold_status_id')) { + $comment_reversed = $this->language->get('text_status_hold_cancelled'); + } + $this->model_checkout_order->addOrderHistory($order_id, $this->config->get($this->prefix . 'mono_order_reversed_status_id'), $comment_reversed); break; @@ ... функция создания ссылки оплаты (getCheckoutUrl) ... @@ function getCheckoutUrl($order_info, string $ccy) { + $this->load->model('checkout/order'); ... $create_invoice_response = $this->createInvoice(...); $this->model_extension_payment_mono->InvoiceInsert(... 'created' ...); + $this->model_checkout_order->addOrderHistory( + $order_info['order_id'], + $this->config->get($this->prefix . 'mono_order_default_status_id'), + $this->language->get('text_invoice_created'), + false + ); return $create_invoice_response['pageUrl']; } Пояснения: Изменение логики возврата средств: При получении веб-хука о возврате платежа (или отмене транзакции) модуль теперь использует новый статус заказа для возврата и единообразную обработку: В старой версии код (показан в удалённых строках) проверял текущий статус заказа: Если заказ был в статусе “оплачено” (успешный платеж), ему повторно присваивался статус "оплачено" (mono_order_success_status_id) с комментарием о возврате (text_status_refund). То есть статус фактически не менялся, просто добавлялся комментарий, что выполнен возврат. Если заказ был в статусе “холд” (платёж на удержании), то ставился статус "отменён" (mono_order_cancelled_status_id) с комментарием о холде отменённом (text_status_hold_cancelled). В новой версии эта логика упрощена и улучшена: Всегда используется единый статус возврата – берётся значение mono_order_reversed_status_id (новая настройка “статус после возврата”). Независимо от исходного статуса, заказ переводится в этот статус. Комментарий к истории заказа определяется условно: по умолчанию используется text_status_refund (“успешный возврат”), но если возврат произошёл с холдированного платежа (т.е. исходный статус был статус холда mono_order_hold_status_id), тогда комментарий будет text_status_hold_cancelled (“холд отменён”). Комментарий сохраняется в переменной $comment_reversed и передаётся в addOrderHistory. Причина изменений: Прежний подход не менял статус для полностью оплаченых заказов при возврате (оставлял их в статусе "Оплачен"), что могло затруднять отличить возвращённые заказы. Теперь введён специальный статус для возвратов – это позволяет явно пометить заказ как возвращённый/отменённый. Администратор может выбрать подходящий статус (например, "Возврат средств" или "Отменён") в настройках модуля. Таким образом, логика возврата стала яснее: при возврате средств заказ получает отдельный статус, а не остаётся в прежнем. Это изменение связано с добавлением нового статуса заказа для возврата в модуле. Присвоение статуса при создании инвойса (оформлении заказа): В методе getCheckoutUrl (вызывается при начале оплаты, когда покупатель перенаправляется на страницу Monobank для оплаты) добавлен вызов: $this->model_checkout_order->addOrderHistory($order_id, $default_status_id, $comment, false); Здесь $default_status_id берётся из настройки mono_order_default_status_id, а комментарий – языковая переменная text_invoice_created (добавлена в файл языка, см. ниже), обозначающая что “заказ создан”. Этот код ставит заказу статус "новый заказ" сразу после формирования счёта (инвойса) и перед перенаправлением на оплату. Кроме того, перед этим вызовом загружается модель заказа ($this->load->model('checkout/order')), чтобы метод addOrderHistory был доступен – это техническое дополнение, необходимое для выполнения смены статуса. Назначение: Теперь заказ сразу получает определённый статус (выбранный в настройках, например "Ожидание оплаты") вместо неопределённого состояния. В старой версии этого не было – заказ до подтверждения оплаты мог не получить явного статуса через историю, из-за чего в OpenCart такие заказы могут считаться "missing" (пропавшими) и отображаться в разделе "Потерянные заказы". Благодаря данному изменению исключается вероятность, что неоплаченный заказ затеряется: он будет виден в админке с заданным статусом (ожидает оплаты) до тех пор, пока клиент не оплатит или пока не истечёт время. Это реализация требования по изменению логики отображения заказа до оплаты, чтобы заказ не попадал в "Потерянные". Комментарий text_invoice_created служит для журнала истории (например, "monopay: Заказ создан"). Он добавлен для информативности, чтобы администратор видел запись, что по этому заказу сформирован счёт Plata by mono и ожидается оплата. Косметические изменения: В нескольких местах в коде контроллера изменены отступы в комментариях (добавлены пробелы после //). Эти изменения не влияют на логику выполнения, а лишь приводят код к единому стилю. Отметил это для полноты картины, хотя функционального значения эти правки не имеют. 6. Файлы языка каталога (catalog/language/en-gb и uk-ua) В файлах языка на стороне витрины (каталога) добавлен новый текст для комментария "заказ создан" при выставлении счёта, используемый в вышеописанной логике. Другие существующие текстовые константы остались без изменений. Изменения в коде (en-gb): $_['text_currency_error'] = 'Error! Invalid currency, ...'; +$_['text_invoice_created'] = 'monopay: The order has been created'; $_['text_status_success'] = 'monopay: Payment was successful'; $_['text_status_created'] = 'monopay: Invoice created but not payed yet'; $_['text_status_refund'] = 'monopay: Successful refund'; Изменения в коде (uk-ua): $_['text_currency_error'] = 'Помилка! Оплата приймається лише ...'; +$_['text_invoice_created'] = 'monopay: Замовлення створено'; $_['text_status_success'] = 'monopay: Оплата пройшла успішно'; $_['text_status_created'] = 'monopay: Інвойс створено, але ще не оплачено'; $_['text_status_refund'] = 'monopay: Здійснено повернення'; Пояснения: Добавлена языковая строка text_invoice_created: в английском – "monopay: The order has been created", в украинском – "monopay: Замовлення створено". Эта строка используется как комментарий при добавлении истории заказа, когда выставляется счёт (инвойс) и заказ получает статус ожидания оплаты. Таким образом, администратор в истории заказа увидит пометку, что заказ был создан и ожидает оплаты через Plata by mono. Остальные строки (text_status_success, text_status_created, text_status_refund и др.) не изменились. Добавление text_invoice_created заполняет пробел в описании статуса до оплаты. Эта новая строка вместе с изменением в контроллере обеспечивает информативность: сразу после оформления заказ имеет комментарий о создании счёта. Это помогает понять, что заказ и платёж находятся в стадии ожидания. 7. Файл: catalog/model/extension/payment/mono.php В модели платежного модуля (каталог) добавлена новая логика, связанная с минимальной и максимальной суммой заказа, а также небольшой корректирующий код для геозоны. Изменения в коде: if ($query->num_rows) { $show_monopay = true; } else { + $show_monopay = false; } +// Дополнительная проверка по сумме +if ($show_monopay) { + $min_total = $this->config->get($prefix . 'mono_total'); + $max_total = $this->config->get($prefix . 'mono_totalmax'); + + if ( + (!empty($min_total) && $total < (float)$min_total) || + (!empty($max_total) && $total > (float)$max_total) + ) { + $show_monopay = false; + } } Пояснения: Явная установка $show_monopay = false для неподходящей геозоны: В проверке доступности метода по географической зоне добавлен блок else { $show_monopay = false; }. Ранее $show_monopay по умолчанию и так был false (до проверки), поэтому функционально это изменение мало что меняет, но делает логику явнее. Теперь, если текущая геозона покупателя не входит в разрешённую (geo_zone), модуль чётко устанавливает флаг отображения метода в false. Влияние: это больше улучшение читаемости кода; итоговое поведение остаётся — если геозона не подходит, Plata by mono не отображается. Добавлена проверка минимальной и максимальной суммы заказа: Новый блок if ($show_monopay) { ... } выполняет дополнительную проверку по сумме заказа, но только если метод уже разрешён по предыдущим условиям (статусу и геозоне). Внутри проверяется: Настройка mono_total (мин. сумма). Если она задана и не пуста, и текущий $total заказа меньше указанного значения, то $show_monopay = false. Настройка mono_totalmax (макс. сумма). Если задана и текущий $total превышает указанный максимум, также отключается метод ($show_monopay = false). Назначение: реализовать логику ограничения по сумме заказа. Теперь администратор может ограничить использование Plata by mono для слишком малых или слишком крупных заказов. Например, можно сделать так, что Plata by mono появится только для заказов от 100 грн до 10000 грн – эти пределы задаются в новых полях настроек, и модель их проверяет. Влияние на работу: если сумма заказа вне допустимого диапазона, покупатель не увидит "Plata by mono" как способ оплаты при оформлении. Это может быть важно для ограничения мелких транзакций или, наоборот, очень крупных, по усмотрению мерчанта. Данный блок – ключевая часть реализации поддержки минимальной и максимальной суммы оплаты. Без него введённые админом значения Минимальная сумма и Максимальная сумма не влияли бы на отображение способа оплаты. Ключевые изменения и новые возможности модуля В совокупности, модификация модуля Plata by mono привнесла ряд улучшений и новых функций: Поддержка ограничения по сумме заказа: Добавлены настройки минимальной и максимальной суммы для использования метода оплаты (поля mono_total и mono_totalmax в настройках модуля). Реализована соответствующая проверка в коде – если сумма заказа выходит за пределы заданного диапазона, Plata by mono не предлагается покупателю. Это даёт мерчанту гибкость в ограничении применения способа оплаты по сумме заказа. Новые настраиваемые статусы заказа: Появились опции для выбора статусов: Статус нового заказа (до оплаты) – присваивается заказу сразу после его оформления, ещё до получения оплаты. Обычно это статус типа "Ожидание оплаты". Введение этой настройки решает проблему исчезновения неоплаченных заказов, позволяя отнести их к определённой категории и не считать «потерянными». Статус при возврате средств – статус, в который переводится заказ, если по нему произошёл возврат или отмена платежа. Вместо того чтобы оставаться в статусе "Оплачен" или "Отменён" по умолчанию, заказ может получить специальный статус (например, "Возврат средств"). Это улучшает учёт возвратов в системе. Изменена логика обработки заказа до оплаты: При переходе покупателя на оплату Monobank модуль сразу добавляет запись в историю заказа и устанавливает заказу заранее определённый статус (см. выше — статус нового заказа). Ранее заказ мог оставаться без изменения статуса до подтверждения оплаты, что помечало его как "Missing" в OpenCart. Теперь каждый оформленный заказ явно помечается, что счёт выставлен и ожидается оплата (с комментарием "Заказ создан" в истории). Это означает, что даже если клиент не завершит оплату, заказ останется в системе с понятным статусом, и администратор сможет его увидеть и обработать (например, связаться с клиентом или удалить по необходимости). Улучшенная логика возврата платежа: При уведомлении о возврате (webhook от Monobank) модуль теперь изменяет статус заказа на специально указанный "статус после возврата" и добавляет понятный комментарий ("успешный возврат" или "холд отменён"). Это облегчает технической поддержке и менеджерам понимание, что произошло с заказом: статус заказа будет, например, "Возврат выполнен" вместо того, чтобы оставаться "Оплачен". Таким образом, учёт возвратов стал прозрачнее, и исключаются ситуации, когда заказ считался выполненным, хотя деньги возвращены. Каждое из перечисленных изменений направлено на расширение функционала модуля Plata by mono и повышение надёжности его работы. В результате модуль получил новые возможности (лимиты суммы, статусы для разных этапов платежа) и устранил возможные проблемы (пропажа заказов без статуса, неопределённость при возврате средств), что должно облегчить поддержку и использование Plata by mono с OpenCart 2.3/3.0. Не знаю, нужно ли это кому-то кроме меня, но, на всякий случай, решил выложить полный отчёт и лог изменений. Вдруг разработчик решить добавить подобный функционал, но уже собственноручно. PS. Чистоту DOM не наводил. Очень хотелось, но не стал. От всех этих <select id="input-order-status"> с одинаковым id "вздрагивалось", но я себя переборол. mono_oc2_3_3_edited.zip

Панове, серйозно? Форум у 2025 році? Що далі — повертаємо phpBB, ставимо скіни під Windows XP і запускаємо чат на ICQ з унікальними номерами типу 226-030-622? Форуми — це круто… було. У 2008. Зараз це як намагатись оживити динозавра: цікаво, але марно. Хто туди реально буде писати? Три ветерани з аватарками 100×100 і підписами в стилі "User since 2007"? Давайте без цього некроманства. Нашо народжувати чергового трупа? Телеграм-канал + чат + бот — ось це формат. Зручно. Мобільно. Реальна активність, а не "останній пост — 3 тижні тому". Можна додати опитування, голосування, інтеграцію з сайтом, навіть слона — було б бажання. А якщо вже так хочеться ретро-формату — можна зробити чат в eMule або форум на uCoz. Але навіщо, якщо всі давно живуть у Telegram? Не те, щоб я був проти форума, просто для нього потрібна готова база зацікавлених людей. Не 10, навіть не 20. Або хоча б стабільний трафік. Все інше - марна трата часу, ресурсів, тобто грошей.

правильно ли я понял, что после ввода актуальных кредов и перевода с теста в бой всё заработает без необходимости каких либо правок и доп настроек? просто уточняюсь)

День добрый. Ocstore 3.0.3.7. Оформление заказа - Simple. Настраиваю оплату частями для приватбанка. Стоят тестовые креды. При оформлении заказа после тестовой оплаты картой 0000111122223333 покупателя перекидівает не на саксесс, а снова на страницу оформления заказа: index.php?route=checkout/simplecheckout Т.е. товар остаётся в корзине и нет инфы о номере заказа. Подскажите как пофиксить.

Добрий. Знайшов помилку в коді. ocFilter 4.8.2 Після імпорту товарів запускаю скрипт, згенерований безпосередньо модулем: // OCFilter copy start $this->load->controller('extension/module/ocfilter/copy', [ 'copy_attribute' => 1, // Копировать атрибуты 'copy_group_as_attribute' => 0, // Группы атрибутов как фильтры 'copy_attribute_id_exclude' => 0, // Данные для копирования 'copy_attribute_group_id_exclude' => 1, // Данные для копирования 'copy_attribute_category_id_exclude' => 1, // Данные для копирования 'copy_filter' => 0, // Копировать стандартные фильтры 'copy_option' => 0, // Копировать опции товаров 'copy_option_in_stock' => 1, // Только в наличии 'copy_type' => 'checkbox', // Тип скопированных фильтров 'copy_dropdown' => 0, // Поместить в выпадающий список 'copy_status' => 1, // Статус скопированных фильтров 'copy_truncate' => 0, // Очистить существующие фильтры OCFilter 'copy_category' => 1, // Привязать фильтры к категориям 'copy_cron_wget' => 0, // Команда для вызова по cron (планировщик) 'copy_value_separator' => ['|'], // 'copy_attribute_id' => ['127', '15', '70', '52', '73', '125', '12', '49', '121', '39', '13', '54', '23', '18', '154', '45', '68', '107', '47', '37', '42', '1', '19', '38', '71', '40', '17', '155', '44', '53', '78', '109', '112'], // 'copy_attribute_group_id' => [], // 'copy_attribute_category_id' => [], // ]); // OCFilter copy end Но в ocfilter.log наступний текст: 2024-03-29 6:00:30 - [Attribute condition] WHERE attribute_id IN(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32) якщо ж копіювати фільтри безпосередньо в модулі, то все корректно: 2024-03-29 5:32:56 - [Attribute condition] WHERE attribute_id IN(127,15,70,52,73,125,12,49,121,39,13,54,23,18,154,45,68,107,47,37,42,1,19,38,71,40,17,155,44,53,78,109,112) Помилка була в admin/model/extension/module/ocfilter/filter.php Замість: $attributes_id = array_filter(array_unique(array_keys($data['copy_attribute_id'])), 'intval'); прописав: $attributes_id = array_filter(array_unique($data['copy_attribute_id']), 'intval');

Боты гугла часто ходят с IP USA.

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

если то с вероятностью приближенной к 100% поле обрабатывается контроллером. в нём и можно глянуть откуда берётся значение. Вероятнее всего в БД сохранен адрес в конфигах для вывода в футере, например, или на каких-то доп. страницах.

Логично, но есть одно НО Тогда и на фронте будет отображаться та почта, с которой идёт отправка. А ему нужно чтобы отправлялось с одной но ему писали на другую (ту, что показана на сайте)

Вам же только from нужно исправить, так что поправочка - 28 правок в 19 файлах:

Добрый. Я так понимаю модуль всё? Или можно брать? Какая версия PHP и IonCube требуемая? PHP 7.3 IonCube 12.0.5 Заведется?

По причине того, что поле username это, в зависимости от службы, не всегда почта - опенкарту при отправке письма нужно от чего-то отталкиваться, чтобы наверняка указать отправителя. И единственное поле, где email указан с вероятностью 146% - Система->Настройки->Магазин->E-mail Но Вы, естественно, можете захардкодить этот момент. Везде, где используется отправка письма (а это около 100 правок в примерно 40 файлах) вместо: $from = $this->config->get('config_email'); $mail->setFrom($from); Сделать что-то вроде такого: $mail->setFrom($this->config->get('config_mail_smtp_username')); Сработает, естественно, в случае, если у Вас username это почта.

Масло масляное. Бесполезная строка не выполняющая ничего. В скрипте у Вас функция hpm_select вызывается дважды. 1. При клике по элементу с классом .hpm-cat-item 2. При изменении значения селекта внутри элемента с классом .hpm-cat-box В качестве параметра передается $(this), т.е. непосредственно элемент. И с вероятностью 146% ни селект ни .hpm-cat-item не содержит data_meta_h1. Если я правильно понимаю Вы пытаетесь в модуле HPM в категории при смене товара-опции чтобы менялся и мета тег h1, но это не корректно. Тег h1 должен быть единственным на странице. Т.е. в категории в качестве H1 будет показываться (и должен показываться) meta_h1 (и при его отсутствии name) именно категории, а не товара. Вы бы лучше первоначальную задачу описали, что именно Вы делаете?

Я ж не писав "нашо вам таке на сайті?", а доволі точно задав питання : "нашо вам модуль?" Ваша побажанка це виправлення 3-х рядків коду вашої теми. Розумієте?

Не зовсім зрозуміло навіщо модуль? Це ж стандартний функціонал опенкарту - рекомендовані товари в категорії: Різниця лише в тому, що показ цих товарів буде не картками, а списком - 2 рядки коду в twig. Тобто виводити назву та ціну замість повного змісту (фото, опис, наявніть й іньше) PS. Можливо ще знадобиться 3 рядки jquery докрутити, щоб була функція "приховати/показати", але то вже прикраси.

А я разве это оспариваю? Просто Вы оказались быстрее))) Я не видел Вашего сообщения, пока не опубликовал своё)

Капец вы тут понаписывали ) Ещё раз - не нужно никаких дополнительных кнопок и прочего. Основа уже есть - товар не в наличии. Осталось только в категории скрыть товары, которых нет в наличии: Одна строка в коде. Ответу 12 лет но актуальность его от этого не приуменьшилась Ну и модуль есть: И модуль и тема про опенкарт 1.5, но суть, я думаю, вы уловите если скачаете модуль и посмотрите что он делает (если есть навыки конечно)

Не совсем понял (точнее совсем не понял) что Вы хотели увидеть при отключении товара? Ну вот есть товар, у него есть ссылка. Вы хотите но при этом Это как? Ну т.е. поисковик перешел по ссылке и что? Что на странице то показывать? Для СЕО лучше не отключать товар, а сделать невозможным его покупку. Т.е. установить количество равное 0 и запретить в настройках продажу при отсутствии. В этом случае товар открывается по ссылке. Но купить его нельзя (он псевдоотключен). Во всех других случаях - вполне ожидаемая 404. А 404 означает обязательное удаление из индекса. Пусть лучше пользователь перейдёт в карточку товара, которого нет в наличии и останется на сайте и, возможно, подберет у вас замену, чем вообще не попадёт к вам на сайт )))

Если я правильно понял логику, то если я уберу строку мультиязычности, то Ваш скриппт не поймёт что pd.name_rozetka и pd.short_description нужно брать для language_id = 2, так как для ru у меня эти же поля, но с language_id = 1. А вот вариант с правками в структуре действительно правильней. Спасибо! Просто у меня там в настройках вот такое уже: Но сам факт того, что на основании кастомных полей, можно создать полноценную выгрузку - прям огонь. Ещё разбираюсь в настройках, так как некоторые из существующих полей тоже сделаны слегка рукожопно (те же pd.name_rozetka и pd.short_description) и вот думаю как это всё дело сделать красиво, чтобы было удобно добавлять новые выгрузки и так же легко их отключать.

Угу. С этим разобрался. В цикле задал замену и unset В таком случае логичней бы было в 4.2 указывать в fields не просто значения а массив - поле-значение, т.е. как-то так: $data['lang_data'] = array('lang_id' => 2, 'fields' => ['name' =>'name_rozetka', 'description' => 'short_description']); Но это уже вкусовщина, да.

Возник вопрос: В помощи написано У меня вместо name и description используются кастомные name_rozetka и short_description Т.е. для реализации мультиязычности нужно в пункте 4.2 прописать: $data['lang_data'] = array('lang_id' => 2, 'fields' => 'name_rozetka, short_description'); Что я, собственно и делаю. Пример - товар с id 22227 В БД заполнено для двух языков: Но в фиде рисует пустые теги name_ua и description_ua Подскажите, ЧЯДНТ. Сразу спасибо за ответы. По всему остальному, вроде, вопросов нет. )

Вітаю. Чи є можливість відібрати товари за значенням поля в БД? Дивіться. Є реалізація додавання товарів до того чи іньшого фіда одним кліком (відео під спойлером): В БД велика кількість товарів і додавати їх безпосереднью в фід в модулі буде (мені здається) не дуже зручно. тобто вказати ((p.status_roz)) == '1' Чи, можливо, можна, наприклад, вказати функцію, як в модулі Simple. Тобто я напишу функцію get_ids_for_feed("rozetka") яка буде повертати потрібні product_id, і просто вкажу її. Чи то я забагато хочу?

ХМ. У Вас же просто опис XML для offers. Классичний. Як ви дізнаєтеся досвід програміста за шматком шаблонного XML? Але то таке... На ваш розсуд Цитую: Нашо вам той FTP, якщо у "Таблеточки" э API? З повноцінним блек-джеком і шлюпками JSON замість застаріваючого з кожним днем XML? А якщо реалізувати звїязок через API, то початкове ТЗ в корні не вірне. Точніше вірне для того, хто зрозумів можливості "таблеточок" по своєму. Задля розуміння. Я не візьмусь, якшошо. Навіть не претендую на співпрацю, але просто вирішив залишити коментар відносно ТЗ і XML

Вы всё время копаете не в ту сторону. Опенкарт, как и ocStore ВООБЩЕ не определяет устройство, с которого Вы заходите на сайт. Эта часть заголовков ему не интересна, разве что Вы собственноручно установили како-то модуль/дополнение/скрипт, который может это делать. Но с вероятностью 99.99% подобные "определения" служат для других целей (адаптация, разные шапки, меню и прочее), но точно не для "убийства" сессии... Как вариант - где-то в настройках Андроида включена опция - очищать историю браузера при закрытии. Т.е. при закрытии браузера очищается кеш. Логично, что в таком случае авторизация будет слетать. ЗЫ. Начал писать это сообщение в 2:02 - в это время авторизовался с мобильного на Вашем сайте. Свернул браузер на 28 минут. И вот сейчас в 22:30 открыл браузер - я всё ещё авторизваон. Дополнительно отпишусь утром (если не забуду) ЗЗЫ. Отправил вам в личку видео из которого видно, что проблема не в ocstore.