Droug

Я уже писал об этом. Это, видимо, теперь нормальное поведение для modx, после обновления до 2.5.2

Модификаторы вроде как не кэшируются, но я в этом не уверен.

Нужно понимание критерия, по которому выбираются эти «правильные» документы. А исходя из этого уже можно формировать условие выборки для pdoMenu

А если как-то так сделать?

&where=`{"parent:!=":"15"}`

Нинада отключать. Не ругайтесь. Всё хорошо…

А так работает?

&tplWrapper=`@INLINE {{+output}}`

P.S.: Если вкл феном — весь вызов в {ignore}...{/ignore}

P.P.S.: Это таки есть в документации)

На всякий случай проверил на чистом тестовом — то же самое. Заходишь от гостя — получаешь единицы.

P. P. S.: Пока проверяю по

{if $_modx->user.id && 0|ismember:'Administrator'}...{/if}

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

Я тоже слазил в код и пишу как раз о том, что для залогиненых всё ок, админы — админы, неадмины — нет, а вот на гостей такая проверка стала возвращать true… И, поскольку в pdoTools функция не менялась, то изменилось поведение самого xPDO и он начал возвращать 1. По кр. мере у меня так на нескольких сайтах на разных площадках.

P. S.: $_modx->user.id — это и есть текущий пользователь, т.е. 0|ismember и $_modx->user.id|ismember — эквивалентные записи.

Тогда уж mgr (и это, кстати, не дает понять кто в какой группе, а лишь говорит кто где залогинен), но вопрос про то, что с какой-то версии, скорее всего с 2.5.2

{0|ismember:'Administrator'}

сам по себе возвращает true для всех гостей…

Если оба их выключить — пустые страницы остаются пустыми или начинают работать?

А если в системных настройках выключить compress_css и compress_js — проблема остается?

P.S.: по 500: надо смотреть не логи в кеше modx, а логи сервера.

Пожалуй, самым простым, но не самым правильным решением будет два вызова pdoResources.
В первом вызове выбрать список всех возможных каталогов, условно как-то так:

[[pdoResources:replace=`||==,`?
    &tvFilters=`cities==%#[[*id]]#%`
    &parents=`ид_родителя_предложений`
    &includeTVs=`cities,catalog`
    &tpl=`@INLINE {{+tv.catalog}}`
    &outputSeparator=`,`
    &toPlaceholder=`cataloglist`
]]

А затем сделать выборку каталогов по списку полученных ресурсов:

[[pdoResources:default=`No results`?
    &parents=`ид_родителя_каталогов`
    &resources=`[[+cataloglist]]`
    &includeTVs=`name,year,author`
    &processTVs=`1`
    &sortby=`{ "pagetitle":"ASC" }`
    &tpl=`@INLINE <a href="[[+uri]]?city=[[*alias]]">[[+pagetitle]] в [[*longtitle]]</a> ||`
]]

Примерно…

P.S.: Мне не совсем ясно, зачем там name,year,author и зачем их процессить, если они все равно в шаблоне не используются, ну да ладно.

А можно глупый вопрос? Почему

{if '0'|ismember:'Administrator'}1{/if}

возвращает 1? 0 — это же все неавторизованные, они никак не могут быть админами…

Очень приближенно нужно вместо

$message = $this->modx->getChunk('subcribe', $array);

Написать что-то такое:

$pdoTools = $this->modx->getService('pdoTools');
$message = $pdoTools?$pdoTools->getChunk('subcribe', $array):$this->modx->getChunk('subcribe', $array);

Эм, ну pdoResources как бы не занимается фильтрацией результатов, он только формирует запрос к бд и оборачивает результаты выборки шаблоном. А в БД migx поля хранятся в виде JSON в одном поле, так что кроме LIKE и RLIKE фильтровать тут особо и нечем.

P.S.: Возможно, надо копать в сторону MIGXdb, там данные хранятся в отдельной таблице и вариантов фильтрации уже больше.

Лучше для такой выборки по возможности использовать не migx, а listbox-multiple (Список (множественный выбор).
А для фильтрации что то вроде

&where=`{"tvName:RLIKE":"(\\|?)3(\\|?)"}`

Отличное обновление для фенома, еще бы можно было бы до $_modx->resource покороче достучаться, было бы просто супер)

Т.е. вместо {$_modx->resource.pagetitle} хочется иметь что-то вроде {$_pagetitle} или {$_res['pagetitle']}