Максим

Конечно есть!
1) Отказаться от сырых запросов. Зачем сначала получать вендеров, потом получать id товаров и потом еще запускать сниппет для получения товаров по id, если в исходниках miniShop2 указана связь?
2) Зачем тук сложно реализована работа с чанком? Зачем чанку отключать кеширование? У меня, по крайней мере, никогда не было проблем с кешированием. На мой взгляд куда правильнее получить сервис pdoTools и использовать его метод getChank, тем самым получив возможность использовать в чанке fenom и обойтись одним чанком.
Думаю что код станет меньше и корректнее по отношению к MODX и установленным компонентам.

Есть несколько вариантов решения задачи:

Для создания отдельных страниц для брендов (выбрали Самсунг — попали на страницу Самсунг)
1) Указать у производителя соответствующую страницу и на ней вызывать сниппет (для каждого производителя придется создавать отдельную страницу).
2) Создать единую страницу для всех брендов и воспользоваться этой инструкцией для настройки

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

Я бы сделал так:
1) Написал свой сниппет для получения товаров, категорий и статей, который бы в зависимости от класса подтягивал необходимые данные (Для товара это дата превью, вендор..., для категорий и статей — соответствующие TV) и оборачивал в соответствующий чанк.
2) указал бы этот сниппет в параметре element сниппета pdoPage.
Если я все правильно помню, то для корректной работы pdoPage сниппет должен в результат добавлять общее кол-во записей, лимит и страницу.

Попробуйте отсортировать по полю rank или docid.
А вообще сниппет достаточно простой и метод сортировки вызывается. Так как объект наследуется от xPDOSimpleObject, то и поле id у него должно быть, и соответственно по нему должна происходить сортировка. Попробуйте поиграть с направлением сортировки. Думаю все должно работать.

Я бы посоветовал копать в сторону Fenom и отказа от использования сниппета getImageList. Написать парочку своих модификаторов и все будет как вы захотите!

Судя по исходнику, Вы никак не сможете выводит нужное сообщение через плагин:

$response = $this->ms2->invokeEvent('msOnGetOrderCost', array(
            'order' => $this,
            'cart' => $this->ms2->cart,
            'with_cart' => $with_cart,
            'only_cost' => $only_cost,
            'cost' => $cost,
        ));
        if (!$response['success']) {
            return $this->error($response['message']);
        }
        $cost = $response['data']['cost'];

        return $only_cost
            ? $cost
            : $this->success('', array('cost' => $cost));

Но Вы можете в JS на Order.getcost.response.success вызвать свой процессор. Ну и там уже делать все, что вам нужно.

Может это поможет: modx.pro/solutions/14568

{$longtitle ? '<small>(' ~ $longtitle ~ ')</small>' :'' }

Описание дополнения msImportExport
Там написано, что умеет. Рекомендую обратиться в поддержку.

Исходники pdoMenu у вас есть. Можно написать свой сниппет по примеру, и limit направить не на выборку из базы а на кол-во итераций при переборе массива результатов. Это конечно не совсем правильно, так как получается что из базы тащишь все записи, но если подойти с головой, то можно сделать достаточно умную выборку.

Мне кажется под это можно приспособить pdoMenu. Вродь как обычная структура менюхи.

В настройках минишопа добавить связи и использовать связанные товары. Там только нужно будет немного JS написать, для добавления товаров в корзину.

В примере уровень вложенности от 1 до 5, а у вас от 1 до 2. В чем проблема?
Или за вас таки написать вызов сниппета?

Используйте суперглобальный массив $_GET:
[[#GET.page:isnot=`1`:then=`...`:else=``]]
Только стоит использовать не isnot а проверку на юольше единицы.

Конечно можно! Особенно если читать описание компонента:
импорт через cron также использует чуть меньше расход ресурсов, а также позволяет частично решить проблему
timeout. Дополнительная инфа по настройки сервера для работы с большими файлами есть в доках дополнения в
разделе “Импорт больших файлов”
А еще можно написать в поддержку компонента и описать проблему.

1) Удалить руками все из папки /core/cache/
2) Проверить возможность входа в админку.
Если это не помогло, то:
3) В базе деактивировать плагин с id 7
4) Зайти в админку, разобраться (исправить ошибку) с плагином с id 7 и если он нужен, то активировать его обратно.

Никогда не пользуюсь капчей. Всегда обхожусь скрытым полем и хуком с соответствующими проверками. Можно в стилях прописать для определенных форм что-то типа того: .form input[name=«email»] {display:none;} Тогда поле с name email будет скрыто, а для пользовательского ввода использовать, например userEmail.
Ну а в хуке проверять на заполненность поля с name email + если отправка аяксом, то проверить на аякс, ну и можно еще кнопке отправить дать нейм, например mysubmit и в хуке проверять, есть ли в суперглобальном массиве соответствующий ключь mysubmit.
Почитать про хуки можно тут
Ну и проверка на ajax. Вариант предложенный Василием ни разу еще не подвел.

Если я правильно понял, то вы для обоих деревьев храните инфу в одной таблице. Тогда нужно ее хоть как-то разграничивать. Помимо category_id добавить еще поля типа market and webmaster, с дефолтным значеним 0. Если дерево маркета, то в маркет 1, если дерево вебмастера, то в него 1.

Вы можете ознакомиться с доступными событиями в документации
Событие которое вы пытаетесь использовать доступно только при работе через процессор

Данный процессор встречается в файле orders.grid.products.js в методах addOrderProduct и updateOrderProduct возможно стоит их переопределить с новым процессором.
Честно говоря сам не очень силен в ExtJS