Воеводский Михаил

Воеводский Михаил

Был в сети 30 марта 2026, 14:44
Заказы не принимаю
Они теперь не нужны. Внимательно прочитайте пост про RC:
Страницы классов TicketsSection и Ticket расширены гораздо более грамотно, и не мешают подключению сторонних дополнений, типа Tagger. Да-да, вы можете использовать эти теги вместе с Tickets!
Сразу после
case 'OnUserSave':
Добавьте
$modx->log(1,'Плагин уведомления о новом пользователе запущен');
Если такой строки не увидите в системном журнале, то разбирайтесь, почему плагин не запускается.

Сам плагин рабочий, скопирован с действующего проекта.
Нужно не только с такими вызовами фильтров разобраться, но и заново пересмотреть структуру. Имеющееся обилие фильтров всегда будут потенциальным источником головной боли.

Нескольких шаблонов не нужно бояться. Лучше 2-3 простых шаблона, чем один перегруженный фильтрами.
&actionKey Вы добавили сами, этот параметр работал корректно.
Для отключения переадресации необходимо было добавить &loginResourceId=`[[*id]]`.

Что касается чрезмерного количества условий в шаблоне — парсер MODX сначала обрабатывает самые внутренние вложенные конструкции, и только потом внешние.

Пример:
[[*id:is=`72`:then=`[[!Shopkeeper@cartCatalog?propertySetName=`cartCatalog` &cartType=`full`]]
[[!$orderTpl]]`]]
Сначала будет запущен в работу сниппет Shopkeeper со всеми параметрами и обработан чанк orderTpl, и только потом запустится проверка условия по ID. Но если ID не совпадет, то результат работы первого шага выводить не нужно. Он и не выведется. А время на обработку уже затрачено.
Поскольку большинство страниц, к которым применен шаблон, служебные, вызовы необходимых сниппетов правильнее писать непосредственно в их поле content, а в шаблоне вместо кучи строк с проверкой ID сделать простой вызов [[*content]].

Но если уж хочется сделать все в одном шаблоне с проверкой ID, используйте такие конструкции:
[[[[*id:is=`72`:then=`!Shopkeeper`:else=`-`]]@cartCatalog?propertySetName=`cartCatalog` &cartType=`full`]]
[[[[*id:is=`72`:then=`!$orderTpl`:else=`-`]]]]
Разница по сравнению с первым вариантом в том, сначала выполнится внутреннее условие проверки по ID и, если произойдет совпадение, после подстановки значения образуется новый для выполнения тег.

Таким образом, сниппет запустится только на одной единственной странице, а не на всех сразу.
Если так изменить все остальные условия, Вы сразу же заметите разницу в скорости загрузки страниц с этим шаблоном.
Тикеты по определению в разы больше подходят для решения задачи, нежели FormIt2db. Сохраните Вы форму, а дальше что? Несколько форм надо связать между собой, как минимум. Появится невероятное количество велосипедов, которые при использовании Tickets просто не понадобятся.
Тайтлы — через JS достаточно легко это сделать.
По урлам —
modx.pro/components/5355-msearch2-version-1-3-0-alias-filters/
Василий недавно обновил компонент, для tv|metro возможно задать alias, и тогда адрес станет на порядок удобнее. Что же касается полноценных FURL, mSearch их не генерирует.

Как на твоем сайте сделан каталог по станциям, пускай он таким и остается. А полноценный множественный фильтр с ЧПУ сложно представить. В каком порядке в адресе должны располагаться фильтры? Как реализовать подстановку значений «От» и «До»?

ИМХО, здесь Василий в отношении ЧПУ прав полностью — каталог страница с фильтром является технической, поэтому наличие многих GET параметров в адресе допустимо.
Разгадка здесь.
Когда запрашиваются группы пользователя, их список берется из сессии.

Алексей, попробуйте проверить, применяется ли изменение групп, если в сессии есть только один контекст.
Сейчас для ответа посмотрел modUser и процессор logout, обратил внимание на интересный момент — если после logout не остается контекстов, в которых пользователь залогинен, сессия должна уничтожиться. Если же есть еще контексты, то со списком групп ничего не произойдет.