sv2109

Якшо ви особисто з якимось двіжком не працюєте то це зовсім не означає що він мертвий)) Ось наприклад по друпалу, він зараз десь у 5 разів популярніший за опенкарт! https://trends.google.com.ua/trends/explore?date=today 5-y&q=%2Fg%2F11b5m9hl85,%2Fm%2F01641s&hl=uk Але масово ви про них і не будете чути, бо і друпал і магенто це зовсім інший сегмент сайтів, це корпоративні сайти, на друпалі колись працював сайт білого дому, не знаю як зараз + різні дуже великі сайти та портали, напр. redhat.com, europa.eu ітд. на магенто розробляють магазини типу allo.ua та інші подібні та дуже великі магазини. Розробники там беруть до 200 і навіть більше $ за годину! і за один день заробляють більше, ніж середньостатистичний розробник під опенкарт заробляє за місяць)) Просто це корпоративний сегмент і туди дуже тяжко пробитися якомусь одному фрілансеру, там заказчики це дуже великі контори які навіть дивитися у сторону фрілансерів не будуть, вони краще заплатять декілька десятків а то і сотень тис.$ якісь великій софтверній фірмі, ніж в десятки разів менше, але якомусь фрілансеру..

згоден, саме з цим я не працював, але колись працював з першими версіями Codeigniter -а так він навіть по синтаксису дуууже сильно нагадує опенкарт, мені навіть здається що на я етапі створення опенкарту Даніель просто злизав частину коду з цього фреймворку. Але в плані фреймворка опенкарт не дотягує навіть до перших версій Codeigniter-а.. що вже говорити про інші більш сучасні фреймворки. А так, да, взяти якийсь дуже простий фреймворк, перенести ядро на нього і дописувати тільки сам функціонал самого магазину і взагалі не паритися на рахунок ядра, над яким працюють інші розробники, постійно його вдосконалюючи, випускаючи нові версії, виправлячи баги, добавляючи нові функції ітд. Цим шляхом до речі у свій час пішов Друпал, раніше десь до 6,7 версії у них все працювати на своїх власних велосипедах і вони витрачали реально купу часу щоб все це підтримувати, потім плюнули та перевели весь Друпал на симфоні, скинувши зі своїх плеч величезний об'єм роботи, бо це все вже і так реалізовано та підтримується величезною спільнотою симфоні. І в результаті від цього всі тільки виграли.

а то я мабуть 10 років з якимось іншим опенкартом працюю))) при використанні модифікаторів конфлікти будуть завжди! Причому їх буде дуже багато. Бо модифікатор змінює код самого опенкарту. І питання тут не у тому правильно написаний той модифікатор чи ні, конфлікти будуть у будь-якому випадку бо модулі пишуть різні розробники і один взагалі нічого не знає і не може знати що у голові у іншого... Я пишу свій модуль і прив'язуюся в модифікаторі до якогось конкретного куска коду в стандартному опенкарті, добавляю свій код після нього. І все працює, бо у стандартному опенкарті цей код є. А до мене якийсь інший розробник змінив цей кусок коду на інший чи дописав щось своє, бо для його модуля саме це треба було зробити, і що буде? мій модуль вже не знайде потрібний код та не добавить свій код після нього. І що це як не конфлікт? маємо помилку і або один модуль не буде працювати або два. Або і ще гірше - два модуля будуть працювати і жодних помилок не буде, але логіка роботи зміниться і наприклад десь у корзині якась ціна буде нараховуватися неправильно.. і подібні помилки взагалі дуже тяжко виправляти бо все вроді працює і в логах чисто.. Так ще не розповідайте басні, що ніяких конфліктів не буде, якщо у магазині встановлено декілька десятків модулів (практично у кожному магазині так) і кожен із модулів вносить десятки змін у код самого опенкарту + ще встановлена якась тема тиду джорнал яка сама по собі переписує половину опенкарту і в результаті отримуємо опенкарт, встановити якийсь новий модуль на який ще те задоволення.. сидиш і тупо виправляєш конфлікти бо все не так як треба.

Дуже спірно, як на мене. Data Mapping це по суті ORM, ORM це дуже крута штука, згідний, але для опенкарту це буде занадто складно, особливо зараз. Зараз люди звичайний конструктор запитів не можуть прийняти бо для них це заскладно, то як вони повинні прийняти цілу ORM яка буде значно складнішою? + вона також буде працювати повільніше, бо це ще один великий шар абстракції. До ORM потрібно дорости і опенкарт як на мене ще взагалі не доріс що цього. ORM дуже зручна якщо мова йде про не складні запити, але коли з'являються зв'язки, особливо зв'язки many to many де в ідеалі потрібно створювати ще одну проміжну pivot таблицю і працювати через неї, щоб побудувати цей зв'язок то це значно ускладнює все. Взяти наприклад таблицю товару в опенкарті (яка пов'язана ще мабуть із десятком інших таблиць, а ті ще з іншими) і як це все перенести на ORM? Перенести то можна, але що в результаті вийде і як воно потім буде працювати по швидкості? Та і рішення яке вийде буде ніяк не простим. Ну і + ORM це штука, яка добре працює у великих системах, де крім самої ORM є ще дуже багато всього (різні міграції, фабрики, кешування, події, інтеграція із шаблонізатором ітд.) і все працює як одне ціле, наприклад в Laravel я через ORM отримую колекцію (по замовчуванню отримується тільки поля основної таблиці, без зв'язків, щоб зробити запит швидким), передаю її у шаблонизатор, там в циклі прохожуся по якомусь зв'язку цієї таблиці і все працює (знову ж таки, потрібно добре розуміти як це все працює під капотом, щоб розуміти скільки запитів до бази при цьому буде створено). А не так що взяти одну ORM і всунути її у опенкарт бо це круто і правильно. У той час як конструктор запитів до бази даних, так, він не такий функціональний, але він і набагато простіший, легший в освоєнні та швидший. І для опенкарт на зараз як на мене підійшов би просто ідеально, як заміна сьогоднішнього підходу коли всі SQL запити тупо пишуть вручну.. Зараз це була б золота середина між голими запитами як зараз та ORM, яка накладає свої обмеження та складнощі. Пізніше коли б всі звикли до конструктора то можна було би подумати щоб впроваджувати щось більш складне та функціональне, але на зараз як на мене це зайве. Якось так, моя досить аргументована позиція))

Название темы очень неоднозначное, так как многие могут сказать, что это совсем разные вещи, сравнивать которые не имеет смысла. Но многие разработчики OpenCart считают OpenCart именно фреймворком, некоторые даже пишут что это не просто фреймворк, а самый лучший фреймворк, на котором можно сделать сайт любой сложности.. Поэтому и решил сравнить именно функционал фреймворков. Почему Laravel На сегодня это наверное самый популярный фреймворк на PHP. Он во много раз (и даже в десятки) популярнее самого OpenCart. Для примера: https://trends.google.com.ua/trends/explore?date=today 5-y&q=%2Fm%2F0jwy148,%2Fg%2F11b5m9hl85&hl=uk за последние 5 лет если популярность OpenCart упала больше как в 2 раза, то популярность Laravel наоборот выросла процентов на 30. Это фреймворк на котором пишут всё - от всевозможных API, серверлесс решений, SPA, бэкенда для мобильных приложений, ботов для мессенджеров до больших и сложных сайтов, интернет магазинов и маркетплейсов. Он простой, быстрый, функциональный, безопасный, что очень важно - очень активно поддерживается сообществом и развивается, совсем недавно вышла новая, 10 версия фреймворка, всего год назад - 9. Есть огромное количество бесплатных расширений, практически под любую задачу уже есть готовый пакет. Он отлично работает как с обычными css библиотеками типа bootstrap так и с реактивными фреймворками типа React и Vue. Я недавно начал более серьезно изучать этот фреймворк, скорее в качестве спортивного интереса и расширения кругозора, так как в последнее время постоянно о нем слышу с очень разных источников. И был очень приятно удивлен его красотой, удобством и функционалом. А также насколько радикально он отличается от опенкарта в плане кода и работы с ним для программистов. Тут автоматизировано почти все, что можно автоматизировать, многие действия делаются вообще в 1-2 строчки кода. Поэтому и решил написать данный пост, а заодно и немного сравнить функционал с OpenCart и даже показать примеры кода. И так, некоторые возможности Laravel, которые больше всего понравились: Тут в полном объеме раскрываются все возможности PHP - классы, интерфейсы, наследование, трейты, Enums, SOLID, шаблоны проектирования (фасады вообще везде, DI, Factory..) итд. Работая с фреймворком реально начинаешь понимать всю красоту правильного подхода, когда в одну строчку кода можно изменить логику работы всего приложения если все спроектировано правильно. А не так как в опенкарт, когда чтобы поменять какую-то мелочь, нужно изменить сотни строк кода в десятках файлах, что и делается постоянно, достаточно посмотреть как в опенкарт сделана напр. пагинация или валидация форм или генерация ссылок или работа с базой.. Чтобы не быть голословным. Если прочитать формулировку 5 принципа SOLID - инверсии зависимостей, то там будет вот это: A. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. B. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. Скорее всего, если вы читаете это впервые то единственное что вы из этого поймете это то, что вы ничего не поняли)) В то же время когда начинаешь работать с Laravel то там достаточно часто методы получают в параметрах не какие-то конкретные объекты и следовательно зависят от конкретных реализаций этих объектов, а интерфейсы, то есть эти методы зависят именно от абстракций. Что это дает? В настройках Laravel можно указать какой конкретный класс нужно использовать для данного интерфейса, можно даже сделать это через условие, например в режиме разработки использовать один класс, который напр. не отсылает никуда данные а только пишет в лог, а в продакшене использовать другой. При этом мы никак не изменяем логику самого метода, ему вообще без разницы какой объект ему передали, главное чтобы это был объект нужного интерфейса. И приложение получается очень гибким и без кучи ненужных условий, проверок и дублирования кода. Изменения делаются через изменение одной строчки кода и у нас уже все приложение работает по совсем другой логике. Консольные поманды php artisan - скрипт с помощью которого можно создавать огромное к-ва кода и запускать типовые действия через 1 комманду. Можно создавать контроллеры, модели, миграции, события, правила, ресурсы, реквесты, работать с базой данных, очередями, планировщиком, представлениями, окружение и многое другое. Можно также создавать свои кастомные консольные комманды или изменять логику работы уже существующих. То есть вам нужно что-то создать вы не пишете весь код вручную, вместо этого вводите 1 комманду в консоли напр. php artisan make:model ProductModel (+ различные параметры если нужно) и создаете сразу новую модель для товара вместе с фабрикой, миграцией, сидом, ресурсным контроллеров (в котором уже будут созданы все необходимые методы для CRUD) а также отдельными классами реквестов. Сколько времени это экономит? Особенно есть учесть что если писать столько кода вручную то полюбому где-то допустишь ошибку и потом еще потратить кучу времени чтобы понять почему оно не работает. Плюс мы также получаем однотипную структуру для всех проектов, что значительно упрощает работу. Очень классно реализована работа с базой Тут есть как отдельный билдер для создания запросов к базе и не нужно вручную писать кучу SQL запросов для кучи однотипных действий - получение, изменение, удаление записей в базе данных. Тут конечно есть и ORM. Вы просто создаете новую модель php artisan make:model ProductModel Это будет практически пустой класс без единой строчки SQL кода, но в контроллере вы уже сможете полноценно работать с базой, например $products = Product::all(); получит все товары, можно также добавить различные условия, лимиты, сортировку, связи итд. Мало того, что вы экономите кучу времени, так еще и все запросы к базе автоматически защищаются от всевозможных SQL инъекций и различных ошибок. Таблицы в базе данных создаются и изменяются с помощью миграций - специальный класс для изменения таблицы, с помощью которого можно как добавить изменения так и откатить их. например миграция для таблицы постов: Schema::create('posts', function (Blueprint $table) { $table->id(); $table->string('title'); $table->text('content'); $table->unsignedBigInteger('category_id')->nullable(); $table->timestamps(); $table->index('category_id', 'post_category_idx'); $table->foreign('category_id', 'post_category_fk')->on('categories')->references('id'); }); Можно использовать сиды - классы для заполнения таблиц какими-то данными. Сиды можно реализовывать через фабрики - класс для автоматического создания записи, есть также класс Faker для создания фейковых данных для полей - текстовых, числовых, различных дат, кодов, картинок, телефонов, емейлов итд. можно очень легко заполнить сайт тестовыми данными для тестирования, за пару секунд создать хоть 1000 постов с названием, описанием, картинкаим итд. Или кучу пользователей с емейлами, паролями итд. То есть как происходит стандартная работа - вы копируете какой-то проект на Laravel, Одной командой создаете все необходимые таблицы для работы Еще одной командой заполняете эти таблицы необходимыми для работы данными. Максимально простые контроллеры (что по сути и должно быть по стандарту MVC, а не то что мы сейчас видим в опенкарт) пример метода контроллера для получения поста public function show(Post $post) { return view('post.show', compact('post')); } Обратите внимание, очень классная фишка Laravel - если в адресе страницы есть id поста (напр. /posts/123) то мы в качестве аргумента метода контроллера можем получить не этот идентификатор чтобы потом по нему вручную создать этот пост, а фреймворк за нас сам создаст этот пост и мы в качестве аргумента получаем сразу объект этого поста, осталось передать его представлению и все. Если пост не будет найден то фреймворк вернет страницу 404. Вроде мелочь, но таких мелочей там десятки, которые очень сильно ускоряют разработку. или контроллер для создания постов public function store(StoreRequest $request) { $data = $request->validated(); $this->service->store($data); return redirect()->route('admin.post.index'); } StoreRequest - отдельный реквест для данного метода, опять же в качестве аргумента получаем готовый объект и нам не нужно его создавать вручную самостоятельно, в нем содержаться правила валидации запроса public function rules() { return [ 'title' => 'required|string', 'content' => 'required|string', 'image' => 'required|file', // можно также указать что это также картинка, определенного типа и размеров. 'category_id' => 'required|integer|exists:categories,id', // тут сразу проверяется наличие этого идентификатора базе в таблице категорий, чтобы не создать пост с несуществующей категорией. 'tag_ids' => 'nullable|array', 'tag_ids.*' => 'nullable|integer|exists:tags,id', ]; } то есть вам не нужно вручную для каждого поля, которое вы получаете, через кучу if конструкций прописывать кучу правил, обработку этих правил, вручную создавать и возвращать ошибки валидации, если эти правила не сработали или даже писать sql запросы если нужно проверить уникально записи в базе данных, нет. Просто создается массив со всеми правила (из коробки уже доступны десятки правил валидации с текстами ошибок, но можно создавать и свои собственные) и все. дальше, в $data = $request->validated(); попадет массив всех уже проверенных данных. Если валидация не прошла то фреймворк сам возвращает пользователя на старую страницу и возвращает все ошибки валидации все что вам нужно это прописать в шаблоне под полем @error('title') <div class="text-danger">{{ $message }}</div> @enderror и фреймворк сам выведет нужные ошибки для всех правил для каждого поля, ошибки тоже можно настраивать и переопределять. дальше по коду $this->service->store($data); вся логика из контроллера вынесена в отдельный сервис для создания всех данных, для улучшения читабельности кода и чтобы не раздувать контроллеры. сам метод примерно такой: public function store($data) { try { // старт транзакции, так как есть работа с несколькими таблицами DB::beginTransaction(); $data['image'] = Storage::put('/images', $data['image']); $post = Post::сreate($data); if (isset($tagIds)) { $post->tags()->attach($tagIds); } DB::commit(); } catch (\Throwable $th) { // откат если произошла какая-то ошибка DB::rollBack(); } } Тут видно работу с транзакциями, которых вообще нету в OpenCart и очень зря, так как при сохранении напр. товара задействуется не одна таблица товара, а с десяток других - опции, атрибуты, акции, скидки, картинки, связи итд. И если где-то произойдет ошибка то в базу запишутся не валидные данные которые потом найти будет крайне сложно. Я достаточно часто встречаю ситуацию когда в базе опенкарт невалидные данные, особенно после использования различных модулей импорта. Очень просто сделана работа с файлами. Можно в настройках указать несколько файловых хранилищ (локальное, фтп, облачные хранилища) и легко переключаться между ними или какие-то данные загружать локально, какие-то в облако итд. Post::сreate($data); создаст новый пост через метод attach к этому посту добавятся новые теги, потому что в модели поста прописана связь этого поста с тегами public function tags() { return $this->belongsToMany(Tag::class, 'post_tags', 'post_id', 'tag_id'); } Эта связь дает нам возможность как автоматически получать теги для постов (через $post->tags) так и изменять их. При этом мы не написать ни одной строчки SQL кода! Весь код со всеми связями, проверками итд. написал за нас фреймворк. И это не только очень сильно ускоряет весь процесс разработки экономя сотни часов времени, но и страхует от кучи возможных ошибок, в том числе ошибок безопасности, например можно какие-то данные при добавлении в базу не обработать и получить потенциальную ошибку безопасности. Понравилась такая фишка как безопасное удаление если в модели просто добавить трейт use SoftDeletes; то при удалении записей они не будут удаляться физически, а просто помечаться что были удалены, на сайте вы их не увидите, так как почти все методы работы с базой этих записей не видят, но они будут в базе и их легко можно восстановить при необходимости. Что еще, для примера - пагинация Если нужно добавить пагинацию то в контроллере при получении постов делаем $posts = Post::paginate(10); а в шаблоне добавляем всего одну строчку кода {{ $posts->links() }} и все, мы получаем рабочую пагинацию, стилизованную напр. под бутстрап, которая сама создает все ссылки. А теперь сравните какую простиню кода нужно написать в опенкарт для того чтобы добавить ту же самую пагинацию для каждой страницы.. это куча строк кода в каждом! контроллере. $url = ''; if (isset($this->request->get['filter_name'])) { $url .= '&filter_name=' . urlencode(html_entity_decode($this->request->get['filter_name'], ENT_QUOTES, 'UTF-8')); } if (isset($this->request->get['filter_model'])) { $url .= '&filter_model=' . urlencode(html_entity_decode($this->request->get['filter_model'], ENT_QUOTES, 'UTF-8')); } if (isset($this->request->get['filter_price'])) { $url .= '&filter_price=' . $this->request->get['filter_price']; } if (isset($this->request->get['filter_quantity'])) { $url .= '&filter_quantity=' . $this->request->get['filter_quantity']; } if (isset($this->request->get['filter_status'])) { $url .= '&filter_status=' . $this->request->get['filter_status']; } if (isset($this->request->get['filter_image'])) { $url .= '&filter_image=' . $this->request->get['filter_image']; } if (isset($this->request->get['sort'])) { $url .= '&sort=' . $this->request->get['sort']; } if (isset($this->request->get['order'])) { $url .= '&order=' . $this->request->get['order']; } $pagination = new Pagination(); $pagination->total = $product_total; // для этого нужно эту переменную еще вручную достать из базы, создав для этого отдельный метод с кучей sql кода и передать в контроллер. $pagination->page = $page; $pagination->limit = $this->config->get('config_limit_admin'); $pagination->url = $this->url->link('catalog/product', 'token=' . $this->session->data['token'] . $url . '&page={page}', true); $data['pagination'] = $pagination->render(); Отличный концепт - очереди и задания. Если есть какие-то действия, напр. отправка почты или какие-то вычисления, для которых нужно обращаться к сторонним сервисам то вместо того чтобы долго ждать каждый раз пока сторонний сервер отдаст результат, можно создать новой задание Job и добавить его в очередь Queue после этого все действия в очереди будут спокойно обрабатываться в фоне и ничего на сайте не будет тормозить пока ожидается ответ от сервера. Еще одна отличная концепция - Middleware Это код который выполняется перед или после реквеста. Очень удобно делать разные ограничения доступа к некоторым страницам (например открыть доступ к странице только авторизованному пользователю или админу итд.) или обработку входящих данных, например по умолчанию для всех входных строк отображаются пробелы в начале и конце. При этом вся логика не пишется в одну кучу в контроллере через кучу условий, а лежит в отдельном классе. Через этот механизм таже сделана защита CSRF (cross-site request forgery ) все что вам нужно это написать в шаблоне для формы @csrf и все! фреймворк сам создаст нужные токены, передаст их в форму, выведет нужный инпут, а на входе проверит все запросы (кроме гет) есть ли там токер, совпадает ли он, если не совпадает то сделает возврат с ошибкой и не даст такой форме пройти дальше. Этот механизм работает для всех форм, то есть уже из коробки есть эта защита для всех форм. И этой защиты вообще нету в OpenCart. Через Middleware также из коробки реализован троттлинг, для API вы можете указать сколько запросов напр. в минуту должен сервер обрабатывать и не больше. Ну и так далее, то что я описал выше это очень малая часть возможностей фреймворка, просто для примера. Всех возможностей многократно больше. Я просто хотел показать насколько тут все продумано до мелочей, когда основные базовые действия автоматизированы настолько, что делаются буквально в 1-2 строчки кода. И как это контрастирует с опенкартом, где для любого действия нужно писать десятки строк кода да еще и дублировать это в десятках контроллеров. Наглядный пример сравнения когда в одном случае продукт делается программистами для программистов и когда в другом случае кто-то пишет код вообще не думая о том кто потом и как с этим кодом будет работать в будущем.. Возможно поэтому популярность Laravel растет последние 5 лет, чего к сожалению не скажешь об OpenCart..

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%, покриваючи фактично всі можливі задачі. Як це можна зробити не буду повторюватися, писав тут Ось вам готовий варіант двіжка, концепт, який буде якісно відрізнятися від існуючого опенкарта (а не тупо скопіює всі його проблеми не вирішивши їх, замінивши об'єкти на статичні класи..) і на який я б наприклад з радістю перейшов замість сьогоднішнього опенкарту, який вже якщо често в печінках сидить через свої баги, конфлікти, помилки та жахливе ставленням Даніела до всіх розробників.

извините, не понял вас, вы хотели что-то спросить?

ні, не так, модуль автоматично не нараховує знижки, він створює саме візуальне оформлення акцій у вигляді таймеру, опису ітд. знижку ви можете зробити наприклад через купони чи вручну чи через інші модулі

ответил только что

Здравствуйте, пишите в ЛС по таким вопросам, нужно смотреть, настройки модуля, данные товаров итд.

Здравствуйте, этот модуль - Поисковая система + для живого поиска модуль Поиск с автодополнением, он работает в паре с модулем Поисковая система (в отличии от вашего модуля шаблона) и намного функциональнее подобных модулей шаблонов. Вот ссылка

да, именно так и будет.

Где я это написал? Или у вас какая-то паранойя по этому поводу?

так в том то и дело что я думал, что там текст, а не число, ведь этот массив это массив товара из опенкарта и в примере это данные из поля SKU что является текстом в базе и работаю я с этим полем как с текстом, что логично, но на каком-то этапе PHP сам изменил тип на число, потому что содержание было похоже на число.. и там вместо текста оказалось число в некоторых случаях. И получается что код в общем работает нормально, а в некоторых случаях - не работает.. Мне вот только что стало интересно докопаться до причины где именно это произошло, нашел. Вот такой код $text = "123456"; var_dump($text); $arr = array(); $arr[$text] = "value"; var_dump(array_keys($arr)); вернет вот такой результат string(6) "123456" array(1) { [0]=> int(123456) } то есть, при добавлении нового элемента массива PHP изменяет тип ключа массива на число если в переменной находится строка, которая похожа на число.. Ну вот, короче, все прелести слабой типизации..

А вы конечно же на память знаете всю документацию по PHP и что написано для каждой функции и как она себя ведёт в каждой версии PHP, ага, конечно Да и по поводу Как вообще можно быть абсолютно уверенным в типе переменной если весь язык слабо типизированный и сам может изменить тип? То есть по сути это ни что иное как баг, который исправили только в 8 версии языка.

Почти час убил в выходной день чтобы найти причину очень странного бага.. оказалось что это баг самого PHP, который исправили только в версии 8! и вот такой простейший код $arr = array(46160); var_dump(in_array("46160G", $arr)); вернет true для версий PHP вплоть до 7.4.33 и false с версии 8.0 и выше: но в strict режиме $arr = array(46160); var_dump(in_array("46160G", $arr, true)); все работает корректно и во всех версиях получаем false

c 3.0.3.7 работать будет насчет фильтра - фильтр у вас будет работать, но если в фильтре есть фильтр по цене то его нужно будет или отключить или он будет работать неточно, потому что фильтр берет цену прямо из базы для создания фильтра по цене, а модуль ее еще обрабатывает для каждого товара по своим правилам. Если наценка или скидка небольшая то это не очень критично, если большая - то в таком случае фильтр по цене лучше отключить, все остальные фильтры будут работать так же как и работали.

нет))

похоже вот сам сервис https://www.mstarproject.com/?action=tecdoc_mysql_site

Такие вещи на готовых CMS обычно не делают, так как они сильно нестандартные. Скорее всего это какое-то самописное кастомное решение, возможно написано на каком-то фреймворке. Я когда-то лет 10 назад делал на CMS Drupal сайт автозапчастей. Drupal в этом плане очень гибкая система по настройкам, но проблема таких сайтов очень большая номенклатура товаров - сотни тысяч и даже миллионы.. для довольно тяжелого друпала это много, даже очень много. Если делать на опенкарте то плюс в том, что опенкарт очень простой и быстрый, он с некоторыми доработками сможет потянуть и миллион товаров. Но сделать такой сайт очень непростая задача и по объему и по сложности и по дальнейшей оптимизации, поддержке, постоянном обновлении данных итд. Проще найти через какой сервис работают эти сайты и за какой-то процент от продажи или абонплату работать с ними, будет и сайт готовый и база актуальная и работать сможете практически сразу.

Модулем мабуть ні, але можна реалізувати, якщо потрібна саме така логіка. Пишіть у ЛС обговоримо.

Гарна ідея)))

мне вот только сейчас мысль в голову пришла, проверил - работает) для очистки лога можно в админке просто открыть роут marketplace/modification/clearlog там идет обычный GET запрос, я почему-то думал что там POST и это не сработает, но работает оказывается, а я постоянно до этого через фтп удалял, оказалось все оч. просто.

О! очень нужный мод, сам хотел когда-то написать, так как ситуация когда заходишь на страницу модификаторов и вкладка браузера просто виснет реально напрягает, тем более что очистить лог через браузер не получится, так как вкладка зависла, приходится вручную удалять файл.