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. Принаймні, я встановив модуль Нової Пошти і він нормально працює ) Поки більше нічого не поміняно, візуально все виглядає по старому. Як вам такий напрямок змін?

Thank you for the help. I could solve all the issues and install the module successfully, but now I got an error: Internal error, more info in console log! Fatal error: Uncaught Exception: Error: Table 'euromag_euromagnet_hu.oc_translate_expert_same_translations' doesn't exist<br />Error No: 1146<br /> select t.attribute_id, t.language_id language_id_from, l1.code language_code_from, t.name text_from, l2.language_id language_id_to, l2.code language_code_to, l2.image language_image_to, t2.name text_to, count(*) value_count from oc_language l1 join `oc_attribute_description` t on l1.language_id = t.language_id and true and REPLACE(REPLACE(REPLACE(REPLACE(t.name, ' ', ''), ' ', ''), ' ', ''), ' ', '') <> '' and t.name is not null join oc_language l2 on l2.language_id <> t.language_id and (l2.language_id = 7) left join oc_attribute_description t2 on t2.attribute_id = t.attribute_id and t2.language_id = l2.language_id left join oc_translate_expert_same_translations stt1 on stt1.language_id_from = l1.language_id and stt1.language_id_to = l2.language_id and stt1.text_hash_sum = unhex(MD5(REPLACE(REPLACE(REPLACE(REPLACE(LOWER(t.name), ' ', in /mnt/buffer.2/srv/www/euromagnet.hu/website/system/library/db/mysqli.php on line 40

Зараз без реклами ніяк, буде реклама - будуть замовлення і органічний трафік підросте.

Доброго Краще site.ua/category site.ua/product Якщо продукт змінює категорію, посилання збережеться Google рахує "ієрархію" по клікам до сторінки від головної (по посиланням) Тому йому все рівно що у вас там в посиланні

Upd. Закінчився термін дії ключа api Нової пошти Генерація нового вирішила питання Дякую!

1. я вам вище написав як працюють події - там все дуже просто, після виконання якоїсь події запускається якийсь метод модуля, все. Що тут складного? Якби була нормальна документація зі всіма подіями, до яких можна підключитися та реальні приклади роботи з ними то освоїти події можна максимум за 1 день це якщо комусь ну дуже тяжко дається щось нове, а так то їх можна вивчити за півгодини. 2. до чого нас довела "простота" опенкарту ми всі вже прекрасно бачимо, до ручки вже дійшли. Далі по суті 2 шляхи - або почати щось змінювати вже зараз (точніше це потрібно було робити ще декілька років тому) або весь опенкарт просто приречений, він і надалі буде занепадати поки не загнеться остаточно.. нажаль. Бо у 2023 році писати SQL запити вручну а потім ще й змінювати це все за допомогою модифікаторів це.. гм.. пц. короче. я ж ніде не написав, що опенкарт потрібно перетворити у престашоп чи вукомерс, до речі трохи працював і з тим і з тим і код там просто жесть.. Задача якраз таки залишити всю простоту опенкарта при цього добавити функціоналу та зменшити к-сть конфліктів. Якщо замість sql запиту на півсторінки буде один зрозумілий $sql->select('*')->where('...')... при чому не потрібно буде вручну писати весь sql код, не потрібно буде скрізь писати префікс таблиці, не потрібно буде екранувати всі дані (бо конструктор це все зробить за тебе) і саме головне будь-який sql на сайті можна буде дуже легко змінити при чому без конфліктів з другими модулями у майбутньому то де тут ускладнення? Як на мене то все навпаки стане простішим. І при чому тут престашоп? У нас буде той самий опенкат, тільки з яким працювати буде в рази комфортніше і к-сть конфліктів буде в десятки разів меншою, якщо все буде працювати через події. Тут якраз таки навпаки ми отримаємо велику перевагу бо по якості та функціоналу опенкарт стане багато у чому не гіршим за конкурентів, а у простоті освоєння в рази простішим. А якщо тупо викинути події бо комусь вони знаються надто складними та повернутися назад до модифікаторів - то це тупо шлях в нікуди і якщо років 10-15 тому на це ще можна було якось дивитися то зараз, то у 23 році це жесть, це архітектура, яка вже мінімум років 10 як застаріла.

Ух, яку тему пропустив)) Якщо ще не пізно то вискажу свою думку, яку вже не раз висловлював тут. Взагалі такий проект потрібно починати ніяк не із стилів кодування, це якраз можна зробити і потім. Головне - це концепція, що у даної збірки буде такого, що буде якісно відрізняти її від теперіншього опенкарту, який докотився все "до ручки".. І зробити це дуже не складно - за основу беремо недоліки опенкарту (які ми всі дуже добре знаємо) та просто їх виправляємо, залишивши при цьому всі переваги. А не просто переписати все на статичні класи і все, це не вирішить жодних проблем. Це те саме що по суті робить сам Даніел - замість того щоб виправляти глобальні проблеми в коді добавляє нові шаблонізатори та змінює версії бутстрапу. Як на мене це всеодно, що починати ремонт у старій хрущовці не з заміни сантехніки, електрики, штукатурки итд. а з переклеювання шпалер та вкладання нової плитки в у санвузлі, яку будуть ложити на старі гнилі та іржаві труби та стару штукатурку - зовні може буде і гарно, але не це ж пц повний.. Які переваги у опенкарта: 1. Немала популярність, вона знижується, але на ньому все ще працює дуже багато сайтів 2. Дуже багато розробників які з ним працюють і на яких по суті все і тримається і які повинні бути дуууже зацікавлені щоб опенкарт розвивався і далі 3. Сам двіжок дуже простий в освоєнні та роботі та дуже швидкий, я бачив магазини на опенкарти де було більше мільйона товарів! 4. Величезна к-сть модулів, плагінів та тем 5. (можете доповнити) Недоліки (і їх також вистачає) 1. За розвиток всього двіжка відповідає аж одна людина, яка робить виключно те, що сама вважає за необхідне. На мою думку у Даніела просто не має необхідного технічного досвіду, щоб зробити з опенкарта нормальний двіжок. З нього б вийшов дуже гарний та відповідальний міддл розробник, який би працював з вже спроектованою архітектурою, але спроектувати велику систему самостійно він тупо не може.. З самого початку у мене таке враження що основу двіжка він десь злизав з якогось фреймворка (мені код дуже нагадує перші версії codeigniter) а далі вона взагалі не розвивається. Тобто сам зробити не може, а іншим не дає.. 2. Дуже жахливе відношення Даніела до інших розробників, коли для кожної нової мінорної версії двіжка потрібно писати нову версію модуля, бо там змінилася якась дрібниця типу створення посилань чи ще щось. Коли для кожного модуля потрібно писати гору html коду а потім його щей переписувати під кожну нову версію твіга чи бутстрапа. Коли за 15 років існування двіжка все ще немає нормальної системи розширень. Коли будь-які пропозиції та побажання щось виправити тупо ігноруються.. на і так дал. Тобто, розробників на яких все тримається тупо посилають подалі з їхніми проблеми. Писав про це ось тут 3. Примітивне ядро самого двіжка. Всі говорять, що опенкарт простий і це його плюс, ні, він, не простий - він примітивний і це не плюс, а насправді величезний мінус. І те, де опенкарт опинився зараз це якраз і результат цього. Відсутність нормальної системи розширень. Гарна система розширень це по суті основа, фундамент любого двіжка. Бо навіть якщо там буде дуууже примітивний функціонал, то маючи гарну систему розширень інші розробники самі все допишуть та щей зароблять на цьому продаючи різні розширення. Я вважаю і багато розробників цю думку підтримують що система модифікацій vqmod/ocmod це дійсно зло. Цей підхід суперечить багатьом фундаментальним принципам програмування. Наприклад принципи SOLID, другий принцип O - принцип відкритості-закритості, який говорить що програмі рішення повинні бути відкриті для розширень та закриті для модифікацій коду, тобто всі розширення повинні робитися через інструменти, які при цьому не змінюють програмний код! В опенкарті ж це не просто робитися як виключення, на цьому побудована вся! система розширень самого двіжка.. Це просто вибух мозку для мене бо це породжує просто нереальну кількість конфліктів та проблем. І в результаті з цього двіжка втікають як самі розробники, так і прості користувачі, яким постійно приходиться стикатися та виправляти якісь помилки. Для чого їм це якщо зараз є десятки сервісів, де вони можуть в пару кліків мишки створити свій магазин взагалі без знань програмування, і не просто створити, але і розширити його модулями та темами. І при цьому їм не прийдеться виправляти жодної помилки! І це на мою думку головна проблема опенкарту! (як мінімум одна із головних) і її потрібно вирішувати в першу чергу, без цього просто неможливо створити нічого якісно кращого за теперішній опенкарт. Як це можна виправити? Добавити систему Подій (Events) Вони взагалі не складні! Вся суть у тому, що коли у системі настає якась подія то до чи після неї запускається якась функція модуля. Все. Що тут складного? Просто Даніел спочатку добавив події без жодної документації, потім постійно у кожній новій версії їх змінював змінюючи і синтаксис і самі події, а потім взагалі забрав модифікатори, коли за допомогою подій не можна було вирішити великої к-сті необхідних задач.. і що в такій ситуації робити розробникам?? Самі події це дуже простий та елегантний концепт, це готовий патерн програмування, який використовується величезною к-сть інших двіжків, фреймворків та систем ітд. І скрізь це працює. Так чому ж це не працює в опенкарті? Тому що для впровадження цього інструменту мало створити клас Event.. тут потрібно змінювати сам двіжок, щоб він їх у повній мірі підтримував. Щоб через Events можна було вирішити не половину всіх можливих задач, а максимально набализитися до 100%, покриваючи фактично всі можливі задачі. Як це можна зробити не буду повторюватися, писав тут Ось вам готовий варіант двіжка, концепт, який буде якісно відрізнятися від існуючого опенкарта (а не тупо скопіює всі його проблеми не вирішивши їх, замінивши об'єкти на статичні класи..) і на який я б наприклад з радістю перейшов замість сьогоднішнього опенкарту, який вже якщо често в печінках сидить через свої баги, конфлікти, помилки та жахливе ставленням Даніела до всіх розробників.