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

В первой версии интерфейса не будет и он будет бесплатным. Как только появится интерфейс — станет платным.
А в целом, я делаю компоненты для разработчиков, потому как считаю, что каждый должен заниматься своим делом: разработчик — разрабатывать, заказчик — заказывать:-) К тому же SendIt можно прикрутить интерфейс на Migx, пример есть в доке, но мне как разработчику удобнее с файлами работать, а заказчику зачастую надо всё на одну почту слать. Вот и зачем ему интерфейс? С фильтрами, конечно, другая история, тут админка нужна и она будет, но сначала надо обкатать компонент. Учитывая активность сообщества, чем раньше я выпущу компонент, тем быстрее его обкатают. А разработка админки займёт много времени, так как я хочу её на Vue сделать, с ним я знаком мало.

В логах сервера должна быть ошибка.

Думаю это связано с тем, что фильтры работают в два этапа. На первом происходит фильтрация и возврат результатов. На втором — поиск недоступных для выбора значений. Изначально всё делалось за один запрос, но тогда ответ приходил через 1.5-2 секунды.

Ничто там непонятного? Вот был у тебя вызов

{'!AjaxForm' | snippet: [
'validate' => 'name:required,phone:required',
'successMessage' => 'Форма отправлена!',
'hooks' => 'email',
'emailTo' => 'some@email.ru',
'emailTpl' => 'defaultEmail',
'form' => 'defaultForm'
]}

Ты копируешь в файл core/components/sendit/presets/sendit.inc.php

return [
    'default' => [
        'validate' => 'name:required,phone:required',
        'successMessage' => 'Форма отправлена!',
        'hooks' => 'email',
        'emailTo' => 'some@email.ru',
        'emailTpl' => 'defaultEmail',
        ]
]

А вместо вызова сниппета вставляешь саму форму, которой добавляешь два атрибута data-si-form=«defaultForm», data-si-preset=«default». Всё форма работает. Согласен непривычно, но ничего сложного. Возможно стоит в доку добавить раздел Миграция с AjaxForm.

А по фильтрам, там SendIt идёт как зависимость, но сниппеты будут вызываться классическим способом)))

Начнем с того, что mfilter хоть и оптимальное решение, но сама схема таблиц такова, что при большом количестве товаров, даже с отключённой агрегацией, фильтры работают медленно. Кстати в моем компоненте агрегации нет, я ей никогда не пользовался и практический смысл её весьма сомнительный, но не суть. Ничего гениального я не придумал, принцип работы остался тем же: выбираем по каким полям фильтровать, выводим эти поля на фронт фильтруем. Разница только в том, что значения для фильтрации заранее собираются в отдельную таблицу(для маленьких сайтов) или в несколько таблиц(для больших). Что касается раздувания БД, то в текущей реализации у меня к 100К товаров 170К индексов(так я называю собранные для фильтрации данные). Если злоупотреблять опциями с множественным выбором, то можно конечно таблицу раздуть знатно. Опять же, это уже вторая версия, в первой индекс строился иначе, и там в БД было больше миллиона записей, однако запросы отрабатывали менее чем за 1сек, и если бы не проблема с невозможностью фильтрациии по множественным знаниям, я бы схему индексации менять не стал.

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

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

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 заказа и получать нужные данные.

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