Leaderboard

Нова версія Deals 1.8.0 У головних налаштуваннях шаблону у вкладці “Картка товару” додане нове налаштування “Блок опису виробника”. Цей блок дозволяє вивести логотип та кастомізувати під будь-якого виробника будь-яку інформацію. Можна налаштувати один блок для всіх виробників або для деяких — свій кастомний блок. Підтримується HTML. У модулі Smart Checkout додана можливість запам’ятовування основних полів гостей при оформленні замовлення. У модулі Smart Checkout додана можливість додати фільтр по виробнику до будь-якого методу доставки. Покращено сумісність з модулями від Prorab: Нова Пошта, Укрпошта, Rozetka Delivery. Додано можливість вивести адміністратору та покупцю номер ТТН на сторінці інформації про замовлення. Додано можливість вивести адміністратору та покупцю посилання на трекінг посилки на сторінці інформації про замовлення. Додано можливість адміністратору або менеджеру в 1 клік відправити покупцю SMS з номером ТТН та посиланням на трекінг, попередньо налаштувавши в модулі “SMS Notify” відповідний шаблон. Покращено лист покупцю при оформленні замовлення. Покращено вивід інформації про замовлення для покупця — додано зображення та посилання на товари у списках товарів. Виправлено дрібні помилки та проведено загальні покращення. Додані\Оновлені файли: Завантажити останню та актуальну версію шаблону, ви можете у центрі підтримки: https://octemplates.net/ Інструкція з оновлення тут: https://dsdocs.octemplates.net/update Настійно рекомендуємо перед оновленням зробити резервну копію сайту (файли + база даних через PHPMYADMIN). За необхідності звертайтеся до нашої технічної підтримки. Ви можете замовити платну послугу оновлення шаблону до актуальної версії. Нова версія шаблону це: виправлення та покращення функціоналу + нові модулі та рішення. Увага! Якщо Ви вносили/вносите нестандартні та кастомізовані редагування у файли нашого шаблону, то Ваші доробки будуть затерті при оновленні.

Для цього ТЗ достатньо цього модуля плюс обрати додаткові послуги(беріть за $50), щоб автор все це налаштував на вашому сайті. Тож за 80 доларів це ТЗ закриєте повністю Та і самого автора модуля рекомендую на доробки. Коли було мало часу, та не знав як швидше і краще зробити замовляв в нього доробки - дуже добре все зробив.

Добрий день, пропоную подумати над ЛК покупця. Наразі ваші шаблони прокачені дуже круто і є реально готовими ІМ (додай товари, доставки, підключи оплату і уперед) але сам ЛК скрізь (не лише у вас) без уваги, лише стилі, та легесенька косметика як правило Частий запит від кліентів не бачу номера ттн у ЛК Частий біль продавців (кліент вказуе у лк номер відділення наприклад НП 4, і так з ним оформлює замовлення і це додае роботу менеджеру із перевиправленням відділення, а головне кліент у такому випадку не побачить реальну вартість доставки, якщо увімкнено розрахунок по api) Прохання наступне: Додати підтримку шипінг дата по способу доставки та адресам для модулів від @Prorab337 (хочаб один аби зберігавля та синхрогизувався) Приклад: У ЛК кліент вибирає через селект спосіб доставки і по принципу як у кошику це зберігає, але тре щей залежності із бд по id відділення протягнути ( бо однієї назви мало буває що НП змінює назву відділення і при оновленні БД модулів доставок аби оновлювалися і самі адреси, при оформленні замовлення у кошику всі поля відразу переоновляться) Цикл з ваших модулів стане ідеальним. Всі будуть у задоволені

Граница 1. Поиск замена. Удалить границу 2. Прописать эту замену. В Предпросмотре не увидите результат. Только уже на сайте https://prnt.sc/YoL3zBLOmbB_

Добрый день. В модификаторах тоже выключили?

Це НЕ кеш. Це ресайзи зображень. Це різні речі. Уніфікуйте розміри (наприклад замість 80х80, 85х85, 90х90 - один розмір 90х90, це суттєво зменшить кількість файлів, бо замість 3-х комплектів ресайзів, буде 1) І ресайзи не можна видаляти, бо на їх генерацію витрачається багато ресурсів сервера (cpu та т.п) та ще вони знаходяться в індексу пошукових систем

Для OpenCart 4 нема адаптованих модулів на даний момент

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

Те що ви пишете повна фігня. 1) Модуль чудово працює на багатьох проектах. 2) Є Відео інструкція, текстова інструкція, величезний топік з розбором всіх можливих помилок, допомога від автора. Якщо є проблема у вас (доречі яка дуже легко вирішується) це не значить що проблема в модулі чи авторі. Трошки подумайте головою і все буде добре , а якщо немає часу думати то заплатіть комусь 40 доларів хай подумають за вас.

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

Лучше напишите мне (разработчику UniXML) задание в ЛС я посмотрю

Скачал модуль для 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

@Allaur Вам нічого не жме? https://banapal.ru/11-3-senezh-effo-kan-10-kg-senegeffo10kg/?utm_source=yandex.direct&utm_medium=cpc&utm_campaign=test Вам мало КАБів, балістики чи дронів на місто?

скрипт, который скрывает все ряды кнопок, начиная со второго, и добавляет кнопку "Показать ещё" для их отображения актуально для категории. но в карточке тоже отлично работает $(document).ready(function () { $showMoreButton = $("<button class='show-more-hpmr'>Показати ще</button>"); $('.hpm-button-wrapper').each(function(){ const $buttons = $(this).children(); let rows = 1; let prevOffsetTop = $buttons.first().offset().top; $buttons.each(function () { if ($(this).offset().top > prevOffsetTop) { rows++; prevOffsetTop = $(this).offset().top; } }); if(rows > 2) { const firstRowHeight = $buttons.first().outerHeight(true); $(this).css('max-height', firstRowHeight + 'px'); $(this).css('overflow', 'hidden'); $showMoreButton.insertAfter($(this)); } }); $(document).on('click', ".show-more-hpmr", function() { $(this).prev().css('max-height', '111111px'); $(this).remove(); }); });

але Можуть шукати SR-1090 або SR 1090 також тому тут потрібно щось більш релевантне на кшталт

так завжди в Опенкарт. встановіть цей модифікатор

Вітаю. В файлі system/library/unixml.php знайдіть рядки по словосполученню $sql .= ", (SELECT CONCAT( там буде два рядки //$sql .= ", (SELECT CONCAT( $sql .= ", (SELECT CONCAT( вам треба зробити навпаки, тобто два слеша поставте внизу а зверху приберіть, щоб було так $sql .= ", (SELECT CONCAT( //$sql .= ", (SELECT CONCAT(

Понизьте версію PHP Наприклад 7.4

Попробуйте через Обработчик xml. https://prnt.sc/MuEzsyESlqdc Начало парсинга *********Наименование товара******** Конец парсинга *********склад********{skip}</td> Или так *********Наименование товара******** Склад 1</span> Звездочки можно не прописывать

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

На сторінці продукту де виводиться фото товару Додаємо <div class="col-sm-6"> {{ block_image }} {% if special %} <!-- це те що додаеться - Додаємо елемент для слова "Акція" --> <span class="promo-label">Акція</span> <!-- Додаємо елемент для різниці в ціні --> <span class="price-difference"></span> {% endif %} </div> Далі перед footer додаємо <script> // Обчислення різниці в ціні document.addEventListener('DOMContentLoaded', function() { const oldPrice = parseFloat(document.querySelector('.price-old').textContent.replace(' грн.', '')); // 360.00 const newPrice = parseFloat(document.querySelector('.price-special').textContent.replace(' грн.', '')); // 300.00 const difference = oldPrice - newPrice; // 60.00 // Додаємо різницю в ціні до елемента const priceDifferenceElement = document.querySelector('.price-difference'); priceDifferenceElement.textContent = `-${difference.toFixed(2)} грн.`; }); </script> Далі у файл стилі додаємо .promo-label { position: absolute; top: 10px; left: 10px; background-color: red; color: white; padding: 5px 10px; font-size: 16px; font-weight: bold; border-radius: 5px; z-index: 1000; } /* Стилі для різниці в ціні */ .price-difference { position: absolute; top: 50px; left: 10px; background-color: #333; color: white; padding: 5px 10px; font-size: 14px; font-weight: bold; border-radius: 5px; z-index: 1000; } У категоріях та модулях основний перший код буде виглядати скоріш за все так <div class="product-list__item...........> {% if product.special %} <!-- Додаємо елемент для слова "Акція" --> <span class="promo-label">Акція</span> <!-- Додаємо елемент для різниці в ціні --> <span class="price-difference"></span> {% endif %} </div> Далі <script> теж треба вставити та стилі будуть вже ті самі Можливо треба зробити так <script> document.addEventListener('DOMContentLoaded', function() { // Знаходимо всі товари з акцією const products = document.querySelectorAll('.product-list__item'); products.forEach(product => { // Перевіряємо, чи є акція (наявність .price-old і .price-new) const oldPriceElement = product.querySelector('.price-old'); const newPriceElement = product.querySelector('.price-new'); const priceDifferenceElement = product.querySelector('.price-difference'); if (oldPriceElement && newPriceElement && priceDifferenceElement) { // Отримуємо значення цін const oldPrice = parseFloat(oldPriceElement.textContent.replace(' грн.', '').replace(',', '.')); const newPrice = parseFloat(newPriceElement.textContent.replace(' грн.', '').replace(',', '.')); const difference = oldPrice - newPrice; // Встановлюємо різницю в ціні priceDifferenceElement.textContent = `-${difference.toFixed(2)} грн.`; } }); }); </script> Для featured працює так Все зроблено за допомогою ШІ

Потрібно оновити файли модулю

Добрый день! Искала информацию о дроппшипинге, нашла ваш сайт. Наша компания импортирует оборудование по дерево и металло обработке из разных стран. Можем быть поставщиками для дроппов. Наш сайт https://slavles.com.ua/ua/ т. 0996444073 Наталья

Радив би періодично вимикати VPN, щоб не збиватись з курсу!

Таке питання краще задайте в темі підтримки шаблону

За допомогою даного модуля ви можете реалізувати опції як окремі товари, створивши безліч товарів з різними характеристиками та зв'язати їх. Якщо в OcFilter є функція, щоб не відображати товари яких немає в наявності при фільтрації, тоді це буде працювати. Так як товари, які розкупили з потрібними характеристиками, будуть не в наявності.

@maaby записал, добавлю в обнову спасибо

Доброго. Модуль прив'язаний (та "трігерує") до кук (можна прописати в налаштуваннях, навіть "свої"). В рамках однієї сесії (а це вже session) - ні. А кукі не прив'язані до сесій. Я рекомендую не слухати SEO-шника (popup вибори мови ніяк не вливає на SEO), а робити як на демо.

він не купував, а вкрав ломаний

Доброго дня \admin\model\sale\receipt.php метод getProductNameByLanguageId замість 'name' предеати 'meta_h1', або іншу назву, якщо у вас це поле по іншому назване

В адресной строке Chrome введите: chrome://flags В строке поиска на странице введите: Auto Dark Mode for Web Contents ыберите Enabled и перезагрузите браузер.

@egortide Открываете файл /admin/view/template/catalog/simplepars_productsetup.twig находите там строку <option value="5" <?php echo @($setting['thread']==5)?'selected':''?>>5 потоков</option> И после нее добавляете <option value="10" <?php echo @($setting['thread']==10)?'selected':''?>>10 потоков</option> После этого у вас в меню появится возможность выбрать 10 потоков. Только не забудьте обновить кеш. Затем идете в /admin/model/catalog/simplepars.php находите строку. $links = $this->db->query("SELECT link FROM ". DB_PREFIX ."pars_link".$where." AND scan=1 ORDER BY id ASC LIMIT 0,5"); И заменяете ее на $links = $this->db->query("SELECT link FROM ". DB_PREFIX ."pars_link".$where." AND scan=1 ORDER BY id ASC LIMIT 0,10"); И все теперь модуль может работать в 10 потоков в парсинге в им.

Логика правильная. Но так(закрыть в роботс) пишут те, кто с яндексом работает. Я с ним не работаю.