Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
  • Sign Up

Что нас ждет в OpenCart 4?


sv2109

2,098 views

На данный момент продолжается работа над 4 версией движка. На сегодня для тестирования доступна версия 4.0.0.0_b. Сроков выхода новой версии пока нету, но уже можно посмотреть какие там запланированы изменения. 
 
Из основного
- минимальная версия PHP - 8
"Warning: You need to use PHP8 or above for OpenCart to work!"

 

- убрали модификаторы (ocmod)
Вот только не понятно как можно убирать модификаторы, если с помощью событий еще можно сделать очень мало? И как при этом писать дополнения? Или будет как в версии 1.5 движка - отдельно OpenCart и отдельно все скачивали vQmod? 

- добавлена схема для базы данных
system/helper/db_schema.php 
Опять таки, зачем она нужна если запросы к базе все еще пишутся в одну строчку?
 
- для товара добавлены варианты
Можно указать главный товар и его варианты, например один товар с различными вариантами цветов, теперь это будут разные товары для каждого цвета со своими наборами опций, ценой, остатками и другими полями
 
- папка дополнений переехала
из
/catalog и /admin
в
/extension/opencart/catalog
/extension/opencart/admin
Свои же дополнения будут храниться в 
/extension/username/catalog
/extension/username/admin
спасибо @chukcha за уточнение

Суть это не меняет, но структуру файлов всех дополнений придется переделывать.

- неймспейсы теперь везде
было
class ModelCatalogProduct extends Model {
стало
namespace Opencart\Catalog\Model\Catalog;
class Product extends \Opencart\System\Engine\Model {

- и строгая типизация
было
public function getProducts($data) {
стало
public function getProducts(array $data = []): array {

 

Шаблон
- Bootstrap обновлен до 5 версии 
при этом поддержку font-awesome убрали, видимо иконки уже есть в Bootstrap

- jQuery 3.6 вместо 2.1 

- возможно, в движок будет добавлен React или Vue
Разговоры об этом идут, я уже писал об этом на форуме, также писал о том, насколько маловероятно что это будет реализовано  
 
- появилась новый шаблон 
product/thumb.twig 

 

для блока товара в категории, поиске, производителе итд. Более подробно тут
 
- появился новый шаблон 
common/pagination.twig
для пагинации
 
Админка
- появился новый тип дополнений - Startup
предположительно для добавления своих скриптов, которые будут выполняться при загрузке магазина

- появились задания крона
wget "http://localhost/opencart/4.0b/admin/index.php?route=common/cron" --read-timeout=5400


- добавлено GDPR Approvals для пользователей


- возле логотипа пользователя появился колокольчик

для уведомлений о новостях, новых версиях и обновлениях от OpenCart но по идее это могут использовать и сами модули для создания своих уведомлений. 


Общие впечатления

К сожалению, вот уже несколько новых мажорных версий, начиная со второй, вместо того, чтобы решать глобальные проблемы движка, такие как отсутствие нормальной системы расширений, отсутствие нормальных инструментов работы с базой данных, валидаторов, дублирование кода, устаревшее ядро движка, которое уже больше 10 лет как почти не изменяется, а также многие другие, OpenCart идет по пути "сделаем все красиво" и в каждой новой версии тратится куча времени для обновления дизайна, сначала добавили Bootstrap, потом в каждой новой версии его обновляют, добавили twig, обновили jQuery.. 
Каких-то кардинальных изменений я совсем не заметил, на мажорную версию это никак не тянет, максимум на 3.1. 
Хотя, работа над 4 версией еще не закончена, есть слабая надежда что еще что-то добавят. 

Если что-то пропустил  - дополняйте или поправляйте в комментариях. 

Products (1).png

Products.png

Dashboard.png

Administration.png

Your Store.png

  • +1 6

54 Comments


Recommended Comments



Цитата

- возле логотипа пользователя появился колокольчик

Вот чего больше всего не хватало опенкарту! :D

 

P.S. Интересно, ждет ли тройку хоть какой-то промежуточный релиз или на ней уже можно ставить крест

Link to comment
5 минут назад, RGB сказал:

P.S. Интересно, ждет ли тройку хоть какой-то промежуточный релиз или на ней уже можно ставить крест

Очень навряд ли, если уже работают над 4 версией то какой смысл выпускать новую версию для тройки? Тем более что если ее выпустить то потом все правки придется заново переносить на 4 версию. 

Link to comment

Нет кардинальных изменений в 4, поэтому больше 3 не должна развиваться.

А вообще, печаль беда. Но если прямо совсем не туда все пойдет, то прийдется форк делать от 2.3

А вообще нам без разницы. у меня и на 1.5 клиенты есть и на 3.0

  • +1 2
Link to comment

Мне 4ка на столько понравилась, что я оттуда сдёргнул в 2.3 кнопку сравнения и универсальное формирование куков для php 5.4-7.4+

Link to comment

- добавлена схема для базы данных
была и в тройке
Нужна  при смене версии

 

- появилась новый шаблон 

не только шаблоны но и контроллеры

Вся папка "встроенных" расширений

в

/extension/opencart/catalog


Свои можете добавлять

/extension/sv2109/catalog

 

 

 

 

 

 

 

Link to comment
Цитата
Из основного
- минимальная версия PHP - 8

"Warning: You need to use PHP8 or above for OpenCart to work!"

 

 

А почему вдруг такая категоричность случилась?

Это хоть чем-то обусловлено?

Даниель это как-то объясняет?

Что такого невероятно прорывного используется в коде php опенкарт, что он даже на 7.4 не будет работать?

Есть примеры?

 

Да и для чего такая заведомо невероятная несовместимость?

Далеко не у всех хостеров есть 8-ка для выбора. Да и не все расширения php есть для 8-ки.  ioncube нет пока, например.

 

Реального прогресса от 8-ки мы, думаю, вряд ли увидим в опенкарт, пока вижу это как "дурью маются".

  • +1 1
Link to comment

По поводу "как мы будем жить без OcMod"... Только на днях заметил, что начиная с 3.0.3.5 есть событие до загрузки файла шаблона, которое позволяет его изменить или поставить свой. Видимо это и ответ, причем не самый плохой.

 

Основная идея 8-ки - JIT, компиляция кода. Именно для нее и нужна повсеместная жесткая типизация.

Я раньше тестировал с компиляцией и без OpenCart 3, разницы не заметил. Никто не хочет потестировать, как в этом плане жестко типизированная 4-ка?

Link to comment
6 часов назад, MaxD сказал:

Только на днях заметил, что начиная с 3.0.3.5

Это было и в 2.3

Вариант хорош для единичного случая, когда ваше событие  - одно, а если их несколько?

Вот вам пример

getProductcs


точнее - вызов контроллера thumb, в который передаются
https://github.com/opencart/opencart/blob/d1546a0970976498603fa27d76fe8fdc065fdcbd/upload/catalog/controller/product/category.php#L205

 

Но Даниель противится передать туда сырой product_info ($result);

Link to comment
7 часов назад, MaxD сказал:

По поводу "как мы будем жить без OcMod"... Только на днях заметил, что начиная с 3.0.3.5 есть событие до загрузки файла шаблона, которое позволяет его изменить или поставить свой. Видимо это и ответ, причем не самый плохой

Там есть 2 события, а не одно, одно вызывается до рендеринга шаблона (before), а второе - после (after)
В первом можно изменить массив данных, которые передаются в сам шаблон, изменить те, которые есть или добавить свои. НО никак нельзя изменить сам шаблон. 
Во втором случае можно изменить output, только это не шаблон, а уже отрендеренный готовый html. Да, его теоретически можно изменить в этом событии, но это еще хуже, чем через ocmod:
1. потому что изменяем мы не шаблон, а готовый html.
Если в шаблоне напр. есть переменная {{ language }} и она одна, то в готовом html будет "Язык" или "Мова" или "Language" для каждого языка свое значение. 
Если в шаблоне напр. {{ price }} то в html будет своя цена для каждого товара итд. Если в шаблоне вывод 1 строки в цикле, то в готовом варианте будет 20 строк результата и что изменять каждую? 
2. в окмод есть кеш и все изменения сохраняются в кеше и потом берутся из кеша, тут же все делается на лету при каждой загрузке страницы
3. в окмод через кеш можно видеть сам файл, какие там изменения. Тут же мы изменили html код на лету, отдали результат и его движок сразу отдал в браузер, поэтому отладить будет намного сложнее. А когда будет  какой-то конфликт, когда один и тот же html код изменит несколько модулей то искать причину будет ой как весело.. А кто-то еще обязательно додумается свой обработчик события закодировать кубом и будет ад в энной степени)))

Насчет "поставить свой" это совсем не вариант, так как если есть несколько модулей которым нужно изменить один html код и кто-то самый умный заменит его на свой то все другие модули просто перестанут работать. 

И это по-вашему "не самый плохой вариант"? Да это настоящая жесть еще большая чем сам ocmod. Если в таком виде все будет добавлено в релиз четверки то сразу после этого кто-то сделает модификаторы модулем и всем придется доставлять его как раньше доставляли vqmod и будет хорошо если это будет один модуль а если их вдруг появится несколько или каждый разработчик напишет свой велосипед? То это вообще будет настоящий ад. 

И плюс это только работа с шаблонами, а как изменить контроллер через события? Никак.
Как изменить напр. sql запрос в модели если это нужно? Опять никак. Можно или подменить весь код на свой или изменить входные параметры и результат, но сами запросы - никак. 
Можно изменить данные при загрузке языков, но только от этого никакого, ведь потом их не вставишь ни в контроллер ни в шаблон через события. 
И вот в пользу этого всего сейчас удаляют модификаторы.. 

Link to comment
1 час назад, chukcha сказал:

getProductcs


точнее - вызов контроллера thumb, в который передаются
https://github.com/opencart/opencart/blob/d1546a0970976498603fa27d76fe8fdc065fdcbd/upload/catalog/controller/product/category.php#L205

 

Но Даниель противится передать туда сырой product_info ($result);

Да, это кстати бы решило немало проблем, так как можно бы было через событие после выполнения модели добавить в результат какие-то свои данные и они автоматически бы попали в шаблон минуя контроллер. Иначе теперь нужно как-то их прописать в контроллере, а такой возможности тупо нету и зачем тогда их изменять если потом с помощью событий сделать с ними вообще ничего нельзя? 
И это все при том, что события существуют начиная со второй версии движка (если не ошибаюсь) а уже на подходе 4-я.. 

Link to comment
12 минут назад, sv2109 сказал:

НО никак нельзя изменить сам шаблон. 

можно

 

14 минут назад, sv2109 сказал:

а как изменить контроллер через события? Никак.

легко
 

 

14 минут назад, sv2109 сказал:

Как изменить напр. sql запрос в модели если это нужно? Опять никак.

тут - да


 

Link to comment
9 минут назад, sv2109 сказал:

НО никак нельзя изменить сам шаблон. 

 

Так вот я как-раз говорю, что в 3.0.3.5 добавили возможность изменять шаблон:

// Template contents. Not the output!
$code = '';
		
// Trigger the pre events
$result = $this->registry->get('event')->trigger('view/' . $trigger . '/before', array(&$route, &$data, &$code));

...

$output = $template->render($this->registry->get('config')->get('template_directory') . $route, $code);

 

Если $code не пустой, то он используется вместо фактического текста шаблона. Получается, что можно модифицировать шаблон в обработчике события, и несколько дополнений, которые вносят изменения в один и тот же .twig, могут вполне себе уживаться.

 

Link to comment
11 минут назад, MaxD сказал:

 

Так вот я как-раз говорю, что в 3.0.3.5 добавили возможность изменять шаблон:


// Template contents. Not the output!
$code = '';
		
// Trigger the pre events
$result = $this->registry->get('event')->trigger('view/' . $trigger . '/before', array(&$route, &$data, &$code));

...

$output = $template->render($this->registry->get('config')->get('template_directory') . $route, $code);

 

Если $code не пустой, то он используется вместо фактического текста шаблона. Получается, что можно модифицировать шаблон в обработчике события, и несколько дополнений, которые вносят изменения в один и тот же .twig, могут вполне себе уживаться.

 

Ну я это видел. Но в первом случае в before $code - вообще пустой. Если кто-то не положит туда что-то из своего обработчика. Это не оригинальный шаблон, который можно изменить. 
А во втором случае смотрю по коду в 3037
в библиотеке шаблонизатора
 

public function render($filename, $code = '') {
    if (!$code) {
      $file = DIR_TEMPLATE . $filename . '.twig';

      if (is_file($file)) {
        $code = file_get_contents($file);
      } 
      ...
    }

    // initialize Twig environment
    $config = array(...);

    try {
      $loader = new \Twig\Loader\ArrayLoader(array($filename . '.twig' => $code));

      $twig = new \Twig\Environment($loader, $config);

      return $twig->render($filename . '.twig', $this->data);
    } 
...
  }

то есть этот $code, который сформирован обраточиком (или обработчиками) модулей просто заменяет оригинальный код шаблона. 
То есть изменить оригинальный код шаблона все равно никак нельзя. 
 

Link to comment

 

1 час назад, chukcha сказал:

легко

как? можно вызывать какой-то свой код До выполнения любого контроллера и После него.
И первый и второй практически бесполезны.
Но изменить сам контроллер никак нельзя, какую-то логику внутри. 

Link to comment
2 минуты назад, sv2109 сказал:

То есть изменить оригинальный код шаблона все равно никак нельзя. 
 

Ну это тривиально. В обработчике события, если передали пустой $code - в него надо самостоятельно загрузить оригинальный файл шаблона. А если не пустой - то работать, с тем что передали.

Link to comment

Правда не могу до конца понять как работает  ArrayLoader в твиг, там передается массив где ключ это файл, а значение - это код из обработчиков событий.

Link to comment
6 минут назад, MaxD сказал:

Ну это тривиально. В обработчике события, если передали пустой $code - в него надо самостоятельно загрузить оригинальный файл шаблона. А если не пустой - то работать, с тем что передали

как вариант, но все равно это очень кривое решение
1. как я могу быть уверен что если $code не пустой, что другой модуль до меня загрузил именно нужный мне файл? а не какой-то свой или что-то совсем другое? Ведь загрузить можно что угодно. Или что если я что-то изменю то кто-то другой после меня не загрузит свой вариант шаблона и не затрет все мои изменения? 
2. каждому модулю вручную загружать код шаблона из файлов не имея вообще никакого апи и инструментов для этого? Я поэтому и не увидел этот вариант что не мог подумать что подобная дичь доступна в движке, ведь это 100% работа движка работать с файлами шаблонов, а не модулей. 
А после загрузки что? каждому модулю так же вручную изменять его с помощью чего? str_replace и preg_replace?...

Да и чем этот вариант принципиально отличается от варианта с модификаторами? Там в шаблоне искали какой-то код и заменяли его на свой, создавая при этом кучу конфликтов и тут точно тоже самое, только если в модификаторах все делал сам движок по инструкциям в xml файле + было кеширование и возможность нормальной отладки, то тут каждый модуль будет это делать по своему через свой код и свои велосипеды (при чем код этот вообще может быть закрыт) в котором потом фиг разберешься, без кеша и возможности отладки.. 

Link to comment
2 часа назад, chukcha сказал:

 

2 часа назад, sv2109 сказал:

Как изменить напр. sql запрос в модели если это нужно? Опять никак.

тут - да

А что подменой метода из модели нельзя? Или вы про sql-запрос в самом методе?

 

2 часа назад, MaxD сказал:

Так вот я как-раз говорю, что в 3.0.3.5 добавили возможность изменять шаблон:

В смысле? Я что-то пропустил. Теперь можно менять не сам отрендереный html, а сам код twig?

Link to comment
46 минут назад, optimlab сказал:

А что подменой метода из модели нельзя? Или вы про sql-запрос в самом методе?

 

подмена есть, но подмена это возможность заменить что-то только одному модулю. А что если одну модель напр. модель товара нужно заменить десятку модулей, тогда как? 
Да, я об изменении самого sql запроса. 

 

47 минут назад, optimlab сказал:

В смысле? Я что-то пропустил. Теперь можно менять не сам отрендереный html, а сам код twig?

можно, как выше уже написали, но и одно и другое это ужасный костыль, даже хуже чем модификаторы, описал недостатки выше. 

Link to comment
9 часов назад, sv2109 сказал:

1. как я могу быть уверен что если $code не пустой, что другой модуль до меня загрузил именно нужный мне файл?

Никак, но должна быть своеобразная этика этого дела. Ситуация ничем не отличается от OCModа или других обработчиков событий - и там и там можно заменить все и наломать всем остальным модулям, которые вмешиваются в это место.

 

9 часов назад, sv2109 сказал:

2. каждому модулю вручную загружать код шаблона из файлов не имея вообще никакого апи и инструментов для этого?

 

Согласен, это достаточно странно, но в принципе ничего сложного:

if (!$code) $code = file_get_contents(DIR_TEMPLATE . $this->registry->get('config')->get('template_directory') . $route . '.twig');

 

9 часов назад, sv2109 сказал:

А после загрузки что? каждому модулю так же вручную изменять его с помощью чего? str_replace и preg_replace?...

В базовом варианте да. А так - можно использовать достаточно сложную логику, недостижимую в OCMod/vQmod, что однозначно плюс.

 

9 часов назад, sv2109 сказал:

Да и чем этот вариант принципиально отличается от варианта с модификаторами? 

Для шаблонов - принципиально ничем не отличается, кроме усложненной отладки. Но хоть какой-то вариант лучше, чем никакого.

 

9 часов назад, sv2109 сказал:

без кеша и возможности отладки.. 

С кешем, кстати, все нормально - при первом обращении к конкретному .twig результат записывается в PHP-файл кеша, как обычно. Правда, я не разбирался, зависит ли имя файла от содержимого $code, или только от названия шаблона. Но, похоже, что не зависит.

 

Меня в этой всей истории смущает другое. Мне кажется, что отличительной особенностью Opencart по сравнению с Wordpress/Prestashop/Magento было то, что можно было просто читать и менять код движка, быстро добиваясь нужного результата. Низкий порог входа, прямолинейное изменение и все такое. А с переходом на события становится "как у всех", когда для даже небольшой модификации надо сильно много думать и курить кучу доков.

  • +1 1
Link to comment
20 часов назад, optimlab сказал:

А что подменой метода из модели нельзя? Или вы про sql-запрос в самом методе?

я же правильно понимаю, что такой подменой ваш модуль шлет лесом любые изменения, внесенные модификаторами в стандартные методы getProducts, getInformations и т.д.?

Link to comment
17 минут назад, Blast сказал:

я же правильно понимаю, что такой подменой ваш модуль шлет лесом любые изменения, внесенные модификаторами в стандартные методы getProducts, getInformations и т.д.?

по идее не только модификаторами но даже событиями из других модулей, так как эти события привязаны с оригинальному роуту, а не к новому. Если это так, то ломается вообще все. 
 

 

12 часов назад, MaxD сказал:

Согласен, это достаточно странно, но в принципе ничего сложного:


if (!$code) $code = file_get_contents(DIR_TEMPLATE . $this->registry->get('config')->get('template_directory') . $route . '.twig');

подобные вещи по любому должны быть в самом движке, должна быть одна точка входа, иначе завтра логика загрузки может измениться и этот код работать не будет. Как измениться? Например если в 4 версии уберут модификаторы и оставят недоделанные события то каждому разработчику придется или изобретать какой-то свой велосипед для изменения файлов движка или загружать в движок какой-то модуль аналог модификаторов (да и не факт что он будет один а не несколько) и этот файл шаблона потом может лежать по разным путям. И что тогда?
Должна быть одна точка входа, тогда ее и изменить просто и работать с ней более удобно. 
Вот почему бы загрузку шаблона не закинуть вот сюда?
catalog/controller/event/theme.php
если в базе есть код шаблона (измененный через редактор) то загрузить его, если нету то загрузить из файла. 

 

 

12 часов назад, MaxD сказал:

Меня в этой всей истории смущает другое. Мне кажется, что отличительной особенностью Opencart по сравнению с Wordpress/Prestashop/Magento было то, что можно было просто читать и менять код движка, быстро добиваясь нужного результата. Низкий порог входа, прямолинейное изменение и все такое. А с переходом на события становится "как у всех", когда для даже небольшой модификации надо сильно много думать и курить кучу доков.

Мне кажется, что это иллюзорная простота. Когда сначала - да, открыл модификатор, добавил пару правил и все работает. Быстро и просто. Но потом это вылазит в  огромное к-во конфликтов которые исправлять приходится разработчикам, разбираясь в этом все кошмаре. И приходится иногда весь день тратить на всевозможные конфликты. И если на сайте установлено пару модулей то еще нормально, а если там десятки модулей + куча кастомного кода + еще тема в довесок на подобие какой-то джорнал и все, атас, попробуй найди причину почему что-то не работает?
С другой стороны события они более сложны сначала (хотя если все нормально сделано, а не такая уродская пародия как сейчас, и есть нормальная документация то все изучается за буквально пару часов), но потом к-во конфликтов уменьшается в десятки раз. Ты просто пишеш код и он работает! представляете, так оказывается можно! :) И не зря все другие движки переходят на события или хуки или их аналоги, потому что они намного более предсказуемы и дают возможность различным разработчикам писать дополнения которые не конфликтуют между собой. 
Похоже что уже даже Даниел это понял, так как не зря же он начал разрабатывать события если и модификаторами можно было все что нужно сделать? И не зря же в 4 версии модификаторы хотят удалить. 

Link to comment
В 07.06.2021 в 11:22, Blast сказал:

я же правильно понимаю, что такой подменой ваш модуль шлет лесом любые изменения, внесенные модификаторами в стандартные методы getProducts, getInformations и т.д.?

Да, верно. Вопрос правильный. Мне тоже не хватало метки информирующей какой файл вызывает то или иное событие. А то событие есть, а кто его вызвал непонятно.

Link to comment
37 минут назад, optimlab сказал:

какой файл вызывает то или иное событие.

Не файл
А..
метод!!!
Так событие привязывается к методу..

Другой вопрос
Из какого контроллера/метода вызвана, например модель
 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.