Andrew

Uncaught SyntaxError: Unexpected identifier
at doDecode (ext-all.js:21)

У меня такой же глюк был при сохранении любого дочернего ресурса, в родителе которого в поле title присутствовал

& q u o t ;

Отключение плагинов, чистка папки кешей не помогала

Это по идее должно быть надо любому пользователю шаблонизатора феном на modx, ибо глюки не нужны никому, особенно которые на ровном месте занижают производительность. И это однозначно правильно отнести к глюкам а не просто «плохой оптимизации», потому что кеширование — это одно из основных достоинств modx…

Другой вопрос — кто в состоянии и знает как и где что править, автор расширения почему-то приходит на ум первым :)) Если нет времени это делать, покажи файлы, части кода где это можно исправить — и кто-то из комюнити исправит, у кого хватит скилов, дадут тебе обратно исправленный код и выложишь в репозитории. Поставь задачу сообществу — и наверняка кто-то из нас сделает. Нет проблем. Стороннему человеку (не автору кода) найти в чужом коде что-то — проблема куда большая чем для человека, который его писал и проектировал изначально. Поэтому без твоей поддержки тут будет сложновато :)

а разве когда стоит pdoTools и прописан как класс парсера, то при вызове [[snippet]] не тот же pdoTools::runSnippet() вызывается?

Да я не мучаюсь, интересно уже докопаться до истины, и мне то как раз нравится функционал фенома: и условия с циклами, и наследование шаблонов особенно, да и сам синтаксис php логичный вполне.
Вместо того, чтобы использовать снипет [[If]] с адским синтаксисом или писать новый снипет, пконечно удобней реализовать на феноме {If…

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

PS: Ну а с костылем-оберткой в кэшер — просто эксперимент был по предложенному коду… конечно такое оставлять в продакшине нельзя, да и уже заметил, что оно глючно работает с этой оберткой, элементы меню путает в pdoMenu, названия страниц в pdoCrumbs.

Не должен, а лезет в базу все равно, массив есть в кеше документа, снипеты кешируемые тоже в нем есть, то есть выходит, что снипеты в кеш сохраняются, а запросы в базу идут:

'elementCache' => 
  array (
    '[[initMS2Config]]' => '<script>miniShop2Config = { "cssUrl":"\\/assets\\/components\\/minishop2\\/css\\/web\\/","jsUrl":"\\/assets\\/components\\/minishop2\\/js\\/web\\/","actionUrl":"\\/assets\\/components\\/minishop2\\/action.php","ctx":"web","close_all_message":"","price_format":[2,"."," "],"price_format_no_zeros":true,"weight_format":[3,"."," "],"weight_format_no_zeros":true };</script>',
    '[[pdoMenu?showLog=``&fastMode=``&level=`2`&parents=``&displayStart=``&resources=``&templates=``&context=``&cache=``&cacheTime=`3600`&cacheAnonymous=``&plPrefix=`wf.`&showHidden=``&showUnpublished=``&showDeleted=``&previewUnpublished=``&hideSubMenus=``&useWeblinkUrl=`1`&sortdir=`ASC`&sortby=`menuindex`&limit=`0`&offset=`0`&rowIdPrefix=``&firstClass=`first`&lastClass=`last`&hereClass=`active`&parentClass=``&rowClass=``&outerClass=``&innerClass=``&levelClass=``&selfClass=``&webLinkClass=``&tplOuter=`@INLINE {$wrapper}`&tpl=`@INLINE
                    <li class="nav-item {$classnames}">
                        <a class="nav-link" href="{$link}" {$attributes}>{$menutitle}</a>
                    </li>`&tplParentRow=``&tplParentRowHere=``&tplHere=``&tplInner=``&tplInnerRow=``&tplInnerHere=``&tplParentRowActive=``&tplCategoryFolder=``&tplStart=`@INLINE <h2[[+classes]]>[[+menutitle]]</h2>[[+wrapper]]`&checkPermissions=``&hereId=``&where=``&select=``&scheme=``&toPlaceholder=``&countChildren=``&startId=`0`]]' => '<li class="nav-item first">
                        <a class="nav-link" href="/" >Главная</a>
                    </li><li class="nav-item ">
                        <a class="nav-link" href="glavnaya1" >Главная1</a>
                    </li><li class="nav-item ">
                        <a class="nav-link" href="test-modx" >Тест-модх</a>
                    </li><li class="nav-item last active">
                        <a class="nav-link" href="test-fenom" >Тест-Феном</a>
                    </li>',
    '[[pdoCrumbs?showLog=``&fastMode=``&from=`0`&to=``&customParents=``&limit=`10`&exclude=``&outputSeparator=`
`&toPlaceholder=``&includeTVs=``&prepareTVs=`1`&processTVs=``&tvPrefix=`tv.`&where=``&showUnpublished=``&showDeleted=``&showHidden=`1`&hideContainers=``&tpl=`@INLINE <li class="breadcrumb-item"><a href="[[+link]]">[[+menutitle]]</a></li>`&tplCurrent=`@INLINE <li class="breadcrumb-item active">[[+menutitle]]</li>`&tplMax=`@INLINE <li class="breadcrumb-item disabled"> ... </li>`&tplHome=``&tplWrapper=`@INLINE <ol class="breadcrumb">[[+output]]</ol>`&wrapIfEmpty=``&showCurrent=`1`&showHome=`1`&showAtHome=`0`&hideSingle=``&direction=`ltr`&scheme=``&useWeblinkUrl=`1`]]' => '<ol class="breadcrumb"><li class="breadcrumb-item"><a href="/">Главная</a></li>
<li class="breadcrumb-item active">Тест-Феном</li></ol>',
  ),

Верю :) Поэтому исходя от впечатления высокого качества Ваших продуктов и взялся попробовать сделать решение именно на феном, вот я и хочу тоже научиться писать с его применением так, чтобы все работало максимально быстрее… При этом я не переделываю существующий сайт под феном, а пытаюсь с нуля его сделать, сравнивая шаблоны на одном и другом синтаксисе.
А вот проблема с кэшированием все таки наблюдается. Обратите, пожалуйста, внимание на мои скрины с дебагом, как раз при появлении лишних запросов к бд снипетами, которые должны быть закэшированы, и проявляется существенное проседание скорости. Когда я эти снипеты прячу в обертку через getCache, запросы лишние уходят и при этом время отработки значительно сокращается. Но это ведь не выход. И конечно же главный параметр для сравнения — скорость, а количество запросов — это уже как следствие, чтобы разобраться где кроется проблема. Ну и исходя из результатов по скорости я все таки бы отнес данный эффект к проблемам, а не к особенностям работы системы. На самом то деле мне все равно запилить небольшой интернет-магазин на мод-икс синтаксисе или на феном, мне даже проще на моде, потому что я с ним ранее работал. Просто хотелось бы внести вклад в развитие Вашего продукта и донести информацию о том, что проблема все таки есть… Ну или если я делаю что-то не так, пожалуйста, помогите разобраться, думаю, что решение будет полезно многим

Так по факту получается, что феном при кешированном вызове сниппета не просто тэг парсит, а запрос в БД делает зачем-то, отсюда и основная потеря производительности

Эту опцию пробовал тоже — не влияет, как и писал автор. Кстати, вариант с обертками при разработке тоже опасен: изменения в коде обертки не обновляют этот кастомный кэш, и снипеты при этом начинают глючить, нужно всегда помнить чтобы чистить кэш руками после изменений.

Сайт небольшой — понятно, и если насильно закешировать оберткой снипеты, то производительность не сильно падает… Однако без оберток-костылей все кешируемые снипеты кушают плюс один запрос, это явно глюк, может автора попросить глянуть пофиксить ?)

то есть абсолютно любому снипету (не обязательно pdoTools-ному) можно передавать этот параметр и оно будет работать?

UPD: не, не помогает такой вариант:

{'pdoCrumbs' | snippet : [
	'showAtHome' => '0',
	'showHome' => '1',
	'cacheTime' => '0'
]}

все равно недокешируется:
3 {pdoCrumbs | snippet: Array ( [showAtHome] => 0 [showHome] => 1 [cacheTime] => 0 ) } 3 0.0030658 0.0148139

в отличии от варианта с обертыванием

ради интереса обернул кеш-враппером каждый вызов кешируемых снипетов, ситуация стала лучше, но все равно феном медленнее чем мод-икс при кешированных запросах.

Инлайн был взят из примера по pdoTools, а разве такие маленькие инлайны хуже чанков? ведь чанк — это плюс запрос к бд. а инлайн он уже есть тут прям сразу де факто.

По поводу времени кеш тайм. а смысл его задавать? Как я понимаю через это время кеш будет считаться очищенным, а этого не хотелось бы, например страницы с редкой посещаемостью и редкой частотой обновления будут страдать и лишаться кеша раньше, чем могли бы без этого ограничения

Уже описал выше, что помогла такая штука на примере крошко-снипета:

{if !$snippet = $_modx->cacheManager->get('cache_key')}
    {set $snippet = $_modx->runSnippet('pdoCrumbs', [
	'showAtHome' => '0',
	'showHome' => '1'
    ])}
    {set $null = $_modx->cacheManager->set('cache_key', $snippet, 0)}
{/if}
{$snippet}

конечно же в данном случае там имеет смысл время 0 задавать (бесконечно хранить)… ну да, помогает оно, кеш тогда работает правильно на феноме. Но каждый вызов каждого снипета оформлять такой жуткой хренью… совсем не кошерно, прям огромная ложка дегтя в бочке с феномом:)

Поставил дебагПарсер (спасибо за подсказки), благодаря ему нашел один провтыканый тег [[]] в феном шаблоне, убрал. картина особо не поменялась. На свежую без кеша феном чуть чуть делает мод-икс. А с кешем все плохо, выходит все снипеты на феноме глючно кешируются (недокешируются). разницы между include и insert при подгрузке шаблона из файла не заметил.

Ну это будет костыль по сути дела, ведь проблема похоже кроется в парсинге именно феномом, так как на дефолтном синтаксисе кеш работает полностью на тех же сниппетах.
Кроме того оборачивать каждый снипет еще одним — будет в два раза больше снипетов. А сделав один универсальный снипет-обретку, которому подсовывать имя нужного снипета, то все равно будет проблема с передачей пргментов, это получается снипет-обертку нужно будет обучить всем возможных аргументам для всех возможных вызываемых снипетов… Или как то можно написать обертку, чтобы она брала все аргументы и все отдавала таргетному снипету? сделать какой-то enum params?

попробовал сделать тест «этим» способом:

{if !$snippet = $_modx->cacheManager->get('cache_key')}
    {set $snippet = $_modx->runSnippet('pdoCrumbs', [
	'showAtHome' => '0',
	'showHome' => '1'
    ])}
    {set $null = $_modx->cacheManager->set('cache_key', $snippet, 0)}
{/if}
{$snippet}

в его случае кешированная загрузка не кушает дополнительный запрос в отличии от:

{'pdoCrumbs' | snippet : [
	'showAtHome' => '0',
	'showHome' => '1'
]}

Глюк с кешированием чанков, обрабатываемых феномом? Ведь по идее я вызываю pdoCrumbs кешировано в обоих вариантах, в т.ч. и втором, где нет воскл. знака. Если кстати я его ставлю во втором варианте то он жрет не на одну кваери болше, а на 3. То есть некешированый вызов как бы срабатывает, но не до конца… а выходит вызов с насильным применением cacheManager фиксит этот глюк и приравнивает вызов к вызову через [['snippet']]?