Сушите весла… Сами вряд ли сделаете. Надо добавлять в селект запрос вида if(find_in_set('{$value}', column) 1, 0) as exists и order by exists DESC, но просто так не сделать этого (скажем так, это небольшая недоработка getdata-процессора). Хотя попробуйте так:

1. В prepareQueryBeforeCount() добавляете left join своей ТВшки, в которой содержатся эти значения.
2. В initialize() добавляете $this->setDefaultProperties(array( "sort" => "if(find_in_set('{$value}', column) 1, 0)", "dir" => "DESC", )); Если надо не порядок отсортировать, а именно получить только те товары, которые есть в указанной категории, то тут проще: пишем в prepareQueryBeforeCount() так: $c->innerJoin('modTemplateVarResource', "tv_categories", "tv_categories.contentid = {$this->classKey}.id AND tv_categories.tmplvarid = {$tv_id} AND find_in_set('{$value}', tv_categories.value)");

Николай подскажите, а как расширить данный процессор, чтобы можно было делать сортировку, если в tv содержится массив из id вида 12,25,45? Т.е. один и тот же товар может принадлежать нескольким категориям. Интересует именно такая реализация. натолкните на мысль хотя бы. Спасибо

ОК. По результатам отпишитесь помогло ли.

Спасибо большое. Замечание учтено исправлюсь

Пишу здесь результаты переписки. У вас там логика просто в интерфейсе не верно построена. У вас на изменение способа доставки 4 запрос отправляется. joxi.ru/DrlaPn9iEYodmP А на изменение кол-ва товаров только три. Это говорит о том, что части интерфейса не связаны с собой. У нас в интерфейсе изменение любого элемента вызывает запрос на сервер на изменение, после чего выполняется запрос опять на сервер на получение всех актуальных данных корзины, после чего выполняется апдейт всех элементов, которые выводят стоимость (хоть 100500). У вас же для блока доставок одна логика, для блока товаров другая. Поэтому и проблемы. Проблема явно проявляется, когда на странице управления заказом начинаешь менять и способы доставки и кол-во товаров.

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

Проблема в том, что вы все не по фэншую делает. modPHPMailer не является наследником класса modProcessor, а потому его нельзя использовать как основу для процессора. Правильней вашим процессором расширить modProcessor и в методе process() получить сервис почты. $mailer = $this->modx->getService('mail.modPhpMailer'); P.S. И не пишите никогда такого: dirname(dirname(dirname(dirname(dirname(dirname(dirname(FILE))))))).'/model/modx/mail/modphpmailer.class.php'; Правильней MODX_CORE_PATH.'model/modx/mail/modphpmailer.class.php'; А в предложенном мной варианте этого вообще не нужно.

Но это не решит твоей проблемы с лейзи. Проверяй мапу. Ссылку я дал.

О, а точно, спасибо, переделаю через связанные объекты. Посмотрим, что будет))

Илья, привет. Чаще всего такое происходит, когда в мап-файле не для всех колонок есть описания. Смотри ветку здесь. На счет твоего сохранения двух объектов: как я понимаю, это на самом деле повторное сохранение одного и того же объекта, просто в первом случае он создается новый, а во втором он дергается из базы. В целом твой процессор логически не правильный. Исключение — это только если ты допускаешь, что созданный $secondOp может оставаться сохраненным в базе данных, даже если первичный объект не удалось сохранить. Надо же понимать, что в beforeSet() create-процессора $this->object еще не сохранен, и у него нет ID-шника. При попытке выполнения этого процессора у тебя еще в beforeSet() сохраняется вторичный объект, хотя в итоге этот метод может вернуть ошибку (а если не он, то еще есть beforeSave(), который так же может вернуть ошибку), и первичный объект не сохранится, а вторичный объект уже будет в БД. Все-таки гораздо правильней в подобных случаях через связанные объекты делать. То есть задай связи этим двум классам и в beforeSet() пропиши типа $this->object->secondOp = $this->modx->newObject('Operation'); И при сохранении первичного объекта у тебя автоматически и вторичный сохранится. Конечно и здесь есть логические ошибки в xPDO, ибо при сохранении первичного объекта сначала сохраняются вторичные объекты, и только потом первичный (а потом и опять вторичные), но здесь уже вероятность ошибок будет гораздо меньше. Плюс к этому ты на любом этапе до сохранения первичного объекта можешь устанавливать любые значения вторичному объекту, и он будет сохранен только при попытке сохранить первичный объект. Если до первичного объекта дело не дойдет, то и вторичный не будет записан в БД.