А если не секрет — зачем?

Да, согласен. Не заметил сразу, дублируется марка при использовании этого скрипта.



Может кто-то подсказать почему так?

Делал так:
1) Создал объект с марками и моделями

var carsModelsObject = {
    "Alfa Romeo": {
        "146": [],
        "147": [],
        "156": []    
    },

    "Audi": {
        "80": [],
        "90": [],
        "100": [],
        "A2": [],
        "A3": [],
        "A4": [],
        "A5": [],
        "A6": [],
        "A6 Allroad": [],
        "A8": [],
        "Q2": [],
        "Q3": [],
        "Q5": [],
        "Q7": [],
        "TT": [],
        "V8": [],

    },
// и так далее по всем маркам...
}

2) Сам скрипт

<script>
      window.onload = function() {
        var carSel = document.getElementById("msoption|marka_0"); // мои названия опций
        var modelSel = document.getElementById("msoption|model_0"); // мои названия опций
    
        for (var x in carsModelsObject) {
            carSel.options[carSel.options.length] = new Option(x, x);
        }
        carSel.onchange = function() {
    
            modelSel.length = 1;
          //display correct values
          for (var y in carsModelsObject[this.value]) {
            modelSel.options[modelSel.options.length] = new Option(y, y);
          }
        }
      }
    </script>

Скрипт отключаю, дублирование пропадает) Может подскажет кто-то, что в нем не верно?
Спасибо!

Может и поздновато), но тут же тогда отлично подходит скрипт из документации
(так как название модели начинается на выбранную марку)
docs.modx.pro/komponentyi/msearch2/tipovyie-resheniya/zavisimyie-filtryi

Да с этой статьей уже знаком, и там в первом абзаце пишут, что EAV это про универсальность, а нам по сути это и нужно, угадать какая точно архитектура будет нужна конкретному магазину нереально, EAV как коробочное решение будет решать задачу универсально, пусть и не самым эффективным образом. А если продумать и заложить возможность полной замены реализации хранения и привязки опций — это даст ещё больше удобства, просто берешь отключаешь коробочное решение, и включаешь своё — но сомневаюсь, что многие этим будут пользоваться, моя статистика показывает, что там где уже есть EAV — мало кто пытается заменить на более производительное решение, так как хватает с головой коробочного. Но если речь про многомиллионные ассортименты и просто нереальное количество опций — то я думаю тут просто не падет выбор на MODX, как на платформу в целом.

Спасибо. Очень полезное мнение.
Насчет EAV правда не уверен.
Во первых опции и так почти по этой модели выстроены. Сущности опций привязаны к категориям, которые в свою очередь определяют какие опции будут доступны у товаров.

Во-вторых полезность EAV сильно спорна и сейчас на рынке наоборт наметилась тенденция отказа от такой модели.
Например Magento перешли к flat таблицам.

Вот хотя бы Хабр можно почитать

Здорово, что ребята находят силы и время развивать продукт, спасибо им за это! Но чтобы компоненту хоть немного приблизиться к профильным решениям на рынке Ecommerce, его реально надо ставить на коммерческие рельсы и открывать обсуждение функционала в широкие массы, как и сбор средств на его развитие. Чтобы я хотел видеть в ecommerce решении для MODX из коробки:

1)Хоть какой-никакой адекватный функционал управления заказами из админки, я имею ввиду, возможность создавать заказы, печатать документы по ним, адекватный пересчет всех параметров заказа (состав, доставка, оплата, скидки), также нужен минимальный функционал выйти на связь с клиентом, хотя бы через отправку E-mail. Сегодня чтобы это реализовать нужно поставить минимум 6 дополнений, которые сломают интерфейс окна заказа, так как каждое добавляет свои поля и настройки в extjs как попало, потому что нет регламента расширения интерфейса окна заказа. Приходится лезть в исходники extjs этих компонентов и переписывать их.

2)Заложенная в коробку и продуманная система скидок/подарков/бонусов — это ключевой блок, на котором разработчики смогут зарабатывать на своих дополнениях. То, что сейчас есть, куча дополнений, где каждое считает несогласованно с другими — это проблема плохой архитектуры. Один компонент переписывает напрямую сессию, второй пытается через методы пересчитывать, в итоге один перебивает расчеты другого — полная вакханалия. Нужен четкий интерфейс для дополнений, чтобы их можно было выстраивать в логические цепочки для конечного расчета заказа. Кому-то нужно сначала применить промокод, а потом скидку от суммы, а кому-то наоборот, это должно решаться простейшим изменением порядка срабатывания и желательно не завязанного на приоритет плагина компонента. Где-то видел, уже не помню на какой платформе, решение — раздел скидок сделан в виде цепочки, куда можно перетягиванием добавлять узлы (компоненты скидок, промокодов, бонусов) — и прям мышкой можно настроить их порядок срабатывания и другие условия совместной работы, типа установка пороговой суммы при которой следующий узел будет активным. Это самое удобное решение из всех, что я видел)

3)Сосредоточиться на API, если будет полное покрытие функционала на API, это даст просто нереальную свободу, будут писать и собственные админки для менеджеров в виде пакетов на всяких Vue.js и React.js и дополнения смогут использовать всю мощь API, вместо того, чтобы придумывать свои велосипеды. Я считаю, что если магазином можно будет пользоваться на полную, просто сидя в том же Postman и посылая запросы — это будет победа и залог на хорошие перспективы развития. Не сделать это на старте — будет ситуация как с текущим miniShop2, тонны дополнений, где часть ломает работу магазина, из-за того, что не поспевают за обновлениями базы, и часть, где царит велосипедостроительство, так как нет API и четких интерфейсов. Как итог, с последней версией miniShop2 адекватно работают, на моей практике из всего modstore, ну компонентов 10-15, и то если их допилить.

4)По поводу опций товаров — я надеюсь, что ребята используют EAV для архитектуры, так как это самое популярное решение сейчас во всех топовых Ecommerce продуктах. Ну и да систему фильтрации хорошо бы тоже иметь из коробки, это неотъемлемая часть любого интернет-магазина, странно было бы видеть этот функционал отдельным компонентом вне коробки, хотя чего удивляться, сейчас он вообще в компоненте поиска по сайту запилен (mSearch2)

5)По поводу финансирования разработки — однозначно нужно завести всякие «бусти» для донатов, но чтобы деньги пошли, нужна мотивация, а для этого нужно что-то показывать, прогресс, демо, видосы, больше деталей, классная дока. Всё это в сумме может дать необходимую мотивацию поддерживать проект, а редкие посты в сообществе о том, что ну процесс идет, нужны деньги — так себе мотивирует) Без обид. Я сам готов поддерживать проект и финансово и идеями, так как у меня довольно много интернет-магазинов в разработке и на поддержке, правда всё меньше на MODX, но хочется верить, что ситуация исправится. Готов поддерживать при условии, что буду видеть прогресс и развитие.

Так понимаю, что реплейс

key = key.replace(/[\[\]]/g, '');

должен был заменить вхождения ключа chetest[] (с квадратными скобками) на ключ без квадратных скобок. Даже если бы эта регулярка сработала, то возникла бы следущая проблема — с проставленной галкой в checkbox при повторном нажатии Отправить — появляется уведомление об обязательности поля, мол галка не стоит.

Корректным вариантом, имхо, будет что-то подобное:

key = key or key[]

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

К сожалению,

key = key.replace(/[\[\]]/g, '');

не дало результата. Фиксирую прежнее поведение: селект, инпут(текст) и текстареа — уведомление исчезает, у чекбоксов и радио — не исчезает.

Скорее всего вот так должно работать:

$(document).on('keypress change', '.error', function () {
            var key = $(this).attr('name'); 
            key = key.replace(/[\[\]]/g, '');
            $(this).removeClass('error');
            $('.error_' + key).html('').removeClass('error');
        });

Сегодня в чате наоборот было жаркое обсуждение о том чтобы побольше платных компонентов засунуть в базовый комплект магазина.
Договорились до того что хотят поиск и фильтр сразу в бесплатном комплекте иметь.
А ты говоришь

Да сделаем

Я бы сделал платной всю часть которая касается корзины и оплаты. Каталог товаров оставить базовым бесплатным.

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

замутите patreon / boosty, я бы подписался

Мне кажется, в этом случае, проще было бы дать чекбоксам разные имена и добавить кастомный валидатор, который при сабмите проверял бы, заполнен ли хоть один чекбокс. И если нет, то выводил бы предупреждение

Конструкции типа [[!+fi.error.chetest]] используются для formit без ajaxForm.

Не знал об этом, исключил эту конструкцию.
Спасибо за информацию!

Нее, тут идея следущая: можно выбрать 1 вариант, а можно и оба(вариант1+вариант2) = поэтому чекбокс, а не радио.

Насколько понимаю, причина в специфике указания имени для чекбоксов и радио, а точнее name=«chetest[]» != name=«chetest». В AjaxForm идет проверка и из-за [] чекбоксы и радио проверку не проходят, и поэтому уведомление не исчезает.

Пробовал доработать строку в default.js:

$(document).on('keypress change', '.error', function () {
            var key = $(this).attr('name'); 
            $(this).removeClass('error');
            $('.error_' + key).html('').removeClass('error');
        });

заменив var key = $(this).attr('name'); на var key = $(this).attr('id');
или var key = $(this).attr('name'); на input[type=«hidden»][name="' + chetest[] + '"]
Понимаю, что мои попытки ничтожны.

Я не совсем понимаю логику — почему у разных чекбоксов один атрибут name? Да ещё массив… не говоря уже про одинаковые id. Если нужно выбрать в форме какой-то один вариант из двух, то здесь радиобаттоны нужны, не?

Конструкции типа [[!+fi.error.chetest]] используются для formit без ajaxForm.

Вот рабочий вариант для одного чекбокса:

<input type="hidden" name="q_agree" value="">
<div class="form-b__field form-b__field_full">
    <input type="checkbox" name="q_agree" class="checkbox" id="politic" value="1" checked="">
    <label for="politic"><a href="politika-konfidenczialnosti">Политика конфиденциальности</a></label> 
    <span class="error_q_agree"></span>   
</div>

скрытый инпут нужен для проверки на пустоту, иначе required-валидация пропустит. А спан с классом error_q_agree как раз и отвечает за вывод ошибок (класс строится из строки 'erorr_' + имя поля)

<form action="[[*id]]" method="post" class="ajax_form af_example" enctype="multipart/form-data">
<div class="form-group">
<label for="chetest">Поле checkbox <span class="required">*</span>:</label>
<div class="controls">
<span class="error_chetest">[[!+fi.error.chetest]]</span>
<span><input type="checkbox" name="chetest[]" id="chetest" value="Вариант1" [[!+fi.chetest:FormItIsChecked=`Вариант1`]]>Вариант1</span>
<span><input type="checkbox" name="chetest[]" id="chetest" value="Вариант2" [[!+fi.chetest:FormItIsChecked=`Вариант2`]]>Вариант2</span>
<input type="hidden" name="chetest[]" value="">
</div>
</div>