[pdoTools] 2.0.0-beta c шаблонизатором Fenom
Представляю вам новую версию pdoTools со встроенным шаблонизатором Fenom.
Это очередная попытка решить вопрос с очень бедным MODX шаблонизатором, который умеет очень мало. Первая «велосипедная» попытка была представлена здесь, а сейчас всё гораздо серьёзнее.
Если вы не знакомы с Fenom, то советую прочитать вот эту заметку на Хабре, а потом пробежаться по документации на GitHub.
Для включения шаблонизатора в вызове любого сниппета pdoTools нужно указать
Все ошибки компиляции пишутся в системный журнал. Если видите сырые теги — смотрите там, в чем беда.
У вас есть доступ к объектам $modx и $pdoTools, а также всем их свойствам и методам. Теперь вы можете делать разные проверки переменных и оформлять вывод как вам захочется без фильтров вывода и прочих сложных конструкций.
Шаблоны компилируюся и сохраняются в директорию /cache/fenom/. При очистке кэша сайта они удаляются.
Строковые плейсхолдеры [[+section.pagetitle]] превращаются в {$section_pagetitle}, так как Fenom ожидает через точку ключ массива. То есть {$section.pagetitle} — это для него $section['pagetitle'].
Лично я уже переписал основные чанки modx.pro на синтаксис Fenom — багов пока не замечено. Даже на моих старых полностью оптимизированных чанках, максимально разогнанных в pdoTools, я заметил прирост от 20% до 50% при более удобном синтаксисе.
Например, наша самая большая тема с 437 комментариями раньше открывалась за 1.3-1.5 сек, теперь за 0.7-0.9 сек.
Синтетический тест из этой темы показывает небольшой перевес чистого pdoTools над Fenom, если в чанке нет ни одного фильтра вывода (то есть, работает только str_replace(), без парсера MODX).
pdoTools
А вот если добавить всего один плейсхолдер, который должен быть разобран парсером MODX
То результат будет совсем иной:
pdoTools
Fenom может работать с объектом MODX напрямую, и ему не нужно парсить его плейсхолдеры — отсюда практически полное отсутствие тормозов при проверках переменных и вызове системных методов.
Скомпилированный шаблон выглядит вот так:
Замена плейсхолдеров:
Вот какой был старый чанк tpl.Tickets.comment.wrapper блока комментариев.
А вот как я переписал его на Fenom:
Еще пример старого чанка tpl.Tickets.comment.list.row.
И новая Fenom-версия:
А вот вообще отмороженный пример:

pdoResources тут нужен только для запуска шаблона с Fenom.
Вот так легко и просто у нас появился настоящий шаблонизатор в pdoTools, который вы можете включить по желанию, а можете и не включать — дело ваше.
Технически в pdoTools изменений немного, но по факту — это огромный тектонический сдвиг в разработке сайтов с использованием библиотеки. Поэтому версия теперь 2.0.0-beta.
Наверное, будут вопросы, а почему именно Fenom, а не Twig, Smarty или кто-то еще? Вот мой список причин:
Выложил в репозиторий версию 2.0.0-rc, в которой pdoParser уже использует Fenom. Теперь новый синтакис можно использовать прямо в контенте документов и шаблонах.
В отличии от MODX, этот парсер не рекурсивный, а компилирующий. Разбирать вложенные теги ему не нужно (они разбираются при компиляции, один раз) — так что разница в скорости должна быть приличной, особенно там, где много фильтров вывода и сложных шаблонов.
Итак, после долгих размышлений и тестов я переписал работу с Fenom так, чтобы скомпилированные шаблоны кэшировались только в ОЗУ.
Выходит, что в случае MODX, где данных хранятся в сравнительно небольших чанках, время на компиляцию шаблонов нивелируется постоянными обращениями к жесткому диску. В тестовых условиях отказ от кэширования файлов на HDD только увеличил скорость.
Чанки MODX не пишутся на диск, а Fenom не кэширует компилированные шаблоны рядом. Никакого мусора, всё быстро и красиво. Теперь Fenom показывает небольшой отрыв даже на простейших чанках без фильтров.
Ошибки компиляции, как и прежде, пишутся в журнал MODX. Так как исходники вам теперь посмотреть негде, на уровне INFO в лог отправляется и сам шаблон. Просто переключите системную настройку MODX log_level, чтобы это увидеть.
Так как Fenom предъявляет требования к именам переменных такие же, как и PHP, наши привычные плейхолдеры просто ломают компиляцию. Поэтому в новой версии все переданные плейсхолдеры можно найти в {$_pls}.
Например, плейсхолдеры превьюшек галереи получаем вот так:
Свежепоявившийся плагин pdoTools можно удалить. Он был нужен исключительно для очистки директории с кэшем, которой теперь нет.
Новая версия pdoTools 2.0.0-rc2 уже доступна в репозитории, обновляйтесь!
Анонс стабильной версии с множеством дополнительных настроек.
Это очередная попытка решить вопрос с очень бедным MODX шаблонизатором, который умеет очень мало. Первая «велосипедная» попытка была представлена здесь, а сейчас всё гораздо серьёзнее.
Если вы не знакомы с Fenom, то советую прочитать вот эту заметку на Хабре, а потом пробежаться по документации на GitHub.
Возможности
- Включение поддержки Fenom раздельно для каждого сниппета pdoTools.
- Можно использовать плейсхолдеры MODX и теги Fenom одновременно. Но быстрее будет использовать что-то одно.
- Если в чанке нет плейсхолдеров MODX, то парсер MODX не запускается
- Если в чанке нет тегов Fenom, то он тоже не запускается.
- @INLINE чанки работают
Особенности
Для включения шаблонизатора в вызове любого сниппета pdoTools нужно указать
&useFenom=`1`Все ошибки компиляции пишутся в системный журнал. Если видите сырые теги — смотрите там, в чем беда.
У вас есть доступ к объектам $modx и $pdoTools, а также всем их свойствам и методам. Теперь вы можете делать разные проверки переменных и оформлять вывод как вам захочется без фильтров вывода и прочих сложных конструкций.
Адрес сайта: {$modx->config.site_url}
{if $modx->user->isAuthenticated($modx->context->key)}
Юзер авторизован в контексте
{else}
Это гость
{/if}Шаблоны компилируюся и сохраняются в директорию /cache/fenom/. При очистке кэша сайта они удаляются.
Строковые плейсхолдеры [[+section.pagetitle]] превращаются в {$section_pagetitle}, так как Fenom ожидает через точку ключ массива. То есть {$section.pagetitle} — это для него $section['pagetitle'].
Тестирование
Лично я уже переписал основные чанки modx.pro на синтаксис Fenom — багов пока не замечено. Даже на моих старых полностью оптимизированных чанках, максимально разогнанных в pdoTools, я заметил прирост от 20% до 50% при более удобном синтаксисе.
Например, наша самая большая тема с 437 комментариями раньше открывалась за 1.3-1.5 сек, теперь за 0.7-0.9 сек.
Синтетический тест из этой темы показывает небольшой перевес чистого pdoTools над Fenom, если в чанке нет ни одного фильтра вывода (то есть, работает только str_replace(), без парсера MODX).
pdoTools
0.0005119: Created inline chunk 0.1967380: Total time 3 670 016: Memory usageFenom
0.0004470: Created inline chunk 0.2136431: Total time 3 407 872: Memory usage
А вот если добавить всего один плейсхолдер, который должен быть разобран парсером MODX
// pdoTools
$tpl1 = '@INLINE <p>[[++site_name]] [[+val1]] - [[+val2]] - [[+val3]]</p>';
// Fenom
$tpl2 = '@INLINE <p>{$modx->config.site_name} {$val1} - {$val2} - {$val3}</p>';То результат будет совсем иной:
pdoTools
0.0003500: Created inline chunk 1.8580759: Total time 3 670 016: Memory usageFenom
0.0004060: Created inline chunk 0.2227199: Total time 3 932 160: Memory usageДа-да, это не ошибка!
Fenom может работать с объектом MODX напрямую, и ему не нужно парсить его плейсхолдеры — отсюда практически полное отсутствие тормозов при проверках переменных и вызове системных методов.
Скомпилированный шаблон выглядит вот так:
<?php
/** Fenom template 'cd20f5e1f2f6add74ba06c086f8b8242.fenom.tpl' compiled at 2015-05-18 21:44:23 */
return new Fenom\Render($fenom, function ($var, $tpl) {
?><p><?php
/* cd20f5e1f2f6add74ba06c086f8b8242.fenom.tpl:1: {$modx->config.site_name} */
echo $var["modx"]->config["site_name"]; ?> <?php
/* cd20f5e1f2f6add74ba06c086f8b8242.fenom.tpl:1: {$val1} */
echo $var["val1"]; ?> - <?php
/* cd20f5e1f2f6add74ba06c086f8b8242.fenom.tpl:1: {$val2} */
echo $var["val2"]; ?> - <?php
/* cd20f5e1f2f6add74ba06c086f8b8242.fenom.tpl:1: {$val3} */
echo $var["val3"]; ?></p><?php
}, array(
'options' => 0,
'provider' => false,
'name' => 'cd20f5e1f2f6add74ba06c086f8b8242.fenom.tpl',
'base_name' => 'cd20f5e1f2f6add74ba06c086f8b8242.fenom.tpl',
'time' => 1431974663,
'depends' => array (
0 =>
array (
'cd20f5e1f2f6add74ba06c086f8b8242.fenom.tpl' => 1431974663,
),
),
'macros' => array(),
));Ну и напоследок несколько примеров для гладкого переезда.Примеры
Замена плейсхолдеров:
[[+pagetitle]] - {$pagetitle}
[[*pagetitle]] - {$modx->resource->pagetitle}
[[%lexicon]] - {$modx->lexicon('lexicon')}
[[~[[+id]]]] - {$modx->makeUrl($id)}Вот какой был старый чанк tpl.Tickets.comment.wrapper блока комментариев.
А вот как я переписал его на Fenom:
<div class="comments">
{if $modx->user->isAuthenticated($modx->context->key)}
<span class="comments-subscribe pull-right">
<label for="comments-subscribe" class="checkbox">
<input type="checkbox" name="" id="comments-subscribe" value="1" {$subscribed != '' ? 'checked' : ''} /> {$modx->lexicon('ticket_comment_notify')}
</label>
</span>
{/if}
<h4 class="title">{$modx->lexicon('comments')} (<span id="comment-total">{$total}</span>)</h4>
<div id="comments-wrapper">
<ol class="comment-list" id="comments">{$comments}</ol>
</div>
<div id="comments-tpanel">
<div id="tpanel-refresh"></div>
<div id="tpanel-new"></div>
</div>
</div>Еще пример старого чанка tpl.Tickets.comment.list.row.
И новая Fenom-версия:
<div class="ticket-comment-row ticket-comment" id="comment-{$id}" data-id="{$id}">
<div class="ticket-comment-body {$guest ? 'ticket-comment-guest' : ''}">
<div class="ticket-comment-header">
<div class="user-avatar-wrapper">
<img src="{$avatar}" class="ticket-avatar" alt="" />
</div>
<span class="ticket-comment-author">{$fullname}</span>
<span class="ticket-comment-createdon">{$date_ago}</span>
<span class="ticket-comment-link"><a href="{$url}#comment-{$id}">#</a></span>
<span class="ticket-comment-star {$can_star ? 'active' : ''}">
<i class="glyphicon glyphicon-star {$stared ? 'stared' : 'unstared'} star"></i>
</span>
<span class="ticket-comment-rating {$can_vote ? 'active' : 'inactive'}">
<span class="rating {$rating_positive ? 'positive' : ''}{$rating_negative ? 'negative' : ''}" title="Всего: {$rating_total}: ↑{$rating_plus} и ↓{$rating_minus}">{$rating}</span>
<span class="vote plus {$voted_plus ? 'voted' : ''}" title="Нравится"><i class="glyphicon glyphicon-arrow-up"></i></span>
<span class="vote minus {$voted_minus ? 'voted' : ''}" title="Не нравится"><i class="glyphicon glyphicon-arrow-down"></i></span>
</span>
</div>
<div class="ticket-comment-text">
{$text}
</div>
</div>
<div class="ticket-comment-meta">
<a href="{$modx->makeUrl($section_id)}" class="ticket-comment-section"><i class="glyphicon glyphicon-folder-open"></i> {$section_pagetitle}</a> →
<a href="{$modx->makeUrl($ticket_id)}" class="ticket-comment-ticket">{$ticket_pagetitle}</a>
<span class="ticket-comment-comments">
<small><i class="glyphicon glyphicon-comment"></i> {$comments}</small>
</span>
</div>
</div>Обратите внимание на свободный вызов {$modx->makeUrl()} и другие интересные конструкции.А вот вообще отмороженный пример:
[[!pdoResources?
&useFenom=`1`
&parents=`999999`
&wrapIfEmpty=`1`
&tplWrapper=`@INLINE
{set $collection = $pdoTools->getCollection('modResource', null, ['parents' => 0, 'limit' => 10])}
{foreach $collection as $idx => $res}
<p>{$res.id} - {$res.pagetitle}</p>
{$pdoTools->addTime('Строка ' ~ $idx)}
{/foreach}
<pre>{$pdoTools->getTime()}</pre>
`
]]Вызов метода pdoTools с присвоением его результата переменной и разбор её в цикле. 
pdoResources тут нужен только для запуска шаблона с Fenom.
Заключение
Вот так легко и просто у нас появился настоящий шаблонизатор в pdoTools, который вы можете включить по желанию, а можете и не включать — дело ваше.
Технически в pdoTools изменений немного, но по факту — это огромный тектонический сдвиг в разработке сайтов с использованием библиотеки. Поэтому версия теперь 2.0.0-beta.
Наверное, будут вопросы, а почему именно Fenom, а не Twig, Smarty или кто-то еще? Вот мой список причин:
- Использование токенайзера вместо регулярок — выше скорость и ниже расход ОЗУ
- Автор — русскоговорящий и пишет документацию на родном языке
- Приятный php-подобный синтаксис, особенно что касается работы с массивами и объектами.
- Приятный исходный код.
- Судя по активности на GitHub, впереди у проекта светлое будущее
- Ну и наконец, я уже использовал его для работы на одном крупном кинопортале и остался доволен.
Обновлено 20.05.2015
Выложил в репозиторий версию 2.0.0-rc, в которой pdoParser уже использует Fenom. Теперь новый синтакис можно использовать прямо в контенте документов и шаблонах.
В отличии от MODX, этот парсер не рекурсивный, а компилирующий. Разбирать вложенные теги ему не нужно (они разбираются при компиляции, один раз) — так что разница в скорости должна быть приличной, особенно там, где много фильтров вывода и сложных шаблонов.
Обновлено 21.05.2015
Итак, после долгих размышлений и тестов я переписал работу с Fenom так, чтобы скомпилированные шаблоны кэшировались только в ОЗУ.
Выходит, что в случае MODX, где данных хранятся в сравнительно небольших чанках, время на компиляцию шаблонов нивелируется постоянными обращениями к жесткому диску. В тестовых условиях отказ от кэширования файлов на HDD только увеличил скорость.
Чанки MODX не пишутся на диск, а Fenom не кэширует компилированные шаблоны рядом. Никакого мусора, всё быстро и красиво. Теперь Fenom показывает небольшой отрыв даже на простейших чанках без фильтров.
Ошибки компиляции, как и прежде, пишутся в журнал MODX. Так как исходники вам теперь посмотреть негде, на уровне INFO в лог отправляется и сам шаблон. Просто переключите системную настройку MODX log_level, чтобы это увидеть.
Так как Fenom предъявляет требования к именам переменных такие же, как и PHP, наши привычные плейхолдеры просто ломают компиляцию. Поэтому в новой версии все переданные плейсхолдеры можно найти в {$_pls}.
Например, плейсхолдеры превьюшек галереи получаем вот так:
[[!ms2GalleryResources?
&typeOfJoin=`inner`
&parents=`0`
&tpl=`@INLINE
<p><a href="{$uri}"><img src="{$_pls['120x90']}" /></a> {$rank}</p>
`
]]Точно так же получаем и плейсхолдеры с точкой:{$_pls['section.uri']}Больше никакой замены точек на подчеркивание в именах переменных — всё ради повышенной скорости работы.Свежепоявившийся плагин pdoTools можно удалить. Он был нужен исключительно для очистки директории с кэшем, которой теперь нет.
Новая версия pdoTools 2.0.0-rc2 уже доступна в репозитории, обновляйтесь!
Анонс стабильной версии с множеством дополнительных настроек.
Комментарии: 175
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Консоль запущена…
PHP warning: Invalid argument supplied for foreach()
Очистка основного кэша: pdoTools
Этого предупреждения на прошлой версии pdoTools пару минут назад не было.
Это как-то связано с этим обновлением похоже. В логах ошибок сайта пусто.
При очистке кэша происходит удаление скомпилированных шаблонов, а у тебя еще нет этой директории. Просто игнорируй, больше не должно появляться.
Конечно я это поправлю, но потом.
Правда, если ты не планируешь пробовать Fenom, то обновляться вовсе не нужно — там больше нет никаких изменений.
Плюс посмотри в заметке примеры, а дальше читать уже в документации Fenom.
Ах… Оочень замечательно! Нет слов…Очень порадовало, что в @INLINE чанках нормально отрабатывают сложные логические конструкции.
Спасибо!
К примеру:
Думаю актуално не только для меня.Спасибо!!!
А все вижу пример ))
Удачи с парсером, мы все с замиранием сердца наблюдаем за этим ;)
АндрейИ осталась ли возможность использовать специальные плейсхолдеры типа [[#12.pagetitle]]?
P.S. блин, только все чанки в ИМ на 50к товаров переписал на «быстрые плейсхолдеры». Прошла неделя — бам, новый pdoTools)))
pdoParser пробует их выполнить без объектов, а если не может — отдаёт в парсер MODX.
Ну а Fenom просто и без затей компилирует шаблон в исполняемый PHP код, который полюбому будет быстрее.
Конечно. Теперь можно даже так:
Андрейто это будет дольше из-за выше приведенных причин парсера MODX, правильно понимаю?
Василий, ещё такой вопрос. Что будет быстрее работать, если вызвать в коде ресурса с id 10?
Просто каша в голове от нового синтаксиса шаблонизатора. Надо поспать, чтобы уложилось))
АндрейПри переустановке опции тоже не выбрать. Приходится или сносить и заново ставить пакет или искать и вбивать значения настроек parser_class и parser_class_path.
По умолчанию парсер я не буду включать по многим причинам.
АндрейТогда этот коммент останется для потомков, чтобы знали, что pdoParser на тестовых сайтах при автоустановке по умолчанию выключен.
Значение настроек:
ругается на
А что с кешированием? Получается вложенные будут выполняться каждый раз?
Fenom требует PHP 5.3.
А кэшированием тебе придётся озаботиться самостоятельно.
1. Для долговремнного хранения есть {$modx->cacheManager->get()} и {$modx->cacheManager->set()}
4. Для кэширования во время выполнения {$pdoTools->getStore()} и {$pdoTools->setStore()}.
3. Можно даже сохранять в произвольные файлы через {$.php.file_put_contents()}.
github.com/fenom-template/fenom/blob/master/docs/ru/syntax.md
А пока можно делать вот так:
Бери плейсхолдер [^t^], делай разные запросы и замеряй производительность.
Давай дальше сам.
Но попробовать можно, почему бы и нет? Напиши о результатах, если будешь делать.
А вот если ты захочешь понапихать в чанки разных проверок — то Fenom будет гораздо быстрее.
&cache=`1`
&cacheTime=`0`
&cache_key=`bestMenu`
чтобы менюшка сейвило под 1 ключом для всех страниц, если конечно от этого ничего не поломается
Я написал свой сниппет для генерации меню и теперь меня все устраивает, просто вопрос был именно в том чтобы ускорить pdoMenu, и не писать свои обработчики
modx/core/cache/ВАША_ПАПКА_КЭША
Так что попробуй, может сработать.
В первом случае одна страница, а во втором несколько, вот в этом и разница.
1)сниппет с 1 sql запросом и рекурсивной генерацией меню, для большей быстроты генерации на лету вес можно еще хранить
2)js скрипт который пробегается по дереву и проставляет текущий пункт и родителей
Скорость генерации сократилась с 10s до 1s при первом вызове и потом до 0.05s при кешировании
ДА. ЭТО. ЖЕ. ПРОСТО. О.УЕННО!!!
Чанки в чанках, грёбанные строки в виде всяких там плейсхолдеров теперь идут НАХЕР!
Циклы! Наконец-то, мать их, циклы!!!
Условия! Наконец-то, мать их, человеческие условия!
Наконец-то есть работа с ДАННЫМИ, а не с какими-то грёбанными строками, которые после обработки всех вложенностей и 10й итерации парсера вылезают хрен пойми где и хрен пойми как, ломая напрочь всю разметку.
Циклы, omfg, да это же ЦИКЛЫ!!! Как мало для счастья надо xD xD
Сколько же я на себе волос повыдирал, когда бодался с этим долбанным парсером. Когда логика фронтенда становится чуть сложнее простого вывода данных, то всё — логика у парсера отключается и активируется режим «Угадай, что получится». Я даже хотел писать статью-ненависти-поток-сознания, в которой хотел по косточкам пройтись по косякам парсера. Теперь всё это идёт НАХЕР! xD
Теперь достаточно написать один простенький сниппет (чтобы не извращаться через tplWrapper pdoResource'а), который подключает pdoTools и с помощью него выводит чанк из параметров сниппета (а в чанке уже можно писать что угодно) и всё, мать его, ВСЁ! xD
p.s. Славься В! Славься В! Славься В!
Не спеши, скоро будет обновление с улучшенным pdoParser:
Но такая глобальная шаблонизация из коробки — это, конечно, будет просто сказка! Ждём-с :)
Обновляйся на 2.0.0-rc, включай pdoParser при установке, и можно использовать Fenom на страницах сайта и в шаблонах.
Вообще, короче, везде можно.
p.s. а в чём там велосипедность-то?) Небольшая функция, подключение pdoTools'а и вывод чанка, в который можно данные передать — куда ж проще-то?)
{$150x120} ломает парсер.
Может, как-то получится это экранировать, но я пока не придумал как именно.
Это верная конструкция или сначала будет распарсен чанк, а уже после Fenom решит показывать его или нет?
И про эту конструкцию такой же вопрос
Если на странице — то MODX, потому что чанк кэшированный.
Если чанк на странице некэшированный, то первым сработает Fenom.
Хотя судя по тому что нижние примеры не срабатывают (1-ый ломает парсер, второй ничего не выводит), оно работает внутрь.
Можно смело делать вот так:
И проверять страницу, передавая параметр ?test=1 или ?test=0
А пример у тебя неверный, не знаю, где ты такое вычитал.
Без всего:
Использовано памяти: 4.54 мб., MySQL: 0.0132 s, 88 request(s), PHP: 0.5319 s, total: 0.5451 s, from cache.
Использовано памяти: 5.69 мб., MySQL: 0.0195 s, 109 request(s), PHP: 0.7325 s, total: 0.7520 s, from cache.
Использовано памяти: 5.69 мб., MySQL: 0.0200 s, 109 request(s), PHP: 0.7373 s, total: 0.7573 s, from cache.
Использовано памяти: 5.69 мб., MySQL: 0.0220 s, 109 request(s), PHP: 0.7495 s, total: 0.7715 s, from cache.
Использовано памяти: 5.48 мб., MySQL: 0.0125 s, 92 request(s), PHP: 0.5108 s, total: 0.5233 s, from cache.
Использовано памяти: 4.54 мб., MySQL: 0.0121 s, 88 request(s), PHP: 0.5129 s, total: 0.5250 s, from cache.
Тут и во всех примерах выше гет запрос пустой.
А пока можно просто переписать на Fenom вот так:
Вот еще особенность, при попытке получить пустой чанк:
Пустой старт: 88 request(s)
88 request(s)
89 request(s)
90 request(s)
Но
88 request(s)
88 request(s)
89 request(s)
89 request(s)
И просто для вида:
88 request(s)
Чанк существует.
Попробую разобраться.
АндрейАндрейОн очищается при ПОЛНОЙ очистке системного, а при обычном сохранении ресурса с очисткой кэша он раздувается.
АндрейКаждый раз, как ты что-то меняешь — генерируется новый кэш. Как, по твоему, вообще должен работать шаблонизатор, без компиляции что ли?
АндрейПо-моему он должен работать с очисткой предыдущего кэша данной страницы, зачем плодить ненужный кэш?
Такое происходит только если вызывать новые теги прямо на страницах, а чанки кэшируются по хэшу своего содержимого.
То, что сейчас в кэше MODX точно так же хранится код каждой страницы никого, почему-то, не беспокоит.
АндрейО да, это просто гениальный ответ, именно такие я всегда жду от тебя. Только не забудь вспомнить, когда будешь переписывать механизм кэширования.
Высказывать своё удивительно важное мнение может каждый, даже ты. А вот сделать что-то всегда проблема.
Не жди ничего, поработай самостоятельно.
P.S.
Сейчас-то хоть дошло, почему я не включаю эксперементальный парсер по умолчанию?
АндрейА мне кажется совсем наоборот — ты считаешь своё мнение сверх важным всегда. До этого я высказал своё мнение по поводу rel=canonical — наткнулся на вилы с твоей стороны и предложение сделать самому. Хорошо, я сделал сам. Хотя насчёт rel=next и rel=prev ты кого-то послушал, и сделал.
Вот и теперь также.
P.S. но эти самые rel=next Яндексом даже не поддерживаются. А насчёт rel=canonical ты почему-то полез в документацию именно Яндекса, когда захотел мне возразить.
Если бы не понимал, ты бы сейчас давал свои советы кому-то другому.
Со временем, боль утихнет.
АндрейКаждый разбирается в своём предмете лучше. Если это твой компонент, то логично же, что именно тебе пишут о его недостатках. Пусть даже в чём-то эти недостатки мнимые. Если ты хорошо знаешь свой «предмет», то просто объясни людям, в чём их заблуждение. Не нужно тыкать пальцем и писать ёрнические фразы.
А если плохо объяснил — должен извиниться, и впредь вести себя вежливо и предупредительно.
Пользователь, понятное дело, ничего такого не должен. Это же автору нужно бегать за пользователем, а никак не наоборот.
АндрейТы же хочешь, чтобы твой компонент был лучше всех? Хочешь. Ты же хочешь, чтобы искали баги — хочешь? Так в чём проблема? В чье-то критике?
P.S.
А между тем выходит версия 2.0.0-rc2 Но ты же всегда прав…
P.S.S. в логе изменений ошибочка, кстати:
Просто я знаю, что хочу сделать и выкладываю промежуточные версии, чтобы можно было посмотреть как получается.
Или ты думаешь, что я весь день плевал в потолок и только после твоих невероятно ценных замечаний, за 5 часов всё переписал, протестировал и выложил?
Ты себе льстишь, серьёзно.
АндрейjaleУдачи тебе в поисках Правды на других ресурсах.
После чтения «критики», в данной ветке особенно, хочется тебя поблагодарить и поддержать.
К яростным мстителям я давно привык — не первый год рулю сообществом.
Подскажите, кто-нибудь как вывести TV'шку с помощью синтаксиса шаблонизатора ?)
А получить прямо из шаблона или чанка можно так
Если ресурса с id 15 нет, то будет ошибка. Поэтому, безопаснее вот так:
Как это сделать? Например, в pdoResources делаю и &includeTVs со списком tv и подготавливаю и обрабатываю их через &prepareTVs=`1` и &processTVs=`1` и все равно внутри чанка можно получить значение этих переменных только в виде:
а для этого надо включать pdotools_fenom_modx, что не очень хорошо для безопасности. Тот же самый вызов только с $_modx не работает. Из этого следует, что внутри чанков по сути получается использовать в формате {$name} только стандартные поля ресурсов, а для получения значений TV надо писать каждый раз огромный код, что конечно «убивает» все удобство написания кода. Так что же я делаю не так? Или просто я что-то не так понял, такой возможности нет и мне пора бы уже сделать себе хоткей в редакторе для TV? :)
Между {$modx} и {$_modx} есть очень серьёзная разница, и если ты пытаешься использовать вторую переменную как первую, то и будет fatal error.
При этом имя TV без тире, точек и т.д.
В чем именно тут ошибка использования? для $_modx нет getObject?
Может, прочитаешь уже документацию, а?
в чанках не выходит получить значение tv. Имена tv не имеют тире, точек, подчеркиваний, поэтому, как я понял, использовать $_pls (куда ведет ваша ссылка) не имеет смысла. Так есть ли возможность как-то по-другому получать значение tv в чанках? Я в документации такого не нашел…
Ну с последним вариантом я уже понял в чем дело…
Первый вариант как я и говорил он предназначен для вывода значения тв для текущего ресурса. ([[*tvName]] а нужен аналог [[+tvName]])
Ну а с $_pls просто ничего не выдается.
>>>Не додумывать, а просто попробовать.
Я обычно так и делаю, чтобы не быть голословным я сначала пробую, а потом пытаюсь додумать, что не так…
login: s3651
pass: 3kEaiHzCM9IY
надо при вызове сниппета, напр. pdoResource, использовать параметр
Ну хотя бы сейчас из этого сообщения люди смогут об этом узнать.
Можно и не делать пустой &tvPrefix, но тогда, не поверишь, нужно выводить ТВ вот так:
Про вывод через точку я тебе давал ссылку еще 2 часа назад.
А вообще, можно увидеть все плейсхолдеры, если просто не указывать чанк.
Допиши, что считаешь нужным, и пришли pull-request. Тогда эта информация добавится на сайте.
Все сетуют на плохую документацию, но никто, почему-то, не хочет её улучшать.
Через пространство имён создано новое имя sitetranslations, /core/components/sitetranslations/lexicon/ содержит два языка — русский и английский. Раньше выводил так:
Решил попробовать шаблонизатор, пробую варианты:
Выводит — lexicon_name. Но ежели в шаблоне оставить хоть один вывод MODX
То Fenome начинает работать и без указания пакета, выводится так:
Попробуй так:
И в документации про load() ничего не вижу. Да я понимаю, что надо загрузить лексикон, только не грузится он у меня без вмешательства MODX.
выводит «Почтовые уведомления». Без первой строчки выводит «area_tickets.mail».
Видимо, тебе тоже нужно указать раздел через двоеточие. По идее:
Кстати говоря, документацию лучше смотреть вот так.
зы. Отлично.
Но да, мне тоже очень нравится =)
Не работает именно [[~[[+id]]. Ссылка выходит такая Товар 1. Такая проблема появилась после обновления pdoTools Fenom. Если задать поместить [[+pagetitle]] в чанк то все работает.
И ошибка в отчете:
Трудно внимательно посмотреть на код и подумать, а вдруг там опечатка? Может, заместо $input_error нужно указать &input_error?
вызов чанка:
чанк:
Но это попахивает уже каким-то извращением, на мой взгляд.
Тут словил вот такую вещь. Сайт падает, когда пользователь не суперадмин. В логах сервера это:
т.е. на этой строке:
Версия pdoTools 2.0.3-pl, modx 2.3.4.
Всё, обновляйся.
?
Вызываем чанк:
А что дальше делать? Или как это работает?
И еще один вопрос. Каким образом можно заменить, например, такую конструкцию в рамках Fenom?
dвот так работает
а вот так уже нет
Скажем, вызываю на странице pdoResources, в котором есть параметр:
и парсер перестаёт работать… Что делать, кто знает? Можно ли как-нибудь экранировать скобки?
с примеру [[#GET.key3]]?
Хотел обернуть тернарным оператором !empty($.get.city)? «бла-бла»: «ой!» — и не вышло, облом.
А я б еще и такие вещи вотворил htmlspecialchars(strip_tags(stripslashes(trim($.get.city)))). А то я на смарти-шаблонизаторе часто вызывал процессоры прям на странице и почистить переменную перед вводом тут бы было очень кстати.
он просто их не видит…
подскажите, где в этих случаях искать ошибки?