Так с этим никто не спорит. Я как бы намекнул, что надо таки туда поглядеть и увидеть, что базовый гетлист процессор в методе getData получает коллекцию, а в методе iterate дергается prepareRow с $object->toArray() под капотом; и select полетит, но не в результатах для вывода. Просто лень все это было печатать…

я знал что есть такая штука как процессоры но это все было далеким и каким то туманным. вся работа заключалась в сниппет->phpClass начав знакомство с процессорами я вижу что при таких возможностях использование snippet->phpClass это просто кощунство outputArray т.е. формировать строку ответа в ручную?

Можно и там, но лучше все-таки сформировать запрос без лишних полей. Нагрузка на мускул меньше будет.

можно вставить перед return $c; такие строки $c->prepare(); print_r($c->toSQL()); die; и если выполнить этот процессор в консоли, выведется sql-запрос

ага)я тоже уже пересмотрел… дело в том что даже если вот так public function prepareQueryBeforeCount(xPDOQuery $c) { $c->where(array( 'sudo' => 1, ));

    $c->select(array(
        'id',
        'username',
    ));

    return $c;
} $response->getResponse() выдает полностью все колонки таблицы что ж за беда то такая

А, вот что :) Я по инерции подумал, что из modxSite процессор за основу взят Если посмотреть core/model/modx/modprocessor.class.php, то у процессора modObjectGetListProcessor нет метода setSelection. Здесь select можно разместить как раз в функции prepareQueryBeforeCount

поспешил отписаться… все равно $response->getResponse() возвращает всю таблицу class xtestGetUsersProcessor extends modObjectGetListProcessor{ public $classKey = 'modUser'; public $defaultSortField = 'id'; public $defaultSortDirection = 'ASC'; public $objectType = 'modUser';

public function prepareQueryBeforeCount(xPDOQuery $c) {
        $c->where(array(
            'sudo' => 1,
        ));
    return $c;
}
public function setSelection(xPDOQuery $c){
    $c->select(array(
        'id',
        'username',
    ));
    return $c;
}

} return 'xtestGetUsersProcessor';