drOC

Це помітив що з емейл сповіщень відбувається пересилання

Взагалі можна для зображень створити окремий статичний сервер / хмару, просто як варіант. Наприклад оригінали зберігаються з ФТП, а кеш на продакшн. Можна зробити щоб оригінали взагалі використовувались з оригінального сервера (якщо немає ймовірності їх видалення звідти). З поточними швидкостями оптики можна дедікейтед вдома зробити на распбері, взяти диск на 1 Тб і не паритись. Коротше поставте собі той клінер платний і подивіться що він видасть. Головне щоб не повісився на таких об'ємах. В мене був перевірений модуль в закладках, але він виявився кацапським тому не ділюсь посиланням, інші нажаль ще не дослідив щоб порадити. Бажано щоб модуль клінінгу був з відкритим кодом (без іонкуб) тоді його можна допрацювати під свої потреби. Я б нічого не ресайзив / не стискав (навпаки поставив якість 100%), просто поклінив би сміття і допиляв той модуль імпорту щоб заново мені їх не завантажував. Думаю скоріше за все більшу частину диску з'їдає саме тека з оригіналами а не кешем.

Я просто стикався з таким, що скрипт імпорту наплодив за два роки тільки щоденних дампів csv на 20 гб, не здивуюсь якщо те само й зображеннями. Опенкарт не видаляє зображення при видаленні товарів, ніяких тулзів чи алертів стосовно їх контролю застосування.. Головне щоб той платний клінер не повидаляв зображення із кастомних модулів, які він не підтримує з коробки.

Ну так і питав спочатку що схоже якись скрипт імпорту забиває. Тут треба оптимізація цього скрипта бо все інше - не причини а наслідки. Ну і пережати / проклінити те що наплодив той скрипт вже. Я чомусь впевнений що у вас там купа зображень без прив'язки. Типовий випадок для багатьох чудо-модулів. Писав вище.

Так, це тимчасове рішення ціною процесорного часу. Якщо так, то думаю самий простий варіант це спробувати зменшити якість тут (або краще всюди де ця функція передає атрибут quality або просто переписати цей атрибут у функції нижче, для тесту вистачить) /system/library/image.php public function save($file, int $quality = 90) { // зменшити quality Або дійсно взяти максимальний розмір зображень зуму і зменшити якимось скриптом локально, потім перезалити на сервер.

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

ну в теорії достатньо додати обмеження в htaccess чи nginx, але не знаю чи на таку "дрібницю" звернули увагу коли робили

Цікаво чи взагалі цей ватермарк захищає бо в опенкарті оригінали наче можна напряму забрати бо все у корені лежить

У випадку опенкарт завжди простіше поставити чисту версію, шаблон і перевстановити модулі.

Можливо знову рядовий випадок з недоступним SMTP сервером через перевищення квоти. Але журнали скажуть більше

Пережати це змінити розмір чи саме стиснення JPEG зменшивши якість? Якщо стиснення то в одному рядку в коді це змінюється, після чого треба кеш видалити і дочекатись поки ті 150 Гб перекешуются самі. Взагалі є модулі клінери, може варто просканувати зображення які не використовуються і видалити їх - може якийсь скрипт імпорту наплодив.

Ну так для цього і пропоную використовувати брідж (міст) для різних БД а не займатись інтеграцію куди більшої кодової бази. Другий інстанс опенкарт можна налаштувати на віртуальний каталог або фізично його там розмістити. Коротше вам варто поставити чистий опенкарт під той модуль, купити / встановити його і далі вже синхронізувати бази покупців (customer) Так у вас буде щонайменше офіційна підтримка модуля від розробника (якщо він її надає) і мінімум мороки з інтеграцією. Просто на чистий рушій поставити поряд.

це в комерційний розділ або пишіть в приват. і додайте скріншоти що куди перенести + посилання на сайт

Який шаблон?

Схоже на зламану логіку модулів групи тотал. Хтось щось надлубав у формі замовлення а в адмінці не встиг.

Доброго вечора, зараз часто виключають світло і я не встигаю за всім, можу відповідати не одразу. який у вас зараз магазин на двійці (можна посилання) і чому вам треба саме на нього інтегрувати а не поставити на трійку поряд? там спільна база акаунтів чи у чому справа? я б поставив поряд на трійку просто на чистий магазин і що треба можна синхронізувати між двома опенкартами.

Якщо сподобався саме цей модуль то пишіть автору - може портує на двійку (враховуючи сумарну кількість продажів для 3-4) Можна ще ризикнути купити і створити запит в комерційний розділ, думаю реально змінити twig на html, звісно якщо потрібний код виявиться не закритий через ioncube - оцінка вже по факту бо треба дивитись що під капотом по ФТП. Або створити сервіс на трійці та інтегрувати його з вашою двійкою через брідж.

а в оксторі тільки товари можна зробити без вкладення? не пам'ятаю але гляньте що там в основних налаштуваннях адмінки

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

Ну міняти тип поля в базі не правильно бо не відомо як будуть працювати розширення як мінімум оплати/доставки/тоталс, плюс цінова логіка буде передана середовищу сервера, що матиме наслідки. Якщо досвіду мало, то шукайте розширення або зверніться в комерційний розділ (можу зробити) Це у вас мабуть якийсь скрипт імпорту "на сиру" передає дані? Моя думка однозначна: зміна типу цінового поля може створити більші проблеми ніж неправильне округлення зараз.

Не треба міняти тип поля в БД, відкоректуйте де треба через модифікатор https://www.php.net/manual/en/function.ceil.php https://www.php.net/manual/en/function.floor.php

Модулі групи total пробували вимикати?

Так буває. У вас мабуть друга версія без twig? Боротийсь в опенкарті або вручну або шукати костилі. Може спробуйте екранувати через зворотній слеш (\), хоча це питання шаблонізації і htmlentities

Схоже на черговий конфлікт модифікаторів, пишіть доступи в приват якщо попередній розробник більше не на зв'язку - можу на платній основі вирішити

Проблему вирішили локально через setlocale / LC_NUMERIC Суть була в тому, що опенкарт форматує дробні числа в форматі string через кому і MySQL некоректно їх інтерпретує