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

Цитата

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

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

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

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

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

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

Спасибо за статью! 

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

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

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

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

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

в

/extension/opencart/catalog

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

/extension/sv2109/catalog

Цитата

Из основного

- минимальная версия PHP - 8

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

 

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

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

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

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

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

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

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

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

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

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

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

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);

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 запрос в модели если это нужно? Опять никак. Можно или подменить весь код на свой или изменить входные параметры и результат, но сами запросы - никак. 
Можно изменить данные при загрузке языков, но только от этого никакого, ведь потом их не вставишь ни в контроллер ни в шаблон через события. 
И вот в пользу этого всего сейчас удаляют модификаторы.. 

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

getProductcs


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

 

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

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

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

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

можно

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

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

легко
 

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

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

тут - да


 

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, могут вполне себе уживаться.

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, который сформирован обраточиком (или обработчиками) модулей просто заменяет оригинальный код шаблона. 
То есть изменить оригинальный код шаблона все равно никак нельзя. 
 

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

легко

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

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

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

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

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

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

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

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

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

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

 

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

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

тут - да

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

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

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

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

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

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

 

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

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

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

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

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 было то, что можно было просто читать и менять код движка, быстро добиваясь нужного результата. Низкий порог входа, прямолинейное изменение и все такое. А с переходом на события становится "как у всех", когда для даже небольшой модификации надо сильно много думать и курить кучу доков.

20 часов назад, optimlab сказал:

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

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

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 версии модификаторы хотят удалить. 

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

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

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

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

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

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

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

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

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

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

какой файл контроллера/метода вызывает то или иное событие

Так лучше?

Лучше бы запостил Диниелю идею, чем кричать...