Блог sv2109

Циии

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

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

 

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 сказал:

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

Да лучше?

 

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