Opencart 5
Entry posted by MaxD in Opencart 5 ·
2 620 переглядів
Щось в останній час мене включило кодити, давно такого не було з початку вторгнення. Зайнявся 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.
Принаймні, я встановив модуль Нової Пошти і він нормально працює )
Поки більше нічого не поміняно, візуально все виглядає по старому. Як вам такий напрямок змін?
-
8
47 коментарів
Recommended Comments
Створіть аккаунт або увійдіть для коментування
Ви повинні бути користувачем, щоб залишити коментар
Створити обліковий запис
Зареєструйтеся для отримання облікового запису. Це просто!
Зареєструвати аккаунтВхід
Уже зареєстровані? Увійдіть тут.
Вхід зараз