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

Более правильным вариантом будет не «с нуля», а сделать форк Tickets, и уже их капитально допиливать.

Самый простой способ — отправить ajax запрос с параметром:

/?ms2_action=cart/clean

bezumkin.ru/training/course1/

С учетом запланированного масштаба, все данные необходимо хранить в собственных таблицах. Слишком много может быть доп.полей, такое количество TV поддерживать вручную сложно.

modx.pro/components/5433-tickets-version-161pl-user-ratings/#comment-39067

$modx->mail->set(modMail::MAIL_FROM,'noreply@from.ru');

Очень похоже, что отправка осуществляется через SMTP.
Поставьте реальный адрес отправителя.

Они теперь не нужны. Внимательно прочитайте пост про RC:

Страницы классов TicketsSection и Ticket расширены гораздо более грамотно, и не мешают подключению сторонних дополнений, типа Tagger. Да-да, вы можете использовать эти теги вместе с Tickets!

Это говорит только о том, что сообщение выводится на уровне ошибок.

Измените строку:

$modx->log(1,'Плагин уведомления о новом пользователе запущен. Режим изменения пользователя: '.$mode);

Сразу после

case 'OnUserSave':

Добавьте

$modx->log(1,'Плагин уведомления о новом пользователе запущен');

Если такой строки не увидите в системном журнале, то разбирайтесь, почему плагин не запускается.

Сам плагин рабочий, скопирован с действующего проекта.

Вручную укажите значения. Например:

$message = 'Message content';
$email = 'your@email.';

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

Для заказов система плагинов не предусмотрена.

Насколько я знаю, решение твоей задачи невозможно без существенного вмешательства в исходники MS2.

Проверьте, работает ли отправка почты с Вашего сайта, с помощью QuickEmail.

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

Нескольких шаблонов не нужно бояться. Лучше 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 параметров в адресе допустимо.