Руслан Алеев

:) А вы можете указать код чанка? Нужно в идеале отловить процесс возникновения ошибки, чтобы тестировать появление окна. А то, что окно в «opacity:0» висит — это понятно.

:) Ага, прикольно, отправьте issue на github — github.com/modxcms/revolution/issues/

И еще поменяйте в условии

strlen($term)

на

iconv_strlen($term)

В в вызове укажите &minChars=`1`.

И в файле:

core/components/simplesearch/model/simplesearch/simplesearch.class.php

Замените условие у функции parseSearchString($str = '') (строка 155) на:

if (strlen($term) < $minChars && in_array($term, $reserved)) {
    unset($this->searchArray[$key]);
}

По-моему там ошибка в проверке. Было !in_array($term, $reserved).

Понял, спасибо

Попробовал использовать такой вызов, но выводится массив.
Т.е. в итоге,

{$_modx->resource.tvname} != {'tvname' | resource}

Хотя, к примеру, {'content' | resource} выведет именно содержание, тут нет ошибки в модификаторе | resource?

А где это прописано? В процессе установки можно выбрать любую кодировку. А, к примеру, у меня config.inc.php выглядит так:

$database_connection_charset = 'utf8';
...
$database_dsn = 'mysql:host=localhost;dbname=DB_NAME;charset=utf8';

Не пойму где именно MODX использует utf8mb4 по умолчанию, и использует ли вообще.

Быстрого решения нету. Нужно писать сниппет, который выводил бы активные ресурсы в соответствующем порядке. И уже вызывать pdoResources с подстановкой этих ресурсов.

Совместными усилиями пришли к работающему варианту:

[[!SimpleSearch?
&customPackages=`msProductData:article:minishop2:{core_path}/components/minishop2/model/:msProductData.id = modResource.id`
]]

Именно msProductData, а не msProduct. В :article: можно через запятую указать и другие поля, типа: :article,price,vendor: и т.п.

Да, спасибо, разобрались с этим — modx.pro/help/20713#comment-122474

В итоге, с помощью @Баха Волков и исходников, выяснилось, что унификация написания есть, с помощью модификаторов через | (что не может не радовать):

[[*content]] -> {'content' | resource}
[[+pagetitle]] -> {$pagetitle} (не путать с {'result' | placeholder})
[[$chunkName]] -> {'chunkName' | chunk}
[[!snippetName]] -> {'!snippetName' | snippet}
[[++settingKey]] -> {'settingKey' | option}
[[%lexiconName]] -> {'lexiconName' | lexicon}
[[~5]] -> {5 | url}
[[...:ellipsis=`100`]] -> {... | ellipsis : 100}

В итоге вопрос снят, спасибо за обсуждение!

Все это доступно в $_modx->resource.

Вы подменяете понятия, вопрос про стиль написания. Выше вы писали, что есть стиль единый, а выходит он не единый.

@Артем @Баха Волков Я работаю с fenom, я даже не утверждаю что он хуже, наоборот, выше писал, что там плюшек больше и это дело привычки. Но мне, персонально, не нравится как это выглядит (в сравнении с [[+]], [[*]], [[$]] и т.п.). А вы мне пытаетесь обосновать то, что мне это должно нравиться :)

Наше обсуждение можно привести к аналогии:
— Мне не нравится капуста.
— Но тебе должна нравится капуста, она полезна.
— Ну чет не мое, не люблю капусту.
— Да любишь, смотри, голубцы можно сделать же, и прочее, красота!
— …
:)

Так это и так уже есть — альтернативный синтаксис через прямую черту. Например,
{1 | resource: 'pagetitle'}
{'some_entry' | lexicon}
{'some_text' | upper}
Чем не единый стиль?

Вот с сокращенной записью можно работать, почти оно, но к сожалению, не все можно вывести. Как, к примеру, вывести TV или id текущего ресурса через |?
А вызов вида

{'id' | placeholder}

в шаблоне сниппета по-моему не работает вообще. Или тут какие-то подводные камни снова?
p.s. Если что, я не говорю, что стандартный шаблонизатор лучше, он просто выглядит логичнее и проще.

что разношерстнее — модификаторы или несколько вариаций обращения к массиву в Fenom

Для конкретного разработчика однозначно вариации обращений в fenom больше, т.к. если я и буду использовать модификатор, то один вариант, который привычен (например, :ne=``), а в fenom мне в любом случае нужно использовать все варианты обращений. Но я не понял причем тут модификаторы, я имел ввиду именно вызов тегов MODX. Было бы сильно удобнее, если бы fenom в MODX отрабатывал бы по схожей логике, например:

{$_modx->lexicon('lexicon')} - {$_modx->%('lexicon')}
{$_modx->resource.tv_param} - {$_modx->*('tv_param')}
{$id} - {$_modx->+('id')}

Или еще как-то лаконичнее.

Если «шаблонизатор» не позволяет пройтись по массиву в цикле, то это никакой не шаблонизатор

Есть какой-то стандарт требований к шаблонизатору? Я не нашел. Так можно и шире рассуждать, мол зачем вообще писать сниппеты, пусть «тру-шаблонизатор» отрабатывает все.

Ну, судя по статьям в сети, и то, и то подходит под «шаблонизатор».

Лично меня раздражает то, что синтаксис сильно вариативный, типа:

{$id}, {$_modx->resource.tv_param}, {$_modx->lexicon('lexicon')}

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

… просто отвратительное занятие.

реально настолько отвратительно? :) И то, и то шаблонизаторы, принципиальной разницы нету.

Всегда работает, а вот к fenom бывают вопросы :) Хотя это дело привычки. И, кстати, встроенные модификаторы MODX fenom также использует, в доках же есть.

Не думаю, что MODX видит разницу между каталогом или деталкой, для него и то, и то — ресурс. Скорее всего вы что-то не так выводите.

В настройках TV можно указать формат вывода, и там есть html-тег.

Спасибо, закинул в обсуждение на github — github.com/modxcms/revolution/issues/13933#issuecomment-672907053
С миру по нитке собираем инфу :)