3.0.0.0 или Что нас ждет

[rb2]

Какой там пин? Там пох что. (Насколько мне показалось.) Salt, в общем.

[sv2109]

я уже ищу конвертер php to twig
вот такой нашел: https://php2twig.com/index.php 

[rb2]

1 minute ago, sv2109 said:

я уже ищу конвертер php to twig
вот такой нашел: https://php2twig.com/index.php 

А зачем? PHP "шаблонизатор" никто не отменял. Твиг - да, добавился.

Насколько помню, если .tpl - используется PHP, если *.twig - используется Twig шаблонизатор.

 

[chukcha]

Да, если явно указать тип шаблона .tpl то подключится  php "шаблонизатор"

 

Но если что-то встраивать в уже существующее - то все равно нужны минимальные знания twig

 

На самом деле он не сложнее, минус всего, как по мне, это сложность проверки вложеностей, т.е. фоматирования

{% for breadcrum in breadcrumbs %}

{% endfor %}

 

Т.е. тут все просто, одна две строки

А большие циклы? типа products, options

 

[sv2109]

5 minutes ago, rb2 said:

А зачем? PHP "шаблонизатор" никто не отменял. Твиг - да, добавился.

Насколько помню, если .tpl - используется PHP, если *.twig - используется Twig шаблонизатор.

 

в лоадере вот код:

$template = new Template($this->registry->get('config')->get('template_engine'));

то есть в настройках есть выбор шаблонизатора и можно выбрать php или twig но twig то по умолчанию и все файлы движка в twig, следовательно и свои модули нужно делать в twig (или и так и так, так как пользователь может выбрать любой вариант?).
Варианта использовать и файлы шаблона и twig и php чтобы один файл был такой а другой такой - нету. или я не вижу. Хотя несложно переделать класс  Template чтобы он понимал 2 типа. 

[ocdev_pro]

в system/config/catalog.php
 

// Template
$_['template_engine']    = 'twig';

Задать 'php' можно. И по сути ничего не измениться

в Ивентах есть условие которое определяет что использовать если twig не найден

        if (is_file(DIR_TEMPLATE . $view . '.twig')) {
            $this->config->set('template_engine', 'twig');
        } elseif (is_file(DIR_TEMPLATE . $view . '.tpl')) {
            $this->config->set('template_engine', 'php');
        }    

Вот и все проблема решена

[rb2]

Знания - нужны. Конвертировать всё подряд из PHP в Twig - по-моему, нет.

Хотя я с твигом не работал (и смысла не вижу), так что сильно упорствовать не буду. Но мне кажется, что это херня какая-то.

 

Будет 90% кода в шаблонах абсолютно тем же, что и был, только с другими скобочками.

Поменялись `<? ... ?>` на `{% ... %}` - и все дела. И добавилась прослойка над PHP. Ну офигеть. Надо было сразу версию на 5.0.0.0 менять.

 

3 minutes ago, chukcha said:

На самом деле он не сложнее, минус всего, как по мне, это сложность проверки вложеностей,

Теперь вся надежда на плагины твига для IDE и редакторов

 

[markimax]

Наблюдал, я наблюдал ... думаю когда вы уже дойдете до twig и увидите этот 3.14
1. В админке все шаблоны twig - одновременно twig и php tpl  работать не могут - всю админку все равно переписывать на twig придется

2. Основная задача шаблонизаторов - это не "красивый" код, а кеширование php кода. В opencart кеширование twig отключено (из-за архитектурных особенностей opencart и twig (смотрю Даниэль пытается все привести в порядок под кеширование, но .. там все запутано под самые "не могу"). Как следствие имеем новые тормоза, так как вместо прямого выполнения кода php в tpl надо еще таким же "количеством" (как у opencart) классов парсить все twig шаблоны - т е маразм полный (можете потестировать - я потестировал скорость упала почти в 1.5 раза на default главной).  Короче Даниэль прогнулся под каким то очередным спонсором у которого было все шаблоны написаны на twig. Ладно добавил "ты" шаблонизатор twig, но зачем его делать основным по умолчанию!

Другого объяснения этому маразму я найти не могу пока

[rb2]

4 minutes ago, markimax said:

Наблюдал, я наблюдал ... думаю когда вы уже дойдете до twig и увидите этот 3.14

 

Месяца 2 назад.

[sv2109]

4 minutes ago, markimax said:

1. В админке все шаблоны twig - одновременно twig и php tpl  работать не могут - всю админку все равно переписывать на twig придется

 

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

[markimax]

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

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

 Можно указать в коде своих контроллеров $this->config->set('template_engine', 'php'); и будет работать php tpl, но тогда "меню" админ части (то что слева) и header, footer  просто переписать под tpl

[sv2109]

9 minutes ago, markimax said:

 Можно указать в коде своих контроллеров $this->config->set('template_engine', 'php'); и будет работать php tpl, но тогда "меню" админ части (то что слева) и header, footer  просто переписать под tpl

тогда уже как-то так:

$template = this->config->get('template_engine');

$this->config->set('template_engine', 'php');
$this->load->view('my_view', $data);

$this->config->set('template_engine', $template);

но все равно изменить один класс шаблона будет проще, чем городить такие конструкции в каждом шаблоне. 

[markimax]

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

тогда уже как-то так:

$template = this->config->get('template_engine');

$this->config->set('template_engine', 'php');
$this->load->view('my_view', $data);

$this->config->set('template_engine', $template);

но все равно изменить один класс шаблона будет проще, чем городить такие конструкции в каждом шаблоне. 

НУ это уже как кому удобнее.

Здесь другое совсем. Факт тот, что шаблонизатор twig в opencart - это новые и достаточно ощутимые тормоза. Т е пламенный "привет" пользователям любящим PS попугаи. Им все равно какие там twig - и фиги стоят - им скорость нужна. Так что маразм (или "прогинание") Даниэля ощутимый здесь.
Кстати presta очень много потеряла комьюнити разработчиков из-за использования смарти как раз (которые перешли на opencart и magento). Шаблонизаторы - тупиковый путь

[chukcha]

58 минут назад, Waha сказал:

в system/config/catalog.php
 

// Template
$_['template_engine']    = 'twig';

Задать 'php' можно. И по сути ничего не измениться

в Ивентах есть условие которое определяет что использовать если twig не найден

        if (is_file(DIR_TEMPLATE . $view . '.twig')) {
            $this->config->set('template_engine', 'twig');
        } elseif (is_file(DIR_TEMPLATE . $view . '.tpl')) {
            $this->config->set('template_engine', 'php');
        }    

Вот и все проблема решена

Что это?

[markimax]

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

тогда уже как-то так:

$template = this->config->get('template_engine');

$this->config->set('template_engine', 'php');
$this->load->view('my_view', $data);

$this->config->set('template_engine', $template);
 

 

Работает вот так:

$template_engine = $this->config->get('template_engine');
$this->config->set('template_engine', 'php');
...
...
$this->config->set('template_engine', $template_engine);
$data['header'] = $this->load->controller('common/header');
$data['menu'] = $this->load->controller('common/menu');
$data['footer'] = $this->load->controller('common/footer');
$data['column_left'] = $this->load->controller('common/column_left');
$this->config->set('template_engine', 'php');
$template = '.../...';
$html = $this->load->view($template, $data);
$this->response->setOutput($html);

Скрытый текст

Как оказалось изменения вообще минимальны "пара" строчек кода на вывод (что выше) и token на user_token поменять
Всё работает отлично

[chukcha]

Но это админский event

[sv2109]

Да, судя по коду в админке через события можно использовать и tpl и twig, но нужно проверить. 
Почему этого нету в каталоге не понятно, но можно добавить. 

[markimax]

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

но все равно изменить один класс шаблона будет проще, чем городить такие конструкции в каждом шаблоне. 

Лучше "engine" не трогать, чтобы не было проблем с совместимостью.
Все отлично работает и без вмешательств в "engine"

[sv2109]

41 minutes ago, chukcha said:

Но это админский event

Смотрю как это событие подключается, 
а подключается оно в 2-х конфигах:
system/config/install.php
system/config/extension.php

где есть
$_['action_event']     = array(
  'view/*/before'                 => 'event/theme',
)

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

Дальше в system/framework.php
добавляются все события:
$event = new Event($registry);
$registry->set('event', $event);
// Event Register
if ($config->has('action_event')) {
  foreach ($config->get('action_event') as $key => $value) {
    foreach ($value as $action) {
      $event->register($key, new Action($action));
    }
  }
}
 

и в лоадере system/engine/loader.php
для view 
есть

$result = $this->registry->get('event')->trigger('view/' . $trigger . '/before', array(&$route, &$data));

то есть при вызове каждого view вызывается это событие "event/theme", там как его повесили на 'view/*/before'
 

Осталось понять где подключается конфиг system/config/extension.php
так как я не вижу по коду где он подключается, если нигде, то и это событие не работает. 
+ это все равно только для админки работать будет, не для каталога, так как только в событии для админки есть проверка расширения шаблона. 

 

[chukcha]

в  startup/event.php

 

А сам event уже находится в базе

 

[chukcha]

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

system/config/extension.php

где есть
$_['action_event']     = array(
  'view/*/before'                 => 'event/theme',
)

Это скорей всего для доп расширений, вне пределов ядра

[ocdev_pro]

Кароче все очень сыро, неверняка пару релизов минорной версии поставят все точки над Ы ) Но не факт что вскоре не появиться 4.0 ))

[ocdev_pro]

Если будет автообновление внятное, то вопросов с совместимостью думаю больше не возникнет

[markimax]

Да подчеркну все же преимущества шаблонизаторов

«Преимущество» шаблонизаторов только в одном
Чтобы криворукие идиоты не вставляли в tpl new Class() и т.п. вызовы которые должны быть в контроллерах

[ArtemPitov]

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

Чтобы криворукие идиоты не вставляли в tpl new Class()

ну это еще цветочки, вот когда запросы к безе с подключением прям там лупят вот это веселее