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

Артур же вам ссылку скинул. читали?

Так а как получить весь HTML?

[migxResourceMediaPath]: docid could not be determined.

Явно где то тут косяк)

Так вон, на скрине прописал по дефолу)

В uploads_files есть mp4?

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

Конечно можно.
просто берете и дописываете:

{include 'test' param1='asd' param2='cvb'}

А можно ли вызывать чанк с параметрами если вызов выглядит так:

{include 'test'}

Те не менее, как это сделать?
+ Какая фактически разница будет между выполнение кода сниппетом и плагином?

Это как минимум логически неверно. Нужен не сниппет, а плагин на cобытие OnWebPagePrerender

<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_control" value="">
</div>
</div>

Вешаешь на chetest обработчик события change, если хотя бы один из чекбоксов выбран в chetest_control записываешь 1, если ни один не выбран 0, после этого делаешь так

$('[name="chetest_control"]').trigger('change');

И валидируешь chetest_control. По-другому чекбоксы валидировать нельзя, т.к. если чекбокс не выбран на сервер ничего не передаётся, я попробовал обойти, но нет до AjaxForm всё равно не доходит сообщение об ошибке и вообще информация о том, что есть какой-то там чекбокс.

Не секрет.
Думал сделать подстановку ссылок по регуляркам в статье, что-то типа перелинковки: если на странице есть слово такое-то, то обрамляем его ссылкой. Помимо основного контента (статьи) на странице могут быть ссылки в сайдбаре, к примеру, или же в других местах. Хотел получать весь сгенерированный текст страницы в сниппете и делать проверку на наличие в нем искомой ссылки для подстановки. Если ссылка уже была бы в коде страницы, то ссылку не добавлял бы в текст статьи, чтобы не было дублей. Вот такая схема.
Подумав, мне кажется, что генерация всей страницы в сниппете при рендеринге страницы — слишком накладная операция. Или нет?

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

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



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

Делал так:
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[]

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