Это не бага, все логично. Просто MODX отрабатывает окончательно весь код документа (вместе с кодом шаблона) уже на уровне modResponse::outputContent(). Немного модифицируем код:
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} иначе как в начале кода. А тут он де факто получается внутри.
Не, если в конфигах включается, то ОК. Я просто пропустил.
И вот такой вопрос: Есть два чанка fenom1 и fenom2. В документе пишу [[$fenom]] и ок, на странице все выводится. Но если я в чанке fenom1 пишу {extends 'fenom2'}, то он расширяет второй чанк, но на странице выводится только содержимое чанков (ничего более от шаблона). Можно как-то расширять другие чанки или что я не так делаю? Шаблоны корректно расширяются.
Спасибо! ОК, уже легче дышется :)
Если вдруг кто тоже не сразу нашел: joxi.ru/82QV3dNu1DovgA
Это для безопасности — вдруг на сайте есть контент-менеджер, который может править чанки.
Ну, как я и сказал, есть как минимум {$_modx->cacheManager->modx}, хотя и можно это тоже перекрыть. А второе: админка в MODX — это уже зона риска огромная, так что нефиг туда вообще никого лишнего пускать :)
modx.pro/comments/ — вот, например, 783 страницы по 25 результатов на каждую.
Это совершенно не связано с затронутой проблемой — генерацией кеша контекста. Подробно про все это читайте здесь, если интересно.
Вся проблема в том, что при сбросе кеша MODX будет пытаться собрать карту ресурсов из всех заявленных 150к+ документов. Во-первых, 783*25 — это совсем не 150к. Во-вторых, MODX не пытается все эти комментарии набить в кеш контекста. Так что вопрос не столько в конечной выборке, сколько в работе самого MODX-а. И с написания той статьи мало что поменялось. И по прежнему в таких случаях приходится использовать cacheOptimizer.
Так или иначе, я вынесу это на суд общественности, где каждый сможет высказаться. Но у меня довольно большой богах кейсов как и в каких случаях использовать шаблонизатор, так что посмотрим, сможет ли феном удовлетворить мои потребности :)
Честно сказать, чтобы подробней ответить на этот вопрос, мне надо установить феном и погонять его как следует, чтобы получилась какая-то сравнительная таблица функциональности. У меня все-таки идеология чуть шире, хоть и запутанней. К примеру, я не знаю как у Василия обстоят дела со скинами сайтов (Василий, сорри за в третьем лице), а так же что там на счет одновременного подключения нескольких дирректорий шаблонов. Плюс к этому, у меня все-таки обычные MODX-шаблоны заменены на php-шаблоны. Это опять-таки для производительности (хотя последние изменения в системе кеширония MODX-а могут свести эту разницу на нет, опять-таки тестировать надо). Но в целом, выполнение в Смарти парсинг его синтаксиса в чанках так же возможен, тем не менее мы почти полностью отошли от чанков и особо эту функциональность не используем.
Тем не менее, если говорить о необходимости переписывать все при обновлении уже работающих проектов — в Смарти так же нет необходимости переписывать все. Оставляете все как было, только самые слабые места переписываете на новый лад и все. Я так совсем недавно очередной проект переписывал. Там конечно во многом низкая скорость была из-за неправильной расстановки некешируемых сниппетов, но и в целом проблемы были все по той же причине — слишком много вызовов сниппетов и чанков. Как много? Смотри лог.
Нее, думаю дальше простого интереса к Твиг у них не пойдет. Может и выкатят какой-то модуль (хотя вряд ли, Andrew Smith давно уже с ним экспериментировал, но судя по всему это затухло), но в ядро это вряд ли запилят.
Вообще, когда я увидел ту заметку еще в 13-ом году, я Райну писал, мол «посмотри, довольно интересная штука и очень компактная, то есть давайте в MODX как-то это оформите». У него интерес был, но реализации так и не увидел свет. Я же на Смарти с 11-го года еще сижу, и не увидев сильной разницы не стал менять шило на мыло.
Ясно. Спасибо за ответ.
Со своей стороны добавлю, что спрашивал только потому что сам феномом не пользовался еще. При этом не вижу в нем какой-то сильной разницы и даже синтаксис сильно схож, потому и поинтересовался, что может вы в силу большего опыта с феномом увидели что-то, чего я не вижу.
Вот здесь автор фенома тесты проводит со смарти и твигом habrahabr.ru/post/169525/
Но это он писал еще в 13-ом году. С тех пор картина могла поменяться (и да, нужны тесты), но судя по тестам, смарти не сильно уступал в производительности феному, если не считать холодный запуск, на котором феном явно лучше себя показывает.
Можно поинтересоваться, что именно не понравилось в Смарти? Я не буду отстаивать Смарти, мне просто интересно что там может не понравиться по сравнению с феномом. Если брать за пример приведенный здесь код, то он же будет на Смарти ровно такой же, за исключением необходимости указывать var перед переменными, и вместо $_modx будет писаться привычный $modx.
Обновляем страницу и получаем такой результат: joxi.ru/VrwoaO9IKVPyXr
То есть это весь код шаблона и страницы, и в нем код чанка fenom1 как есть, вместе с расширением {extended}. То есть расширение уже становится не чанка, а по сути шаблона. В общем, контекст не тот уже.
Здесь надо мыслить как с этим поступить. Самое правильное, как мне кажется — это даже в рамках шаблона отрабатывать чанки сразу. Или договориться о том, что нельзя использовать кешируемые чанки с расширением других чанков.
К слову, Смарти не позволяет декларирование {extends} иначе как в начале кода. А тут он де факто получается внутри.
joxi.ru/a2XVypGuy0Bzjr
joxi.ru/ZrJVWD0u13PO4r
По всякому игрался, результат один и тот же.
И вот такой вопрос: Есть два чанка fenom1 и fenom2. В документе пишу [[$fenom]] и ок, на странице все выводится. Но если я в чанке fenom1 пишу {extends 'fenom2'}, то он расширяет второй чанк, но на странице выводится только содержимое чанков (ничего более от шаблона). Можно как-то расширять другие чанки или что я не так делаю? Шаблоны корректно расширяются.
Если вдруг кто тоже не сразу нашел: joxi.ru/82QV3dNu1DovgA
Ну, как я и сказал, есть как минимум {$_modx->cacheManager->modx}, хотя и можно это тоже перекрыть. А второе: админка в MODX — это уже зона риска огромная, так что нефиг туда вообще никого лишнего пускать :)
Это совершенно не связано с затронутой проблемой — генерацией кеша контекста. Подробно про все это читайте здесь, если интересно.
Вся проблема в том, что при сбросе кеша MODX будет пытаться собрать карту ресурсов из всех заявленных 150к+ документов. Во-первых, 783*25 — это совсем не 150к. Во-вторых, MODX не пытается все эти комментарии набить в кеш контекста. Так что вопрос не столько в конечной выборке, сколько в работе самого MODX-а. И с написания той статьи мало что поменялось. И по прежнему в таких случаях приходится использовать cacheOptimizer.
Тем не менее, если говорить о необходимости переписывать все при обновлении уже работающих проектов — в Смарти так же нет необходимости переписывать все. Оставляете все как было, только самые слабые места переписываете на новый лад и все. Я так совсем недавно очередной проект переписывал. Там конечно во многом низкая скорость была из-за неправильной расстановки некешируемых сниппетов, но и в целом проблемы были все по той же причине — слишком много вызовов сниппетов и чанков. Как много? Смотри лог.
Со своей стороны добавлю, что спрашивал только потому что сам феномом не пользовался еще. При этом не вижу в нем какой-то сильной разницы и даже синтаксис сильно схож, потому и поинтересовался, что может вы в силу большего опыта с феномом увидели что-то, чего я не вижу.
Но это он писал еще в 13-ом году. С тех пор картина могла поменяться (и да, нужны тесты), но судя по тестам, смарти не сильно уступал в производительности феному, если не считать холодный запуск, на котором феном явно лучше себя показывает.