MaxD

Обновление 4.33: выбор качества WebP инструмент анализа медленных запросов, который также дает возможность потестировать и добавить индексы (пока не переведен на русский) фиксы

Этот параметр не настраивается. Чаще всего кеширование таких большие запросов не дает выиграша в производительности. Если очень нужно, я могу вам написать, какое место в коде подправить (но это надо будет делать после каждого обновления Lightning). Возможно что-то сбойнуло. Дайте знать, если снова выскочит.

Отличная идея, сделаем )

Обновление 4.32: фиксы безопасности улучшенная прегенерация внизу виджета добавлена ссылка на инструменты Lightning

@chukcha Это какие-то странные фантазии. Файл кеша пишется через file_put_contents($file, "<?php\n $"."data = " . var_export($data, true) . ";"); var_export екранирует все случаи, когда из базы может попасть что-от вредоносное.

@chukcha jsondecode в принципі повільніший, ніж unserialize, а він повільніший, ніж include php коду, що заганяє дані в масив, якщо є opcache. На мому тесті (розмір масиву ~ 1.5 Mb, PHP 8.2, 250 прогонів кожного варіанту) вийшло таке співвідношення: jsondecode: 9.4 sec unserialize: 5.2 sec php include: 0.7 sec

При збільшенні кількості товарів рано чи пізно настає момент, коли операція "витянути з бази всі seo_url та перекрутити їх у ассоціативні масиви" стає повільнішою, ніж зробити окремі запити до бази для кожного лінка на сторінці. І чим більше товарів, тим цей розрив драматичніший. Lightning кешує найчастіше вживані лінки і це значно помагає у класичному сценарії, але до одного місця, якщо на початку кожного запиту витягується вся база seo url (

@elabba Возможно, выключен модификатор Lightning. Если Lightning не используется, удалите папку catalog/controller/extension/lightning. Если используется (или собираетесь использовать) - переустановите Lightning.

catalog/controller/extension/lightning

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

Тому, хто читає код і намагається зрозуміти, що в ньому відбувається - непрозорий. Банально, дивишся на файл шаблону і намагаєшся зрозуміти, чому на сайті є кнопка, а в шаблоні нема. Або читаєш код моделі, а її видачу уже перепахало три різних доповлення внахльост, іди шукай і розбирайся. І IDE тобі тут не поможе, хіба дебаг. Так, ocMod/vQmod треба буде підрихтовувати. Але принаймні прості розширення в класичному opencart-стилі - доставки-оплати-модулі працюватимуть, що вже добре. У Opencart4 і цього нема, а переробляти розширення під нього ще той цимес, змінилося буквально все. Registry мало того, що є супер-збоченим способом емулювати глобальні класи, який не дає IDE зрозуміти, де що, він ще й дає пенальті на швидкість, бо кожен пук викликає магічну функцію. Чому мій код лайно, можна більш конкретно? В світлі підтримки порівняно з Opencart3?

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

Всем привет! Я допилил свой Тестовый сайт, инструмент который позволяет создать тестовую копию магазина за один клик без всяких заморочек. Теперь он поддерживает Opencart 4 и будет очень полезен для экспериментов с ним )

Добавлена поддержка Opencart 4

@SFS77 Файл с таким названием не входит в дистрибутивы Lightning. Если бы Lightning содержал в себе какой-то шеллкод, ему бы не было необходимости записывать его в отдельный файл. Скорее всего злоумышленник или вредоносная программа случайным образом выбрали место сохранения шелла поглубже, чтобы его не нашли.

@SFS77 Спасибо за ответ. Буду благодарен, если узнаете еще один ньюанс. Как назывался файл с шелкодом?

@SFS77 Через Lightning невозможно взломать сайт. Можно ли получить более развернутое описание от программиста, почему он считает, что виноват Lightning?

@Feniksalex Надо смотреть, киньте доступ в админку.

Правила форума не разрешают продажу лицензий для домена RU.

@zaleha Там весь системный кеш и кеш Lightning (страниц и запросов). Размеры кешей Lightning можно увидеть в виджете. До скольки они выростут, зависит от ситуации в магазине.

@zaleha А Google какое подхватывает? Там можно посмотреть. Вижу, в 2 раза больше стало. Даже чисто эстетически намного лучше выглядит )

@zaleha Это не от Lightning зависит, а от настроек магазина. У вас на странице товара очень маленькие изображения, их бы увеличить раза в 2:

@zaleha Да, через 7 дней Lightning выключится. Lightning сносит все JavaScript в конец страницы. Видимо надо добавить код счетчика в исключения:

@russer Киньте доступ в админку, надо смотреть.

@mem Надо смотреть, киньте доступ в админку.