Артур

Можно использовать 1 плагин на 2 события.

Вероятно я мы по-разному считаем количество плагинов))) А по поводу остального, это было моё предположение.

Так ты проверил, событие срабатывает?

Я бы сделал так. Перед добавлением товара в корзину (msOnBeforeAddToCart) проверял бы сколько товаров уже есть в ней, если 3 и больше обнулял стоимость, соответственно при удалении товара из корзины (msOnRemoveFromCart) делал бы аналогичную проверку, но возвращал товару с нулевой стоимостью его первоначальную цену. На всё это нужно два плагина, но возможно, я не учёл какие-то нюансы.

Если XParser создаёт ресурсы через процессоры, то скорее всего срабатывают системные события, значит можно попробовать на OnDocFormSave отменять публикацию.

Судя по вопросу Вам надо в документацию, поскольку и class_key и id это названия полей ресурса. Ну и да выше я написал плагин на событие OnDocFormSave

Не знаю как ты создавал дополнительные поля, но предположу, что по инструкции из сети, и тогда, скорее всего, данные сохраняются в поле properties в формате json, в этом случае можно из получить так

$extFields = json_decode($order->get('properties'),1); // в результате получишь массив

Во-первых, если ты укажешь несуществующий чанк письма, скорее всего ничего не придёт, а в логах будет ошибка о том, что ты пытаешься отправить пустое письмо.
Во-вторых, если ты не используешь Fenom, то именовать поля нужно так email1, email2 и т.д., а в чанке письма выводить так [[$email1]], [[$email2]] и т.д.
Если ты используешь fenom, то можно именовать так emails[], phones[], а в чанке можно выводить так {$emails[0]}, {$emails[1]}, {$phones[0]}, {$phones[1]} и т.д. Или именовать так fields[0][email], fields[0][phone], fields[1][email], fields[1][phone], а в чанке выводить так

{foreach $fields as $field index=$i}
{$field[phone]}
{$field[email]}
{/foreach}

$order = $modx->getObject('msOrder', $id);

Я не знаю, что за поле «Прежняя цена», но вот плагин для автоматического заполнения поля старая цена если новая цена меньше, той что была

<?php
if($resource->get('class_key') == 'msProduct'){
    $res = $modx->getObject('msProduct', $resource->get('id'));
    if($res->get('price') > $_POST['price']){
        $resource->set('old_price',$res->get('price'));
    }
}

Есть предложение выкинуть капчу и сделать так. Создаешь скрытое поле с именем например secret. В вызове в параметре validate пишешь secret:contains=^Bdsvgfdbr^ и пишешь js который при загрузке страницы или при попадании любого поля формы в фокус будет заполнять secret значением Bdsvgfdbr (любой набор символов).

Думаю нужно будет сделать как написано тут

У пользователя есть поле extended что по сути уже и есть поле migx, т.е. хранит данные в json. Если тебе нужно табличное представление данных, то можно создавать для каждого пользователя отдельный ресурс и указать этого пользователя создателем данного ресурса. А вообще, надо понимать какая именно задача стоит, возможно стоит создать свою таблицу в БД.

А что там сложного? Суммарно я дописал/изменил 50-60 строк кода, ну максимум 100, при этом основная логика создания заказа вообще никак не поменялась, что в теории позволит без проблем прикрутить оплату как это обычно делается в minishop2, и, вероятно, калькуляторы доставки, но как по мне это уже ни разу не заказ в 1 клик. А так да, можно и через FormIt. Вообще вариантов реализации можно придумать много, мне было интересно сделать меняя только js.

Не переключается, наверное, потому что Вы не переключаете. У msoptionprice2 есть событие

$(document).on('msoptionsprice_product_action', function (e, action, form, response) {
    console.log(action, form, response);
});

А в swiper есть метод swiper.slideTo(index, speed, runCallbacks)
Ваша задача в событии получить идентификатор модификации, по нему найти слайд и переключиться на него.

Я не призываю к этому привыкать, этот вариант годится только для очень небольших сайтов, например, как в моём случае для маленького имага чисто протестировать нишу. Если проект зайдёт, тогда будут подключаться дополнения.

Под быстротой я имею ввиду скорость создания поиска.
А сайт действительно до 100 страниц, если есть рекомендации по улучшению запроса, а именно как его переписать так, чтобы учитывался шаблон и чтобы он работал быстрее, буду признателен.
И да, я надеюсь query обрабатывается в pdoTools.

Вставлю свои 5 копеек. Кто не хочет интегрироваться с CRM, может создать отдельную группу пользователей, на bootsrap набросать несколько форм и таблиц, и вынести управление заказами на фронт. Все проблемы по пересчёту сумм, отправке писем, запрете на удаление заказов сразу же будут решены)))

Можно использовать AjaxForm + свой сниппет, в котором можно делать, всё что угодно.

Предполагалось что это будет сделано для людей без знаний html css, но потом мне подумалось, что слишком сложно, а если упрощать, то это уже конструктор, а их хватает. А вообще, может ещё запилю.

В общем, меня посещала идея сделать, аналогичный компонент, но с возможностью кастомизации блоков. Т.е. сам блок представляет собой постоянный набор элементов, например Заголовок, Подзаголовок, Кнопка и Картинка и каждый элемент можно немного кастомизировать, менять цвет, размер, тип шрифта. Как основу я использовал bootstrap, потому что там можно изменить глобально настройки всего фреймворка и сайт преобразится, а можно точечно классами менять внешний вид отдельных элементов. В итоге должен был получится недоконструктор сайтов. Но сейчас я думаю, что это никому нах не нужно)))

P.S. Настройки boostrap я выносил в clientConfig и при сохранении пересобирал sass. Хотел даже статью запилить, но подумал, что это никому не нужно)))