Артур Шевченко

Будет только фильтрация.

В первой версии скорее всего будет только конфиг примерно такой

return [
    12 => [
        'filters' => [
            'width' => [
                'filter_type' => 'numrange',
                'field_type' => 'number'
            ]
        ]
    ]
]

12 — id категории, width — опция. По этой конфигурации будет создана таблица в БД с полями id, rid, width в которую будут записаны значения опции width для каждого товара. В шаблоне ты будешь вызывать сниппет и указывать ему параметр configName = 12 и шаблоны для каждого поля, по аналогии c mFilter2, а он тебе отрисует фильтры.

Ну это потому что у вас modx 2.8.6 Надо править исходники библиотеки phpthumb

Подключить их самостоятельно. Библиотека уже есть в комплекте, её нужно подключить в ваш JS, и потом сделать что-то типа

miniShop2.Message = {
success = function(message){
    IziToast.show({message: message});
}
}

Можно ещё подключить класс IziToast который в ванильных скриптах есть и установить его значение как значение miniShop2.Message

Делать фильтры по JSON крайне неэффективно, работать они будут неточно. На вашем месте я бы скриптом заполнил данные для Tagger и сделал как положено. В текущем варианте нормальную фильтрацию вы не сделаете.

Если это тэги в блоке, то почему бы просто не использовать Tagger?

В исходном коде при успешном оформлении редирект происходит, причём на сервере.

Она решается за пару минут, редактированием одной строки.

Как-то это все грустно, «старики» оперативно покидают разработку под modx, а есть ли достойная смена?

Во-первых, minishop2 и msearch2 это разные компоненты и у них разные разработчики. Во-вторых, запрос нужен всего один — получить ассоциативный массив и записать его в плейсхолдер, если конечно ты используешь Fenom

А, погоди, тебе в фильтрах же надо, тут есть фундаментальная проблема: в значения фильтров попадает название цвета, т.е. тебе нужно получить список названий со списком значений и из этого массива по названию получать значения.

Можно посмотреть как он в базе хранится. Или спросить у @Алексей Смирнов

Самостоятельно надо прикрутить этот функционал

Делать запрос на сервер с id заказа и получать нужные данные.

Бесполезно, только если нет аргументов. Оформление заказа в модальном окне нужно чтобы ускорить процесс, а если нагружать его выбором способов оплаты и доставки, расчётом стоимости доставки, то весь смысл теряется, а процесс разработки усложняется.

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

{foreach $items as $item index=$i}

где $i это номер итерации.

Сервис рассылки вы выбираете самостоятельно и отправку данных в него пишите самостоятельно.

{if ($idx | resource: 'published') == 1}

idx это как правило порядковый номер, лучше переименуй в id

А зачем выносить полноценное оформление заказа в модалку?

По сути всё правильно, может не очень быстро, но при небольшом количестве товаров это будет незаметно.