Fenom VS Smarty
Недавно Михаил попросил меня написать сравнительный обзор Fenom и Smarty. Честно сказать, я феномом не пользовался, и хотя сейчас уделил время на какое-то его изучение, все-таки не смогу выдать какое-то сильно аргументированное заключение, просто потому что много в феном мог и не увидеть (хотя оно там может даже и есть). Тем не менее, я приведу несколько примеров использования Smarty, которые довольно часто используются на практике, но которых я не увидел в Феноме, а те, кто хорошо знает Феном, пусть поправят меня или подтвердят.
Для начала следует отметить, что все-таки эти инструменты хоть и схожие, но изначально судя по всему ориентированы на разные цели. Феном (в рамках pdoTools) на родные MODX-сущности (чанки, шаблоны и т.п.), а Смарти (в том числе и в рамках modxSmarty) на работу с файлами. Потому, еще раз, их немного сложно сравнивать. Ну да ладно, это все лирика. Разберем лучше на реальных примерах.
Одновременно несколько директорий шаблонов (скинов).
Что в первую очередь искал в феноме, но не увидел — это работа с несколькими директориями шаблонов. Тут стоит оговориться, что я имею ввиду разделы в файловой системе, но это может быть и какое-то другое групповое отличие. В любом случае, идея в том, чтобы можно было не просто одним чанком расширить другой чанк, а одну группу чанков сменить другой группой чанков, чтобы получить совершенно новое оформление. Приведу пример, как это работает в Смарти. К примеру, у нас есть вот такая структура joxi.ru/KAxeRO7c4n0JGr
Здесь у нас есть основной полноценный шаблон (скин сайта) shopmodx с кучей шаблон-файлов. Так вот, если я хочу какие-то шаблон-файлы основного скина переопределить (полностью или частично), мне не обязательно где-то что-то модифицировать. Мне достаточно Смарти добавить еще одну (а можно и не одну) директорию шаблонов, и смарти при вызове шаблонов будет перебирать все эти директории, пока не найдет запрошенный шаблон.
…
На самом деле ряд моментов я опущу, так как все это такие тонкости, которые на конкретных задачах рассматриваются. Но вот сегодня дополнительно тестировал Феном и столкнулся с парой неприятных для меня моментов:
1. Вызов произвольных функций.
К примеру, в Смарти я легко могу написать {print_r($array)}, или {array_sum([1,3,4,6,7])}. Вот в Феном я этого не смог сделать. Ошибка. Вопрос: он вообще это умеет делать?
2. Доступ к объекту $modx
Вот это вообще тема… Довольно часто я в шаблонах обращаюсь к API MODX. Например, {if $modx->user->id} это проверка наличия пользователя. Если пользователь в админке авторизовался, то он и во фронте будет виден и все политики для него будут работать. А вот {if $modx->user->isAuthenticated()} будет себя иначе вести, так как этот метод проверяет, авторизован ли пользователь именно в этом контексте (по умолчанию web), а так как авторизовавшись в админке пользователь авторизован только в контексте mgr, то во фронте при такой проверке пользователя не будет.
Другой пример {if $modx->resource->Parent->published}, то есть я в шаблоне просто хочу проверить опубликован ли родитель текущего документа или нет. И вот в Феном я этого просто так не могу сделать (на самом деле могу, но это далее). То есть у меня просто нет объекта {$modx}. Есть объект {$_modx}, но это вообще мало отношения к $modx имеет, так как это кастомный тонкий клиент между шаблоном и реальным объектом $modx. К слову, вот это у меня больше всего вопросов и вызвало. Зачем прятать объект $_modx->modx? Зачем он приватный? Ведь так мы теряем полноценный доступ к API MODX. Для секурности? Но полноценной секурности здесь нет, ибо ничто мне не мешает обратиться к $modx через объект {$_modx->lexicon->modx} или {$_modx->cacheManager->modx}, а вот головной боли мне это серьезно добавляет и урезает творческую реализацию.
В общем, надо будет еще все это как следует погонять. Но так или иначе, Феном все-таки тоже весьма не плохо, хотя мне и не получается пока на нем разгуляться.
Для начала следует отметить, что все-таки эти инструменты хоть и схожие, но изначально судя по всему ориентированы на разные цели. Феном (в рамках pdoTools) на родные MODX-сущности (чанки, шаблоны и т.п.), а Смарти (в том числе и в рамках modxSmarty) на работу с файлами. Потому, еще раз, их немного сложно сравнивать. Ну да ладно, это все лирика. Разберем лучше на реальных примерах.
Одновременно несколько директорий шаблонов (скинов).
Что в первую очередь искал в феноме, но не увидел — это работа с несколькими директориями шаблонов. Тут стоит оговориться, что я имею ввиду разделы в файловой системе, но это может быть и какое-то другое групповое отличие. В любом случае, идея в том, чтобы можно было не просто одним чанком расширить другой чанк, а одну группу чанков сменить другой группой чанков, чтобы получить совершенно новое оформление. Приведу пример, как это работает в Смарти. К примеру, у нас есть вот такая структура joxi.ru/KAxeRO7c4n0JGr
Здесь у нас есть основной полноценный шаблон (скин сайта) shopmodx с кучей шаблон-файлов. Так вот, если я хочу какие-то шаблон-файлы основного скина переопределить (полностью или частично), мне не обязательно где-то что-то модифицировать. Мне достаточно Смарти добавить еще одну (а можно и не одну) директорию шаблонов, и смарти при вызове шаблонов будет перебирать все эти директории, пока не найдет запрошенный шаблон.
…
На самом деле ряд моментов я опущу, так как все это такие тонкости, которые на конкретных задачах рассматриваются. Но вот сегодня дополнительно тестировал Феном и столкнулся с парой неприятных для меня моментов:
1. Вызов произвольных функций.
К примеру, в Смарти я легко могу написать {print_r($array)}, или {array_sum([1,3,4,6,7])}. Вот в Феном я этого не смог сделать. Ошибка. Вопрос: он вообще это умеет делать?
2. Доступ к объекту $modx
Вот это вообще тема… Довольно часто я в шаблонах обращаюсь к API MODX. Например, {if $modx->user->id} это проверка наличия пользователя. Если пользователь в админке авторизовался, то он и во фронте будет виден и все политики для него будут работать. А вот {if $modx->user->isAuthenticated()} будет себя иначе вести, так как этот метод проверяет, авторизован ли пользователь именно в этом контексте (по умолчанию web), а так как авторизовавшись в админке пользователь авторизован только в контексте mgr, то во фронте при такой проверке пользователя не будет.
Другой пример {if $modx->resource->Parent->published}, то есть я в шаблоне просто хочу проверить опубликован ли родитель текущего документа или нет. И вот в Феном я этого просто так не могу сделать (на самом деле могу, но это далее). То есть у меня просто нет объекта {$modx}. Есть объект {$_modx}, но это вообще мало отношения к $modx имеет, так как это кастомный тонкий клиент между шаблоном и реальным объектом $modx. К слову, вот это у меня больше всего вопросов и вызвало. Зачем прятать объект $_modx->modx? Зачем он приватный? Ведь так мы теряем полноценный доступ к API MODX. Для секурности? Но полноценной секурности здесь нет, ибо ничто мне не мешает обратиться к $modx через объект {$_modx->lexicon->modx} или {$_modx->cacheManager->modx}, а вот головной боли мне это серьезно добавляет и урезает творческую реализацию.
В общем, надо будет еще все это как следует погонять. Но так или иначе, Феном все-таки тоже весьма не плохо, хотя мне и не получается пока на нем разгуляться.
Комментарии: 45
Нужно просто в настройках включить использование php в Fenom и доступ к объекту modx. Тогда эти два момента разрешатся.
Это для безопасности — вдруг на сайте есть контент-менеджер, который может править чанки.
Это для безопасности — вдруг на сайте есть контент-менеджер, который может править чанки.
Спасибо! ОК, уже легче дышется :)
Если вдруг кто тоже не сразу нашел: joxi.ru/82QV3dNu1DovgA
Если вдруг кто тоже не сразу нашел: joxi.ru/82QV3dNu1DovgA
Это для безопасности — вдруг на сайте есть контент-менеджер, который может править чанки.Ну, как я и сказал, есть как минимум {$_modx->cacheManager->modx}, хотя и можно это тоже перекрыть. А второе: админка в MODX — это уже зона риска огромная, так что нефиг туда вообще никого лишнего пускать :)
А вот это я пропустил, спасибо — отключу в новых версиях обязательно.
Суть в том, что пользоваться {$_modx} можно давать кому угодно, он только для чтения, грубо говоря. Тогда как через {$modx} можно легко убить всю систему. По этой же причине и php функции отключены по умолчанию.
Суть в том, что пользоваться {$_modx} можно давать кому угодно, он только для чтения, грубо говоря. Тогда как через {$modx} можно легко убить всю систему. По этой же причине и php функции отключены по умолчанию.
Не, если в конфигах включается, то ОК. Я просто пропустил.
И вот такой вопрос: Есть два чанка fenom1 и fenom2. В документе пишу [[$fenom]] и ок, на странице все выводится. Но если я в чанке fenom1 пишу {extends 'fenom2'}, то он расширяет второй чанк, но на странице выводится только содержимое чанков (ничего более от шаблона). Можно как-то расширять другие чанки или что я не так делаю? Шаблоны корректно расширяются.
И вот такой вопрос: Есть два чанка fenom1 и fenom2. В документе пишу [[$fenom]] и ок, на странице все выводится. Но если я в чанке fenom1 пишу {extends 'fenom2'}, то он расширяет второй чанк, но на странице выводится только содержимое чанков (ничего более от шаблона). Можно как-то расширять другие чанки или что я не так делаю? Шаблоны корректно расширяются.
Ты пишешь только
Или прям расширяешь его?
{extends 'fenom2'}
Или прям расширяешь его?
{extends 'fenom2'}
{block 'some_name'}
Тут то, что расширили
{/block}
А то недавно Иван Климчук заметил, что без переопределения хотя бы одного блока ничего не работает и дописал это в доки.
Нет, я именно расширяю с переопределением блоков.
joxi.ru/a2XVypGuy0Bzjr
joxi.ru/ZrJVWD0u13PO4r
По всякому игрался, результат один и тот же.
joxi.ru/a2XVypGuy0Bzjr
joxi.ru/ZrJVWD0u13PO4r
По всякому игрался, результат один и тот же.
Хм. А чанк fenom3 как выглядит?
sdfsdf3
{block 'test'}
dfdf666
{var $test = '222222'}
{/block}
Не вижу никакого криминала, вроде всё должно быть ок.
Посмотри, может где-то какие-то ошибки в логах есть? По идее, всё должно расширяться без проблем — сам этим пользуюсь постоянно на разных проектах.
Посмотри, может где-то какие-то ошибки в логах есть? По идее, всё должно расширяться без проблем — сам этим пользуюсь постоянно на разных проектах.
Всё, увидел этот баг на тестовом сайте.
Чанк с расширением нужно вызывать некэшируемым:
Чанк с расширением нужно вызывать некэшируемым:
[[!$fenom1]]
Или можно так:{$_modx->getChunk('fenom1')}
Тогда никаких белых страниц, всё работает.
Это не бага, все логично. Просто MODX отрабатывает окончательно весь код документа (вместе с кодом шаблона) уже на уровне modResponse::outputContent(). Немного модифицируем код:
То есть это весь код шаблона и страницы, и в нем код чанка fenom1 как есть, вместе с расширением {extended}. То есть расширение уже становится не чанка, а по сути шаблона. В общем, контекст не тот уже.
Здесь надо мыслить как с этим поступить. Самое правильное, как мне кажется — это даже в рамках шаблона отрабатывать чанки сразу. Или договориться о том, что нельзя использовать кешируемые чанки с расширением других чанков.
К слову, Смарти не позволяет декларирование {extends} иначе как в начале кода. А тут он де факто получается внутри.
public function outputContent(array $options = array()) {
if (!($this->contentType = $this->modx->resource->getOne('ContentType'))) {
if ($this->modx->getDebug() === true) {
$this->modx->log(modX::LOG_LEVEL_DEBUG, "No valid content type for RESOURCE: " . print_r($this->modx->resource->toArray(), true));
}
$this->modx->log(modX::LOG_LEVEL_FATAL, "The requested resource has no valid content type specified.");
}
if (!$this->contentType->get('binary')) {
$this->modx->resource->_output= $this->modx->resource->process();
$this->modx->resource->_jscripts= $this->modx->jscripts;
$this->modx->resource->_sjscripts= $this->modx->sjscripts;
$this->modx->resource->_loadedjscripts= $this->modx->loadedjscripts;
/*
Здесь добавим вывод текущего контента и прервем обработку
*/
print $this->modx->resource->_output;
exit;
/* collect any uncached element tags in the content and process them */
$this->modx->getParser();
Обновляем страницу и получаем такой результат: joxi.ru/VrwoaO9IKVPyXrТо есть это весь код шаблона и страницы, и в нем код чанка fenom1 как есть, вместе с расширением {extended}. То есть расширение уже становится не чанка, а по сути шаблона. В общем, контекст не тот уже.
Здесь надо мыслить как с этим поступить. Самое правильное, как мне кажется — это даже в рамках шаблона отрабатывать чанки сразу. Или договориться о том, что нельзя использовать кешируемые чанки с расширением других чанков.
К слову, Смарти не позволяет декларирование {extends} иначе как в начале кода. А тут он де факто получается внутри.
Лично я ничего с этим делать не планирую.
Вызов Fenom чанков через Fenom синтаксис работает без проблем — лучше так и делать =)
Вызов Fenom чанков через Fenom синтаксис работает без проблем — лучше так и делать =)
ОК.
Всё, заменил lexicon и cacheManager с публичным свойством $modx на свои, ограниченные.
Теперь, насколько я вижу, из {$_modx} до modX добраться не выйдет. Спасибо, что указал на эту уязвимость!
Теперь, насколько я вижу, из {$_modx} до modX добраться не выйдет. Спасибо, что указал на эту уязвимость!
Василий, извини, что поддаюсь на провокацию, но не могу не наделать пакостей)) Это просто к тому, что нет смысла что-то подобное запрещать тем, кто имеет доступ к редактированию чего-то в админке. Это все ограничивает в творчестве, но все равно не сильно увеличивает безопасность.
Вот я отключил в настройках доступ к $modx и выполнение php. ОК. А теперь я хоть в чанке, хоть в контенте документа (не имея доступа к чанкам и т.п.) пишу вот такое:
Вот я отключил в настройках доступ к $modx и выполнение php. ОК. А теперь я хоть в чанке, хоть в контенте документа (не имея доступа к чанкам и т.п.) пишу вот такое:
{var $opt = $_modx->config}
{$opt.pdotools_fenom_modx = 1}
{$opt.pdotools_fenom_php = 1}
{$_modx->cacheManager->set('config', $opt, 0, [
"cache_key" => "system_settings/",
])}
Что я здесь делаю, не трудно догадаться: я просто перетираю кеш системных настроек MODX-а с новыми значениями настроект. И при повторном заходе на страницу (с перезаписанными настройками), я уже могу делать все, что угодно, включая {$modx->user->sudo = 1} {$modx->user->save()}. Сорри, но это ппц какая дыра в безопасности.
Круто, богатая у тебя фантазия! Придётся отключать cacheManager совсем.
Хотя нет, не отключать, а просто запретить указывать такие настройки. Выложил новую версию, в которой параметр $options у cacheManager::set() не используется. Итого, кэш получать можно любой, а сохранять только в default.
Твой ход =)
Хотя нет, не отключать, а просто запретить указывать такие настройки. Выложил новую версию, в которой параметр $options у cacheManager::set() не используется. Итого, кэш получать можно любой, а сохранять только в default.
Твой ход =)
Предвидел я это. Про то и говорю: ты замахаешься все отключать, это все будет ограничивать разработчиков, но все равно где-то дыры будут. Потом где-то регистрацию сделают и человек что-то подобное в своем имени укажет или еще где-то. Проблема тут в том, что откуда бы код не взялся, он в итоге собирается в единое и потом на уровне modResponse отрабатывается как единый шаблон. Это та же проблема, по которой MODX фильтрует MODX-теги в запросах. Вот та же головная боль возникает и здесь. Возможно тут надо подумать немного в другом направлении, как вариант — не отрабатывать все как феном-код на конечном этапе modResponse, хотя это мне и кажется в рамках текущей парадигмы маловероятным. Для сравнения у меня Смарти отрабатывается только на уровне Смарти, не обрабатывая потом его шаблонизатором содержимого чанков, документа и т.п. То есть в контент можно писать смарти-теги, но они будут просто как текст для него. Тут получается и в творчестве не ограничен (на уровне смарти-шаблонов можно писать что угодно) и секурней, потому как вряд ли у кого-то постороннего будет доступ к смарти-шаблонам, а в контент пусть что угодно пишет.
Проблема тут в том, что откуда бы код не взялся, он в итоге собирается в единое и потом на уровне modResponse отрабатывается как единый шаблон.Это отключено по умолчанию. Так же как и доступ в php и modX.
А доступ в {$_modx} включен по умолчанию и он должен быть безопасным. Сегодня ты очень сильно помог в этой задаче. Надеюсь, что больше никаких уязвимостей при конфигурации по умолчанию не найдётся.
Если же разработчик (не редактор) хочет — он может смело всё включить. Но он должен это сделать сам, понимая, чем рискует.
ОК. Если в процессе на что-то наткнусь, дам знать.
Василий, не подскажешь, что я делаю не так?
Вызов в шаблоне:
{$_modx->runSnippet('temp')}
Сниппет:
<?php
$output = $modx->getChunk('testChunkCommon', array('some_placeholder' => 'some_placeholder'));
return $output;
Содержимое testChunkCommon.tpl:
1: {$some_placeholder}
2: {$_pls['some_placeholder']}
3: {$_modx->getPlaceholder('some_placeholder')}
4: [[+some_placeholder]]
Результат:
1:
2:
3:
4: some_placeholder
Вызов в шаблоне:
{$_modx->runSnippet('temp')}
Сниппет:
<?php
$output = $modx->getChunk('testChunkCommon', array('some_placeholder' => 'some_placeholder'));
return $output;
Содержимое testChunkCommon.tpl:
1: {$some_placeholder}
2: {$_pls['some_placeholder']}
3: {$_modx->getPlaceholder('some_placeholder')}
4: [[+some_placeholder]]
Результат:
1:
2:
3:
4: some_placeholder
testChunkCommon.tpl у тебя чанк, а обращаешься к testChunkCommon
И? Я не правильно обращаюсь?
Не знаю, у меня вот так всё работает:
Если я неправильно понимаю, чего ты хочешь добиться — покажи свою проблему на чистом тестовом сайте.
{$_modx->getChunk('@INLINE {$some_placeholder}', [
'some_placeholder' => 'some_placeholder'
])}
Значит, проблем с обработкой плейсхолдеров Fenom в чанке нет.Если я неправильно понимаю, чего ты хочешь добиться — покажи свою проблему на чистом тестовом сайте.
modx.pro/development/7162-example-fenom/#comment-50656
Зато все значения выводятся при вызове сниппета [[!temp]]
Тестовый сайт:
s3660.h2.modhost.pro/test.html
user: s3660
pass: a0VU4iiGhkmb
Зато все значения выводятся при вызове сниппета [[!temp]]
Тестовый сайт:
s3660.h2.modhost.pro/test.html
user: s3660
pass: a0VU4iiGhkmb
$output = $modx->getChunk('testChunk', array('some_placeholder' => 'value'));
Смешно.С каких это пор сам MODX научился работать с Fenom?
$pdo = $modx->getService('pdoTools');
$output = $pdo->getChunk('testChunk', array('some_placeholder' => 'value'));
Спасибо, я не совсем понимал логику работы парсера.
MODX не знает ничего про Fenom, только pdoTools с ним может работать. Соотвественно, и обрабатывать чанк нужно не через методы MODX, а через методы pdoTools.
Помню, что в документации написано было, «Эти способы загрузки чанков работают во всех родных сниппетах pdoTools и во всех других, которые используют методы pdoTools getChunk и parseChunk.» Но почему-то решил, что когда в системных настройках указать joxi.ru/VrwWGlWfKKxvMr, то это распространиться и на обычные чанки.
P.S. Вот теперь fenom будет у меня повсюду :)
P.S. Вот теперь fenom будет у меня повсюду :)
Спасибо за это разъяснение! Буду уже везде pdoTools использовать для работы с чанками.
Но всё же это не решает проблему с сниппетами, которые писал не я, например с Office или HybridAuth — у них точно такая же проблема с плейсхолдерами.
Но всё же это не решает проблему с сниппетами, которые писал не я, например с Office или HybridAuth — у них точно такая же проблема с плейсхолдерами.
Николай, обзор интересный, спасибо. Но получился неполным из-за незамеченных тобой системных настроек, на которые Илья уже указал.
Ждать вторую, более развернутую часть сравнения?
Ждать вторую, более развернутую часть сравнения?
Не за что.
Более развернутую? Вряд ли. При включенных $modx и php в рамках самого MODX API и php никаких отличий не может быть. А по поводу отличий на уровне самой шаблонизации я в топике писал:
По поводу более расширенных возможностей Смарти:
Пример 1. Скрываемые блоки hide.
В основном шаблоне мы пишем
Во-первых, я не увидел в Феноме возможность указывать дочерние блоки. То есть можно в расширяющем шаблоне в блоке прописать {parent} и туда выведется родительский блок, но нельзя указать {child}, чтобы туда вывелось содержимое дочернего блока.
Во-вторых, интересен блок hide (его можно использовать и без $smarty.block.child, он от него не зависит) — если в расширяющем шаблоне нет этого блока или содержимое блока будет пустым, то и родительский блок не выводится. В нашем случае, если в расширяющем шаблоне не будет определен сам баннер, то и базовое обрамление тоже не будет выведено.
Пример 2. Инклюды с кешированием.
Тоже этого не увидел в Феноме.
Всем известно, что MODX кеширует конечный код для каждой страницы в отдельности. То есть даже если у вас кешируемый чанк, то на каждой отдельной странице при первом заходе он будет отрабатываться. Но если вещи, которые вообще не меняются на всем сайте (например, подвал). В Смарти я могу вот так легко сделать: {include $template cache_id=«footer»} и этот шаблон будет вызван только один раз, а все остальные вызовы будут уже из кеша.
Более развернутую? Вряд ли. При включенных $modx и php в рамках самого MODX API и php никаких отличий не может быть. А по поводу отличий на уровне самой шаблонизации я в топике писал:
…То есть какие-то моменты я уже начал писать, но потом стер, так как все-таки под разные задачи создавались эти модули. Феном уступает в некоторых моментах (пару примеров все-таки ниже приведу), но зато он добавляет логику на уровне самих MODX-шаблонов и чанков. modxSmarty мощнее в плане самой шаблонизации, но не отрабатывает смарти-теги в самих MODX-шаблонах и чанках (хотя техническая возможность на самом деле есть, и если есть интерес к этому, это можно обсудить отдельно).
На самом деле ряд моментов я опущу, так как все это такие тонкости,
По поводу более расширенных возможностей Смарти:
Пример 1. Скрываемые блоки hide.
В основном шаблоне мы пишем
{block banner hide}<div class="banner">
{$smarty.block.child}
</div>{/block}
Во-первых, я не увидел в Феноме возможность указывать дочерние блоки. То есть можно в расширяющем шаблоне в блоке прописать {parent} и туда выведется родительский блок, но нельзя указать {child}, чтобы туда вывелось содержимое дочернего блока.
Во-вторых, интересен блок hide (его можно использовать и без $smarty.block.child, он от него не зависит) — если в расширяющем шаблоне нет этого блока или содержимое блока будет пустым, то и родительский блок не выводится. В нашем случае, если в расширяющем шаблоне не будет определен сам баннер, то и базовое обрамление тоже не будет выведено.
Пример 2. Инклюды с кешированием.
Тоже этого не увидел в Феноме.
Всем известно, что MODX кеширует конечный код для каждой страницы в отдельности. То есть даже если у вас кешируемый чанк, то на каждой отдельной странице при первом заходе он будет отрабатываться. Но если вещи, которые вообще не меняются на всем сайте (например, подвал). В Смарти я могу вот так легко сделать: {include $template cache_id=«footer»} и этот шаблон будет вызван только один раз, а все остальные вызовы будут уже из кеша.
habrahabr.ru/post/169525/ — если брать на заметку анализ производительности, то Fenom решает.
Это обсуждали еще в прошлой статье. При повторном заходе разница не существенная.
По феному вскрылся серьезный минус, касающийся производительности. modx.pro/help/7278/#comment-51096
Василий, это будет исправлено?
Василий, это будет исправлено?
github.com/fenom-template/fenom/blob/10c8109bb545afc6ab599aee273e6978f2789ae6/docs/ru/mods/date_format.md — не работает модификатор даты, как в примере. То есть формат меняет без проблем, но если я попытаюсь вывести в таком виде "{$ts|date_format:"-1 day"}"
то выведет "-1 day"
то выведет "-1 day"
в таком виде "{$ts|date_format:"-1 day"}"А зачем кавычки вокруг фигурных скобок?
Кавычки судя по всему нужны все-таки, только тогда уж одинарные в таком виде "{$ts|date_format:'-1 day'}"
та кавычки здесь не при чем, я в комменте выделил для наглядности. Суть в другом
{$ts|date_format:"%Y/%m/%d %H:%M:%s"} — работает
{$ts|date_format:"-1 day"} — не работает
{$ts|date_format:"%Y/%m/%d %H:%M:%s"} — работает
{$ts|date_format:"-1 day"} — не работает
Кавычки при чем. Мы же все-таки на форуме программистов, и каждый символ имеет значение.
ОК, если у вас там нет ковычек, тогда уже вопрос к самому феному.
ОК, если у вас там нет ковычек, тогда уже вопрос к самому феному.
Согласен
В документации, видимо, ошибка. В коде не совсем так.
Попробуйте
Попробуйте
{var $ts = date('Y-m-d H:i:s')." -1 day"}
{$ts|date:"%Y/%m/%d %H:%M:%s"}
Не парсится, в феноме конкатенация через тильду идёт ~. Однако при правильной записи выдаёт текущую дату. Чтобы модификатор прямо к строке добавлять, нужно чтобы дата в опрделенном формате была, не помню в каком точно.
Вобщем так работает
{set $date = strtotime('+10 days')}
{$date|date_format:'%d %b %Y'}
Вобщем так работает
{set $date = strtotime('+10 days')}
{$date|date_format:'%d %b %Y'}
Вот пару моментов, может пригодится кому-то
1) date() в феноме модификатор и первый аргумент тут дата или timestamp, а второй — формат
2) При вызове модификатора date_format, %s (в нижнем регистре) возвращает timestamp. Нужно юзать %S
Варианты записи:
1) date() в феноме модификатор и первый аргумент тут дата или timestamp, а второй — формат
2) При вызове модификатора date_format, %s (в нижнем регистре) возвращает timestamp. Нужно юзать %S
Варианты записи:
{set $time = time()}
{set $date = date($time,'Y-m-d H:i:s') ~~ '+10 days'}
//Или
{set $date = $time|date_format:'%Y/%m/%d %H:%M:%S' ~~ '+10 days'}
{$date|date_format:'%Y/%m/%d %H:%M:%S'}
Кстати, конкатенацию делать необязательно. Попробуйте так:
{var $date = date('Y-m-d H:i:s -1 \d\a\y')}
{$date|date:"%Y/%m/%d %H:%M:%s"}
Ах, да, это же не PHP… У меня вот так заработало:
{var $date = date(time(), 'Y-m-d H:i:s -1 \d\a\y')}
{$date|date:"Y/m/d h:m:s"}
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.