Сергей Шлоков

Я бы создал коллекцию объектов (можно через pdoResources) таким запросом

select Res.* from `modx_site_content` as Parent
inner join `modx_site_content` as Res on Res.parent = Parent.id
where Parent.parent = 12
ORDER BY Res.parent ASC, Res.id DESC

А затем пробежался по массиву и сформировал требуемую коллекцию с одним дочерним ресурсом.
Итого всего один запрос к БД.

Ибо не положено. Вообще, как минимум, странно разрешать гостям писать разметку в описании.

Есть более функциональный календарь fullCalendar. У него есть MODX и javascript события для управления событиями календаря.

Как минимум глянуть в параметры сниппета. Документацию почитать не предлагаю — молодое поколение программистов просто засмеёт.

Советую поставить Tickets. Он удобнее для ведения блога — в нем есть генератор урла для документов, возможность не показывать документы в дереве и т.п.

В инлайн-чанках для условий используйте фигурные скобки вместо квадратных.

Насколько я понимаю, перенос происходит вручную. Если при сохранении нового документа возникает ошибка, то проще в форме в поле alias добавить, например, дату документа — congratulation-2016-01-01.

Ярко. Для полной красоты можно было бы добавить ещё красный треугольник. Единственный вопрос — где стрелочки, кружочки и квадратики, выделяющие событие OnBeforeDocFormSave? И где само это событие на картинке??? Хотя это уже второй вопрос.

П.С. Событие OnDocFormSave срабатывает после сохранения ресурса, а ошибка возникает при сохранении.

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

Вот так.

siteStatictics не является альтернативой Google.Analytics и и Яндекс.Метрики. Он ведёт:
— статистику посещений и просмотров ресурсов, которую можно использовать для сортировки ресурсов по популярности;
— статистику посещений пользователей.

Ещё он показывает пользователей, которые в текущий момент находятся на сайте. Вот ссылка на полную документацию с описанием всех возможностей компонента.

И есть ли возможность вытащить эти данные и например вставить их в данные формы или заказа?

UTM-метки — это get параметры. Работать с ними можно как на уровне PHP, так и на уровне Fenom. siteStatistics не ведёт отдельный учёт по этим меткам. Для этого есть гугл и яндекс.

Мужики, объясните, а что, в Казахстане и Белорусии не слышали про кабели? Или они просто кончились?

А ещё лучше

WHERE FIND_IN_SET({$var}, u.id) > 0

FIND_IN_SET

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

Ждемс. Хочется посмотреть как вы на казахском разговариваете. :)

Может лучше вместо удаления очищать профиль?

Попробуй через $user->remove(). Он менее строгий. Но страницу надо сразу обновлять или пользователя перенаправлять куда-то.

Для ясности… отдельно профиль удалить нельзя. Он удаляется автоматически при удалении пользователя. Собственно указанный процессор удаляет именно пользователя.

Каким образом процессор должен понять какого пользователя удалять? Ему нужно передать id пользователя. А форма ему передаёт uid.

Ну и наконец (насколько я помню) MODX не разрешает удалять текущего пользователя.

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

$user = $modx->getObject('modUser', (int) $_POST['uid']); 
$user->remove();

Посмотри про параметр thread сниппета TicketComments

Внесу свои 5 копеек в оптимизацию кода.

1. Самая первая переменная называется $parent, а проверяется $parent_id. Явная опечатка.
2. Блок с Alt key непонятно зачем нужен. Достаточно просто указать ключ context вместо ctx и context_key. Думаю, программисту это будет не сложно.
3. В коде

if (!$parents = $modx->getParentIds($input, $height, $options)) {
    $parents = array();
}

можно сразу возвращать null. Зачем тратить время на дальнейшие операции.

П.С. Ещё желательно, чтобы переменная height была необязательная. Она явно ограничивает применение фильтра.