Leaderboard

Щось в останній час мене включило кодити, давно такого не було з початку вторгнення. Зайнявся Opencart 4, наваяв багато крутих штук для нього, і майже дописав підтримку доповнень від Opencart 3 (принаймні на рівні доставок-оплат). І тут виникло відчуття розвилки - можна намагатися врятувати Opencart 4, або дати йому потонути. По факту Opencart 4 "не взлітає". Вялі інновації, переускладнений код, всі старі проблеми не вирішені. До цього плюсується абсолютна неадекватність Даніеля і його одноосібний контроль на репозиторієм. Проект, який би міг яскраво рухатись вперед силами ком'юніті, ледь ворушиться по міліметру за півроку. Зашквару ситуації додає те, що люди качають на opencart.com Opencart 4, як актуальну версію, а на форумах та й сам Даніель кажуть, що це бета і використовуйте Opencart 3 (причому не з сайту, а з гітхабу). Люди чухають потилицю і йдуть собі далі. Як на мене, розклад з Opencartом зараз один з найгірших за всі роки, і треба щось робити. Можна почати ваяти публічний Opencart 5, взявши за базу Opencart 3 (а калічну четвірку лишити Даніелю). У людей купа класних ідей, персонально у мене теж є немало крутих наробок. Цим постом я хочу прощупати, чи є у нас ентузіазм? ) Ніша Opencart Opencart вирізняється серед інших рішень простотою коду, який можна читати, розуміти і правити. Абсолютна прозорість, процедурність та голі SQL запити цьому допомагають. Це його і слабкість, і сила. І тільки у цій ніші він може жити. vQmod/ocMod є вираженням ідеї "я бачу, що мені треба поміняти в коді, і я просто міняю". Будь-які спроби від цього піти одразу переводять проект в іншу категорію, де і так є свої давні гравці - Prestashop, Magento, Woo. Загалом, треба починати з основ. І перше питання, яке треба вирішити - це code style. Я зробив трансформацію кодової бази Opencart 3 з своїм баченням основ, хочу вам це показати і почути вашу думку. Ось збірка, у ній можна подивитись, як виглядає новий код - https://devs.mx/down/opencart_experiment1.zip Що зроблено? 1. $registry "упразднен", всі об'єкти переведені на статичні класи. Це дає можливість доступатися до них з любого місця без всякої додаткової магії. Раніше було: $this->url->link('product/product', 'product_id=' . $this->request->get['product_id']) Стало: url::link('product/product', 'product_id=' . request::get['product_id']) Так, :: естетично виглядає гірше, ніж ->, але крім цього одні плюси, і в швидкодії теж. Нарешті IDE повністю розуміє, що звідки береться, працює підсвітка параметрів, code completion та переходи по Ctrl-клік. 2. Моделі уже не треба завантажувати в явному вигляді перед використанням. Із звертання для лаконічності забрано префікс model_. Було: $this->load->model('catalog/product'); $product_info = $this->model_catalog_product->getProduct($product_id); Стало: $product_info = catalog_product::getProduct($product_id); 3. Моделі адмінки мають префікс admin_, що дає можливість завантажувати адмінські моделі в каталозі і навпаки: $product_id = admin_catalog_product::addProduct(request::post); $preview = catalog_product::getProduct($product_id); 4. Забрано DB_PREFIX. Ситуації, коли в одну базу треба поставити 2 магазини - супер-рідкі і вирішуються створенням нової бази. Було: $this->db->query("SELECT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) LEFT JOIN " . DB_PREFIX . "category_to_store ... ") Стало: db::query("SELECT * FROM category c LEFT JOIN category_description cd ON (c.category_id = cd.category_id) LEFT JOIN category_to_store ... ") 5. Додано коротку функцію esc(), яка екранує та додає одинарні лапки. Було: $this->db->query("INSERT INTO " . DB_PREFIX . "category_description SET category_id = $category_id, name = '" . $this->db->escape($value['name']) . "', description = '" . $this->db->escape($value['description']) . "'"); Стало: db::query("INSERT INTO category_description SET category_id = $category_id, name = " . esc($value['name']) . ", description = " . esc($value['description'])); 6. Додана коротка функція config(), яка повертає ключ конфігурації, що починається з префікса config_, та переводить його в int, якщо він закінчується на _id. Було: $this->db->query("SELECT * FROM " . DB_PREFIX . "category c LEFT JOIN " . DB_PREFIX . "category_description cd ON (c.category_id = cd.category_id) WHERE cd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND c2s.store_id = '" . (int)$this->config->get('config_store_id')) . "'") Стало: db::query("SELECT * FROM category c LEFT JOIN category_description cd ON (c.category_id = cd.category_id) WHERE cd.language_id = " . config('language_id') . " AND c2s.store_id = " . config('store_id')) 7. Повністю забраний механізм events, як непрозорий. 8. Більшість шляхів та URL тепер відносні. config.php тепер один, в ньому немає купи дублюючих визначень: <?php const SITE_URL = 'http://localhost/opencart5/'; const DIR_STORAGE = 'system/storage/'; // DB const DB_HOSTNAME = 'localhost'; const DB_USERNAME = 'root'; const DB_PASSWORD = 'root'; const DB_DATABASE = 'opencart5'; 9. З адмінської частини забрано user_token в URL. Хтось знає реальний сценарій атаки, від якого він захищав? Якщо так, то є менш кодо-засираючі методи захиститись, наприклад автоматичне додавання IP, з якого логіняться, в білий список. 10. При цьому всьому за допомогою обгорток повністю підтримується старий синтаксис і працють доповлення Opencart 3. Принаймні, я встановив модуль Нової Пошти і він нормально працює ) Поки більше нічого не поміняно, візуально все виглядає по старому. Як вам такий напрямок змін?

Я готовий виконати якесь одне завдання для нової збірки, якщо що. Наприклад, змінити код якогось вбудованого модуля або безкоштовного модуля. Окрім зміни коду, було б чудово бачити зміни в функціональності системи з моменту ії встановлення. Верніше, наразі це може бути просто перелік. Але скажімо так, було б цікаво бачити, чи така збірка може привабити клієнтів.

@Zaurius Доброго вечора! Дякуємо за інформацію, подивимось ці моменти.

До Twigа якраз найменше питань. Синтаксис простий, останні його версії по швидкодії не так сильно відстають від TPL. Ось зараз копирсаю, додав в Opencart можливість одразу робити {{ load('common/header') }}, код контроллерів ще трохи почистився. Правда, лише в адмінській частині, інакше би одразу збилася сумісність з усіма шаблонами для вітрини. І в результаті вийде Prestashop в початковій стадії. Події та ORM сильно підіймають поріг входу та вартість розробки. Супер - якщо прийде час, запрошу долучитися. Звичайно, є орієнтовний план і потрібно зробити немало роботи до того, як чимось заявлятись. Основна концепція - щоб усе нагально-потрібне було з коробки, і було настільки хорошим, щоб уже в цю зону не було потрібно робити комерційних доповнень. Хоча це теж засада, бо весь час Opencart тримається на розробниках, що продають базовий функціонал, your pain is my gain, Daniel )) Программа-мінімум: 1. Зміна структури бази під швидкодію з великою кількістю товарів/категорій/атрибутів 2. Вбудоване SEO, більшою частиною автоматичне і підкапотне 3. Хороший та швидкий модуль фільтрів 4. Імпорт/експорт 5. Оновлення Opencart по кнопці, перевірка нових версій доповнень і теж оновлення їх по кнопці 6. Блог/статті/новини 7. Хороша робоча дефолтна тема вітрини, на якій можна реально крутити магазин

"Міша, все фігня! Давай спочатку!" (С) По-перше. Чому саме 3.*? TWIG - взагалі якийсь анті-паттерн. По-друге. Робити з опенкарту якусь нову, більш правильну версію, виглядає як євроремонт хрущовки. Сама конструкція потребує капітального ремонту! По-третє. Події - це дуже добре, але не в реалізації Данілки. Ось як мають робитися події https://github.com/ikkez/f3-events Далі. Голі sql-запити злюче зло. Потрібно (ну хоча б!) маппінг, але по нормальному потрібно використовувати ORM/ODM https://github.com/ikkez/f3-cortex

@malchuk якщо версія 3.5, оновіть до актуальної версії

twig - це чергова абстракція, яка адміну сайта не несе жодних переваг. ORM/ODM - навпаки (принаймі та реалізація яку я вказав) не тільки знижує поріг входу, але й пришвидшує швидкість розробки і повністю виключає вразливості типу sql-injection.

функции автоматизации по пересчету цены и кол-ву родительского доработаны

этот не подойдет?

Из существенного - не живу и не плачу налоги в России, достаточно? Или надо пойти на кремль с голой жопой?

Кожна копійка в бюджет 404 це патрон/ракета в сторону України

А треба бути в окопі, щоб бути причетним до вбивства українців?

Там гораздо проще всё решается В файле catalog\controller\api\login.php закомментировать: /* $ip_data = array(); $results = $this->model_account_api->getApiIps($api_info['api_id']); foreach ($results as $result) { $ip_data[] = trim($result['ip']); } if (!in_array($this->request->server['REMOTE_ADDR'], $ip_data)) { $json['error']['ip'] = sprintf($this->language->get('error_ip'), $this->request->server['REMOTE_ADDR']); } */ В файле catalog\controller\startup\session.php код $query = $this->db->query("SELECT DISTINCT * FROM `" . DB_PREFIX . "api` `a` LEFT JOIN `" . DB_PREFIX . "api_session` `as` ON (a.api_id = as.api_id) LEFT JOIN " . DB_PREFIX . "api_ip `ai` ON (as.api_id = ai.api_id) WHERE a.status = '1' AND as.token = '" . $this->db->escape($this->request->get['token']) . "' AND ai.ip = '" . $this->db->escape($this->request->server['REMOTE_ADDR']) . "'"); заменить на $query = $this->db->query("SELECT DISTINCT * FROM `" . DB_PREFIX . "api` `a` LEFT JOIN `" . DB_PREFIX . "api_session` `as` ON (a.api_id = as.api_id) LEFT JOIN " . DB_PREFIX . "api_ip `ai` ON (as.api_id = ai.api_id) WHERE a.status = '1' AND as.token = '" . $this->db->escape($this->request->get['token']) . "'"); После этих изменений при работе с API ваш IP проверяться не будет