Всё зависит от задачи. Подключить на один сайт или сделать пакет? Оставить принцип парсера MODX (как в случае с Fenom) или сделать ближе к фреймворкам?
— cssToHead — регистрация CSS кода в шапке страницы
— htmlToHead — регистрация произвольного HTML в шапке страницы
— htmlToBottom — регистрация произвольного HTML в подвале страницы
— jsToHead — регистрация javascript файла в шапке страницы. Если передать параметром true, то можно регистрировать сразу код.
— jsToBottom — регистрация javascript в подвале страницы. Если передать параметром true, то можно регистрировать сразу код.
{'<script>alert();</script>' | jsToBottom: true} // При загрузке страницы будет javascript alert
А разве хуки не стандартное средство?
Кроме того, какая-то странная задача — динамически менять имя отправителя?
05 апреля 2020, 18:44
0
Разве можно в параметры сниппета подставлять данные из формы? Они обрабатываются при просмотре страницы и сохраняются то ли в кэше, то ли в сессии. Т.е. повлиять на них уже нельзя. Наверно, только свой хук писать.
05 апреля 2020, 15:25
+1
Может здесь собака порылась?
Конечно здесь. Память уже подводить стала :(
Метод modX::getChunk() работает только с кэшированными плейсхолдерами. Оно и понятно. Ибо смысла делить их на кэшированные и некэшированные нет в отличие от ресурса или шаблона.
Читатели моего блога знают, что в случае обработки кэшированных плейсхолдеров Fenom не запускается. (Так как я давно уже MODX активно не занимаюсь, начал подзабывать такие тонкости.) Как я уже не однократно говорил, в MODX ни один шаблонизатор не будет работать нормально, так как отличаются концепции парсинга.
05 апреля 2020, 15:14
0
Учим матчасть. Самый простой способ — изучать код. Для начала смотрим Chunk::process().
05 апреля 2020, 11:27
+1
Ты, наверно, путаешь с инлайн чанками.
pdoTools подключает свой парсер, который легко справляется с феномом в чанках любых сниппетов. По крайней мере, должен с стандартных ситуациях.
Да забудь ты уже про это. Во-первых, не надо лазить в ядро. Во-вторых, этот же результат можно получить отключив опцию cfgSetAutoBrMode в наборе параметров Ticket.
Можно было бы использовать второй вариант, а в нужных шаблонах выводить контент через Jevix с включенной опцией. Но тут возможны проблемы типа предпросмотра тикета. Ибо нет возможности повлиять на вывод.
01 апреля 2020, 07:57
0
Сорри, пропустил твой коммент. Самый простой вариант
// Событие OnWebPagePrerender
$templates = [1,2,3]; // id шаблонов, у которых нужно удалять br.
if (in_array($modx->resource->template, $templates)) {
$modx->resource->_output = str_replace('<br>', '' , $modx->resource->_output);
}
31 марта 2020, 14:30
0
Создал набор параметров Site. Связал его со сниппетом Jevix. Понимаю, что это криво, но другого выхода пока что не вижу.
Вполне себе годное решение, но от двойной обработки контента Jevix'ом не спасает. МОжет проще в плагине при загрузке документа вырезать теги br?
Тикеты сейчас поддерживает не Василий, а чел из этого сообщества. Попробуй обратиться к нему. У меня с ним контакта не получилось.
Кроме того, какая-то странная задача — динамически менять имя отправителя?
Метод modX::getChunk() работает только с кэшированными плейсхолдерами. Оно и понятно. Ибо смысла делить их на кэшированные и некэшированные нет в отличие от ресурса или шаблона.
Читатели моего блога знают, что в случае обработки кэшированных плейсхолдеров Fenom не запускается. (Так как я давно уже MODX активно не занимаюсь, начал подзабывать такие тонкости.) Как я уже не однократно говорил, в MODX ни один шаблонизатор не будет работать нормально, так как отличаются концепции парсинга.
pdoTools подключает свой парсер, который легко справляется с феномом в чанках любых сниппетов. По крайней мере, должен с стандартных ситуациях.
Можно было бы использовать второй вариант, а в нужных шаблонах выводить контент через Jevix с включенной опцией. Но тут возможны проблемы типа предпросмотра тикета. Ибо нет возможности повлиять на вывод.