Еще один кейс: на сайте куча пользователей без какой-либо группы. Надо их всех закинуть в определенную группу.
 
К слову, это еще один логический минус системы политик безопасности MODX, так как уровни доступов пользователей настраиваются только на основании групп пользователей, а тут получается, что пользователь и не аноним (неавторизованные пользователи в группе анонимов находятся, которой можно задавать права доступов), и ни в какой другой группе. Без группы им вообще нельзя права задать, и получается, что часто такие пользователи вообще прав меньше имеют, чем анонимы даже.   
 
Готовый код:
 
<?php

ini_set('max_execution_time', 0);
ignore_user_abort(true);

print '<pre>';

// Формируем запрос на выборку пользователей, не состоящих ни в одной группе
$q = $modx->newQuery('modUser');
$q->leftJoin('modUserGroupMember', 'UserGroupMembers');

$q->where(array(
    "UserGroupMembers.id"   => null,
));

// Подсчет количества таких пользователей
// print "<br />". $modx->getCount('modUser', $q);

$groupId = 5;       // ID группы пользователей, в которую надо добавить пользователя
$roleId = null;     // ID роли
$rank = null;

foreach($modx->getIterator("modUser", $q) as $user){
    
    // Добавляем пользователя в группу
    $user->joinGroup($groupId, $roleId, $rank);
}

print "<br />OK";

Возникла на сайте задача создать кучу пользователей и разослать им уведомления (с кастомным сообщением). Как обычно, решил выполнить это с помощью родного MODX-процессора. Как оказалось, здесь не мало подводных камней имеется…
 
Сразу опубликую итоговый код, а детали далее разберем.  
 
<?php

$modx->switchContext('web');

print '<pre>';

$site_url = $modx->getOption("site_url");

$msg = "
<p>Здравствуйте!</p>

<p>Ваши данные для авторизации на сайте <a href='{$site_url}'>[[+sname]]</a>:</p>

<p><strong>Логин:</strong> [[+uid]]<br />
<strong>Пароль:</strong> [[+pwd]]</p>

<p>После авторизации на сайте вы сможете изменить свой пароль.</p>

<p>С уважением,<br />
Администрация сайта.</p>
";

$modx->setOption('signupemail_message', $msg);

$username = "username";
$email = "user_email";
$fullname = 'user_fullname';

$data = array(
    "passwordnotifymethod"  => 'g',     // Указываем, что пароль надо сгенерировать
    "username"  => $username,           
    "email"     => $email,
    "fullname"     => $fullname,
    "active"    => 1,
    "passwordnotifymethod"  => "e",     // Данные регистрации надо отправить на почту пользователю
    "groups"    => array(
        array(
            "usergroup" => 1,           // ID группы пользователей
            "role"      => 1,           // Роль. 1 - Member
        ),    
    ),
);

$modx->error->reset();

$response = $modx->runProcessor('security/user/create', $data);

if($response->isError()){
    print_r($response->getResponse());
}

print "OK";
Первое: путаница. В системе есть две настройки: signupemail_message и websignupemail_message. Предполагаю, что это пережиток прошлого (времен MODX Evolution). Тогда было четкое разделение пользователей на системных манагеров и веб-пользователей. Хотя может просто закладывали основу, но так и не довели до ума. Так или иначе, но настройка websignupemail_message (шаблон письма для веб-пользователей) не используется, используется только signupemail_message.
 
Второе: неприятность. При отправки письма пользователю, MODX формирует ссылку на сайт, да не просто ссылку, а ссылку на админ-панель. И переопределить это нельзя.
 
'surl' => $this->modx->getOption('url_scheme') . $this->modx->getOption('http_host') . $this->modx->getOption('manager_url'),
Вот это совсем не круто. Поэтому мы в свой кастомный шаблон прописали свой $site_url. Можно было, конечно, задать $modx->setOption('manager_url', '/'), но все равно не круто.
 
Третье: вообще досадная неприятность: MODX при обработке письма использует не парсер, а str_replace().
 
foreach ($placeholders as $k => $v) {
    $message = str_replace('[[+'.$k.']]',$v,$message);
}
В итоге нельзя ни системные настройки в шаблоне использовать, ни чанки-сниппеты, нифига.

Не за что.
 Поправил.
 Когда-нибудь сделаем. Просто руки не доходят.

По-теме могу только спасибо сказать. А теперь буду офтопить.
 От назовите меня занудой, но разширение.
 
еще дино предложение — злостный офтоп: можете сделать возможность переголосовать (там где палец вверх и вниз)? А то я бывало промахивался, вместо "+" ставил минус, по-ошибки, а потом все, не поменяешь.

Пилю на проекте расширенную панель управления пользователями, и по традиции решил не переписывать все с нуля, а просто взять и расширить родной MODX-компонент MODx.grid.User.
 
CustomComponent.grid.UsersGrid = function(config) {
    config = config || {};
    
    Ext.applyIf(config, {
        baseParams: {
            action: 'custom/security/user/getList'
            ,usergroup: MODx.request['usergroup'] ? MODx.request['usergroup'] : ''
        }
    });
     
    CustomComponent.grid.UsersGrid.superclass.constructor.call(this, config); 
    
}

Ext.extend(CustomComponent.grid.UsersGrid, MODx.grid.User,{
     
});

Ext.reg('modx-grid-user', CustomComponent.grid.UsersGrid);
Да вот только не заладилось… Мои изменения не воспринимаются. Стал копать, оказалось компонент UserKarma так же переопределяет родной компонент и затирает мои изменения (точнее по новой создает компонент из базового). Возник вопрос — как же переопределять так, чтобы можно было и другим поверх переопределяться? Получился вот такой вариант:
 
var _prototype = Ext.ComponentMgr.types['modx-grid-user'];

CustomComponent.grid.UsersGrid = function(config) {
    config = config || {};
    
    Ext.applyIf(config, {
        baseParams: {
            action: 'custom/security/user/getList'
            ,usergroup: MODx.request['usergroup'] ? MODx.request['usergroup'] : ''
        }
    });
     
    CustomComponent.grid.UsersGrid.superclass.constructor.call(this, config); 
    
}

Ext.extend(CustomComponent.grid.UsersGrid, _prototype,{
     
});

Ext.reg('modx-grid-user', CustomComponent.grid.UsersGrid);
Здесь переменная _prototype — это всегда актуальная зарегистрированная функция-прототип компонента (зарегистрированного по xtype 'modx-grid-user'). Вот так уже два переопределения не особо конфликтуют друг с другом. Здесь конечно же возможны логические ошибки, если они начнут друг у друга переопределять параметры, а не дописывать их новые, но тем не менее в конечном гриде учтены дополнения обоих расширенных компонентов. Предлагаю взять этот метод как стандартный в переопределении базовых компонентов. Тогда не будет явных конфликтов при использовании нескольких расширений.

Может у вас указан параметр parent, а не category_id?

Здравствуйте, подскажите, почему у меня выводятся только товары категории, а из подкатегорий нет?