Николай Савин

Да по тексту стало сильно понятнее. Но по-прежнему не понятно зачем такой инструментарий использовать. Особенно при формулировке

используя минимум сторонних компонентов.

Куда более правильно было был написать малюсенький JS скрипт, который слушает форму, отправляет условные логин-пароль на сервер. А Сервер в свою очередь тоже, используя простенький PHP скрипт заводит запись в базе. Ну или логинит.

Зачем сюда подключать твои здоровенные комбайны, да еще форкнутые, ума не приложу. Это ж изобретение велосипеда, которых тут на форуме наверное с несколько десятков наберется.
Ты бы лучше свою деятельность направил на реанимацию ajaxLogin

Артур, ты если ради критики выкладываешь — то лучше бы это делать в разделе вопросы.
Раздел готовые решения предполагает собственно готовое решение. Причем понятное случайному посетителю (хорошо бы).
Я три раза перечитал текст, но так и не понял какую задачу ты решал, в чем ее решение, и почему это решение такое. Просто поток мыслей — без какой-либо цели.

Не знаю как насчет FormIT, но вот AjaxForm точно для MODX3 точно никто не обновлял.

Спасибо, примем меры

Добрые люди обычно в спасибо копеечку заворачивают )

Да — для MODX3 минишопа пока нет. Версия сейчас в разработке.

То есть ты не смог собрать компонент из исходника, а виноват MODX3?
Компонент для MODX3 лежит вот здесь
github.com/halftrainedharry/Gallery
Для сборки и установки компонента из исходника нужно запустить файл /_build/build.transport.php

В этом случае в процессоре нужно добавить выборку данных из дополнительной таблицы. Тогда они будут доступны как родные в JS

Вряд ли из-за прав. Скорее просто плагин не успевал выполнить задачу за доступное время. А в консольном режиме ограничения времени на выполнение PHP скрипта нет. Он может и неделю выполняться.

Ну для начала идея — не использовать для таких задач плагин.
Это некорректно с точки зрения архитектуры (плагин по своей сути это функция). А также плагин ограничен максимальным временем выполнения PHP скрипта.

Такие задачи выполняются в CLI режиме. То есть создайте отдельный php файл, подключите туда MODX, перенесите ваш код. Желательно переделать в класс и использовать ООП. И выполняйте код в консольном режиме.

А где связь? Никаких изменений связанных со списком товаров заявлено не было.
Обновление касается корзины и оформления заказа по большей части.

Это статья не про MODX3 а про minishop2.

Рекомендую использовать ZoomX для построения API. Текущая статья — устаревшая. Архивная я бы сказал

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

Вы здесь немного смешиваете понятия. Опция это Модель и Марка отдельно.
А то что внутри (список моделей, Список марок) — это значения опций.
Вам получается нужно дернуть из базы значения указанной опции. Верно? Так это совсем простенький запрос в базу ведь.

Позвольте вмешаться в ваш диалог.
Массив опций вывести без проблем можно. Это ведь обычные записи базы данных. Значит их без проблем можно оттуда забрать.
Готовых сниппетов для этого нет. То что есть, использовать сильно не рекомендую, даже если там есть какие-то отсылки к опциям.
Проще всего написать свой достаточно простой сниппет, забирающий нужные вам данные.
Для этого нужно уметь составлять XPDO запросы через $modx->newQuery (или хотя бы через SQL)

На первой вкладке отображаются данные из другой таблицы базы данных ms_orders. Соответственно желательно расширять эту таблицу, а не ms_order_address про которую речь в статье.

А неплохо вы тут сам с собой общаетесь

@Сергей Шлоков Обрати, пожалуйста, внимание на проблему.
@fred Oushen По-правильному вам нужно создать issue в репозитории компонента на github, в котором описать проблему с пошаговой инструкцией для воспроизведения проблемы.

Так он 17 года выпуска. Было бы странно если бы в 22 — он работал как надо