Edvard

Що можна сказати про версію 3.0.5.0 після порівняння різниці з попередньою. У гілці Opencart 3.х з якою було злиття, виправлено помилки, яким вже декілька років та які переходили з версії до версії. Підвищені системні вимоги для роботи - PHP8.1+. Ніяких покращень, нових можливостей не виявлено. Резюме: нових можливостей, покращення дизайну та взаємодії з користувачем - немає виправлена частина помилок але не всі підвищені системні вимоги без будь-яких покращень у коді та дизайні немає необхідності для переходу, якщо використовуєте модулі та шаблони без підтримки PHP8.1

Треба вирішити питання - скільки потрібно тягнути старих проблем та копіювати недоліки оригіналу? Підняли системні вимоги для версії 3,x - втратили сумісність, робота майже всіх старих модулів та шаблонів для гілки 3.x буде проблемною, особисто дякуємо авторам які використовують ioncube. Сумісність в любому випадку буде часткова. Може настав час зробити щось краще ніж було? Відмовитись від "покращень" автора Opencart які тільки дратують та не мають нічого спільного з зручністю використання. Не треба переносити авторські "знахідки та рішення". Хай це буде окрема гілка продукту, краща ніж оригінал, який останнім часом перетворюється на додаток для показу реклами та продажу своїх послуг. З чого треба почати. Виправити усі відомі помилки. Привести форматування коду до єдиного стилю. Оновити системні компоненти до останніх версій хоча б у межах гілки, це найбезболісніше, нічого не зламає. Bootstrap v3.3.7 до Bootstrap v3.4.1, Jquery v3.7.1 (присутній в 3.0.5 але є нюансы, весь JavaScript застосовує старі (deprecated) конструкції), jquery-sortable.js та Sortable.js замінити на сучасну Sortable 1.15.7 (JavaScript треба буде поправити де застосовується перетягування та разом виправити в цих шаблонах інші помилки). Замінити Summernote на CKEditor або TinyMce або додати нормальні редактори як альтернативу з можливістю вибору що використовувати. Видалити блог або доробити його до логічного завершення. Видали рекламу (promotion) та маркетплейс з адмінки. Кінцевим користувачам цей функціонал не потрібен зовсім. Дуже приємно чекати завантаження сторінки, коли сервер не відповідає. Якщо є бажання зробити краще, то можно продовжити з переліком помилок, опечаток та іншим. Якщо треба просто поміняти циферки у версії, то не треба даже починати. Залишайте як є.

Нет там мультиязычности. Да и сам блог, мягко говоря, не очень. Блог - это наспех переделанные файлы категорий и товаров с кучей ошибок и мусора. По хорошему его лучше вообще удалить, чем использовать в таком виде.

Це не єдиний випадок, коли ви побачити цю помилку. В коді повно місць де звернення йде без перевірки існування або присвоювання без попереднього створення (ініціалізації). PHP8+ не допускає такої поведінки. Ваше рішення дозволить лише завантажити файли svg через файловий менеджер, но не дозолить їх використовувати ні в адмінці ні на фронті. Хіба що, ви використовуєте якесь стороннє рішення, яке дозоляє використовувати файли svg. Проблема в тому, що в шаблонах які відповідають за вивід html не задан розмір зображень (ширина та висота). Буде багато сюрпризів при відображенні. Також svg файли обов'язково повинні перевірятися перед завантаженням, тому що вони можуть містити шкідливий код, та сторонні скрипти.

Помилка в admin/controller/tool/backup.php префікс бази жорстко прописаний oc_user if ($i > 0 && (substr($line, 0, 24) == 'TRUNCATE TABLE `oc_user`' || substr($line, 0, 30) == 'TRUNCATE TABLE `oc_user_group`')) { треба замінити на if ($i > 0 && (substr($line, 0, 24) == 'TRUNCATE TABLE `' . DB_PREFIX . 'user`' || substr($line, 0, 30) == 'TRUNCATE TABLE `' . DB_PREFIX . 'user_group`')) {

Між версією 7.3 і вище та 8.х різниці в швидкості ви не помітите. А проблеми побачите 100 відсотків. Напевно у вас є модулі та шаблон відмінний від того, що замовчуванням. Вони теж повинні підтримувати старші версії PHP. Якщо бажаєте оновити сам Ocstore, то скачайте останню версію https://github.com/ocStore/ocStore/tree/3.0.x.x, створіть дві папки: одну зі своїм старим кодом, другу з новим, що скачали. Скористуйтесь программою для порівняння, наприклад, WinMerge або Beyond Compare. Внесіть зміни. Переверти працездатність по завершенню.

Сенс оновлюватися є коли з'явилися нові можливості та виправлені помилки. Не першого ні другого там не має. Працює - не чіпайте. Нічого, крім додаткових проблем, оновлення вам не добавить. В оригінальний 3.x версій зараз знаходять помилки, які вже ювілеї відсвяткували. Знаходять та виправляють так повільно, що цей процес затягнеться на багато років. Не довіряйте списку того що зроблено, таке враження що його зібрали зі всіх згадувань про проблеми та їх "вирішення" (яки насправді не вирішили) від першої версії до теперішнього часу. Якщо є велике бажання - використайте програми які можуть провести зрівняння файлів по їх змісту та порівняйте відмінності між цими версіями. Результат вас здивує - в оновленні немає сенсу!

@OcBox модуль работает, но в отчете отображаются битые ссылки вида домен/desktops/catalog/view/javascript/bootstrap/css/bootstrap.min.css домен/desktops/catalog/view/javascript/font-awesome/css/font-awesome.min.css и т.д. В отчете куча битых ссылок вида домен/чпу_категории/catalog/view/* (шрифты, скрипты, файлы стилей) Но на самом деле таких ссылок не существует. desktops это ЧПУ категорий и в реальности такого адреса с ссылкой на файлы *.css, *.js и другие не существует.

Не знаю, яку користь несе ваше повідомлення? Але бачу по лайках, що воно дуже корисне та змістовне. Набагато корисніше повідомлень про помилки, проблеми чи їх вирішення. Необґрунтована заява. Будь-який модуль / шаблон, який продається тут на форумі містить купу помилок. І це платні рішення! При цьому більшість закодовані ионкубом або обфусцовані. У авторів через високе почуття власної важливості та замиленості очей не вистачає часу, бажання тощо, виправляти помилки. Тут безкоштовний модуль із відкритим кодом і що його допомагало написати – не має значення.

Причина ошибки, указанной в сообщении выше В классе Boximageoptimizer отсутствует метод getLastSkipReason(), при этом контроллер использует его для статистики пропусков. Нужно добавить в /system/library/boximageoptimizer.php // добавить свойство private $last_skip_reason = '' ; //добавить метод public function getLastSkipReason () { return $this -> last_skip_reason ; } //Исправить метод addToQueue public function addToQueue ( $file , $priority = 5 ) { // сброс причины пропуска $this -> last_skip_reason = '' ; $path = $this -> getFullPath ( $file ); if (! file_exists ( $path )) { $this -> last_skip_reason = 'file_not_found' ; return false ; } $check = $this -> db -> query ( " SELECT queue_id FROM `" . DB_PREFIX . "box_image_optimizer_queue` WHERE file_path = '" . $this -> db -> escape ( $file ) . "' " ); if ( $check -> num_rows ) { $this -> last_skip_reason = 'already_in_queue' ; return false ; } $hash = md5_file ( $path ); $logCheck = $this -> db -> query ( " SELECT log_id FROM `" . DB_PREFIX . "box_image_optimizer_log` WHERE file_path = '" . $this -> db -> escape ( $file ) . "' AND file_hash = '" . $this -> db -> escape ( $hash ) . "' AND status = 'success' LIMIT 1 " ); if ( $logCheck -> num_rows ) { $this -> last_skip_reason = 'already_optimized' ; return false ; } $info = @getimagesize ( $ path ); $this -> db -> query ( "INSERT IGNORE INTO `" . DB_PREFIX . "box_image_optimizer_queue` SET `file_path` = '" . $this -> db -> escape ( $file ) . "', `file_hash` = '" . $this -> db -> escape ( $hash ) . "', `file_size` = " . ( int ) filesize ( $path ) . ", ` width ` = " . ( int ) ( isset ( $ info [ 0 ) ) ? $ info [ 0 : 0 ) . = " . ( int ) ( isset ( $ info [ 1 ) ) ? ` mime_type ` = ' " . $this -> db -> escape (isset ($info [' mime '])? $info [' mime ']:''). "' , `status` = 'pending' , `priority` = ". (int) $priority. " , `created_at` = NOW (), `updated_at` = NOW () "); return $this -> db -> countAffected() > 0 ; } Также желательно подправить addToQueue() так, чтобы он выставлял причину ошибки (заделы на предстоящие улучшения). Текущая реализация addToQueue() возвращает только true/false, но не сообщает причину false: return false, если файл не найден return false, если уже есть в очереди return false, если уже оптимизирован (по логу) Контроллер различает только: already_in_queue already_optimized "второе" Еще одна ошибка: в addToQueue() используется таблица box_image_optimizer_* , а в resetAll() очищаются другие таблицы с именами box_imageoptimizer_* , что не соответствует реальным именам в базе. В коде public function resetAll() { $tables = array( 'box_imageoptimizer_queue', 'box_imageoptimizer_stats', 'box_imageoptimizer_log' ); Должно быть public function resetAll() { $tables = array( 'box_image_optimizer_queue', 'box_image_optimizer_stats', 'box_image_optimizer_log' ); И еще найдено нелогичное поведение оптимизации - после оптимизации файл может вырасти в размере (отрицательная оптимизация). Правильная логика: если результат не дал экономии (или ухудшил), откатываемся к исходному файлу и считаем операцию "skip". Необходимо производить оптимизацию во временный файл, сравнивать размеры и только потом подменять оригинал.

@OcBox еще ошибка - вкладка Оптимизация - нажать кнопку Сканировать - получаем ошибку, в логах. Error: Call to undefined method Boximageoptimizer::getLastSkipReason() in \admin\controller\extension\module\box_image_optimizer.php on line 474

@OcBox отличный модуль с большими возможностями и удобным интерфейсом. При беглой проверке нашел ошибку - на вкладке Панель -> нажать кнопку Старт для организации "Изображения брендов". Будет ошибка. В логах 2026-01-23 22:33:32 - Exception: Error: Unknown column 'name' in 'field list' (1054) SELECT name FROM `oc_manufacturer_description` WHERE manufacturer_id = 5 AND language_id = 1 in \system\library\db\mysqli.php on line 53 Причина ошибки - в таблице manufacturer_description нет поля name. Таблица manufacturer - содержит общие данные о производителе (включая поле name), а таблица manufacturer_description — используется для мультиязычных описаний, там поля description, meta_title, meta_description, meta_keyword, а не name. Ошибку вызывает /system/library/boximageoptimizer.php метод public function generateManufacturerSeoFilename($manufacturer_id, $language_id = 1, $max_length = 100) { $table_check = $this->db->query("SHOW TABLES LIKE '" . DB_PREFIX . "manufacturer_description'"); if ($table_check->num_rows) { $query = $this->db->query(" SELECT name FROM `" . DB_PREFIX . "manufacturer_description` WHERE manufacturer_id = " . (int)$manufacturer_id . " AND language_id = " . (int)$language_id ); if ($query->num_rows && !empty($query->row['name'])) { $slug = $this->slugify($query->row['name'], $max_length - 12); return $slug . '-brand-' . $manufacturer_id; } }

Якщо не етапі установки або через панель адміністрування створити користувача в паролі якого будуть використані спецсимволи, то користувач не зможе увійти - буде помилка пароля при вході. В OpenCart вбудований клас Request при отриманні даних з $_POST обробляє їх для захисту від XSS-атак, перетворюючи небезпечні символи HTML-сутності. Проблема в admin/controller/user/user.php в якому забули перед збереженням паролю зробити html_entity_decode При натисканні кнопки "Зберегти", у масиві $this->request->post['password'] спецсимволи вже замінені на HTML-сутності (наприклад, & перетворився на &). При збереженні: Контролер передає в модель addUser масив "як є". До бази даних записується хеш від рядка 123&amp456. При логіні: код робить html_entity_decode та намагається перевірити пароль 123&456. Підсумок: Хеші не збігаються. Вхід неможливий. Щоб виправити, потрібно декодувати пароль (додати html_entity_decode) перед тим, як передати його в модель для збереження в базу. Це потрібно зробити у методі add() та у методі edit() та ще й у validateForm(). Приклад для add() Знайти if (($this->request->server['REQUEST_METHOD'] == 'POST') && $this->validateForm()) { $this->model_user_user->addUser($this->request->post); Замінити if (($this->request->server['REQUEST_METHOD'] == 'POST') && $this->validateForm()) { // Декодуемо пароль перед збреженням $this->request->post['password'] = html_entity_decode($this->request->post['password'], ENT_QUOTES, 'UTF-8'); $this->model_user_user->addUser($this->request->post); Зробити по аналогії для метода edit() знайти if (($this->request->server['REQUEST_METHOD'] == 'POST') && $this->validateForm()) { $this->model_user_user->editUser($this->request->get['user_id'], $this->request->post); замінити if (($this->request->server['REQUEST_METHOD'] == 'POST') && $this->validateForm()) { // Декодуємо пароль перед збереженням (якщо його змінено) if ($this->request->post['password']) { $this->request->post['password'] = html_entity_decode($this->request->post['password'], ENT_QUOTES, 'UTF-8'); } $this->model_user_user->editUser($this->request->get['user_id'], $this->request->post); Для validateForm() знайти if ($this->request->post['password'] != $this->request->post['confirm']) { $this->error['confirm'] = $this->language->get('error_confirm'); } замінити if (html_entity_decode($this->request->post['password'], ENT_QUOTES, 'UTF-8') != html_entity_decode($this->request->post['confirm'], ENT_QUOTES, 'UTF-8')) { $this->error['confirm'] = $this->language->get('error_confirm'); }

Было бы хорошо, если бы ответы давались в понятной большинству форме. В форме, которой любой сможет повторить действия, а не только тот, кто хорошо разбирается в вопросе. Поэтому перефразирую для лучшего понимания и доступно для всех, кто захочет так изменить логику поведения копирования товара. Чтобы при копировании товара поле "Дата поступления" имело текущую дату нужно: Найти в модели admin/model/catalog/product.php метод public function copyProduct($product_id) {...} и после строки $data = $query->row; добавить строку $data['date_available'] = date("Y-m-d"); Параметры времени H:i:s не нужны потому, что поле 'date_available' в базе данных имеет тип date. Время в любом случае не сохраниться.

@AlexMax13 Не хочу нікого образити, але щоб ви не вибрали Ocstore 3, Opencart 3 або будь-яку збірку на їх основі, ви їхатимете на кульгавій кобилі, у випадку Opencart, вона ще буде тринога. Друга версія буде кращою, але через її моральне старіння та відсутність хороших шаблонів і модулів її не варто розглядати. У будь-якому випадку ви зіткнетеся з ситуацією "рука-обличчя" і, найімовірніше, вирішуватимете проблеми на платній основі. Щоб не обрали – скрізь будуть проблеми. Скрізь помилки, що не виправляються роками. Зверніть увагу на підтримку версій PHP. Останні версії можуть вже не працювати на PHP 7.x.