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

Так вроде пофиксили эту проблему в 3.0.4

Дорожная карта состоит примерно из фразы «надо сесть и сделать» )
Проблема в том что это сотни часов работы, которые никто в одиночку не может себе позволить.
Потому я в каждом посте призываю помочь финансово, чтобы была возможность не думать о заработке, а поработать на благо сообщества.

Что там пилить. Генерируешь произвольную строку пользователю. Отдаешь на фронт.
Теперь фронт каждый раз при авторизации подписывает запросы токеном. На базе него происходит проверка прав и выдача ответа. В отличие от куки — токен можно быстро, массово отозвать, сменить и так далее.

Согласен работа с токенами — самый простой и достаточно надежный способ авторизации через API
Его очень легко реализовать для MODX.

Никак. В тексте опечатка. Подразумевалось каждую минуту.
Посекундного запуска крона не бывает.

Совсем не об этом писал. В этом варианте VUE все равно внутри шаблона подключается.
Я использую VUE CLI. В таком варианте — в шаблон вообще ничего не подключается. Только JS файлик, в котором скомпилированная логика. JS смотрит в DOM дереве заранее указанный ID и заменяет этот DOM элемент на VUE компонент.

Виджетами я называю отдельные модули. По отношению ко VUE наверное так никто не говорит действительно. Но в целом называть какой то отдельный кусок интерактивного кода виджетом — нормально. Во VUE наверное корректнее писать компоненты.
В более менее крупном проекте может быть запросто десяток подключаемых VUE компонентов. У меня порой страница целиком — один большой VUE компонент.

Как работаю я, когда мне нужно вставить виджет VUE внутрь MODX

Использую VUE CLI с компонентами
Создаю отдельный проект. Страницу index.html забираю с сайта, чтобы иметь нужный дизайн, со всеми стилями и скриптами.
Далее готовлю нужный мне VUE виджет. Компилирую бандл, и получившийся JS файл добавляю в MODX проект.

В шаблоне MODX — там где должен быть виджет пишу

<div id="vue-widjet-one"></div>

А VUE распознав ID заменит этот блок на подготовленный виджет.

Я обычно на доноре делаю скрипт, который складывает требуемые данные в json файл.
А сайт-приемник просто в удобное время читает этот json и парсит данные.

Хорошо бы. Пора все под MODX3 переводить.

$response = $modx->runProcessor('security/login', $data);
        if ($response->isError()) {
            $modx->log(modX::LOG_LEVEL_ERROR, print_r($response->response, 1));
        } else {
            //User отдельно необходим потому-что процессор не возвращает юзера и не присваивает его автоматом объекту $modx->user
            //В данном случае нет смысла дополнительно проверять права, потому что процессор уже все проверки провел.
            $user = $modx->getObject('modUser', array('username' => $username));
            if ($user) {
                $modx->user = $user;
                $modx->initialize('mgr');
            }
        }

Володя не заходил сюда уже почти год. Вряд ли он вам ответит.

ага

Судя по ошибкам у вас идет обращение к не найденному компоненту modFormCustomization — вы о таком знаете? Существует он на сайте?

Код нужно помечать специальным тэгом для лучшей читаемости

Имейте в виду, что во время ближайшего обновления, эти строчки затрутся.

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

• Не у каждого компонента есть достоверное описание, не всегда понятно для чего он, что умеет, где можно применить и какую пользу получить
• Не о каждом компоненте есть более менее приличная заметка здесь. Не удивлюсь если о половине вообще ничего не написано, или написано очень кратко
• Какие-то компоненты заброшены, и есть смысл составить список тех, чье обновление требуется
• По каким то компонентам здесь на форуме много заданных, мало раскрытых вопросов. Можно составить контент-план по раскрытию вопросов. Необязательно самому писать. Для начала можно просто составить список тем, которые было бы неплохо раскрыть. Уверен ребята заметят активность и подключатся

Хм. При такой бизнес логике реализация имеет смысл. Но из коробки ее нет. Я даже не слышал, об упоминании подобного решения.

Я всегда рассматривал связь по аналогии modUser + modUserProfile

Готовится. Сегодня будет

На самом деле, при глубоком погружении оказалось, что этот issue и вызвал поломку.
Связь Заказа и Адреса сделана довольно странно. Обычно Подчиненную модель (Адрес) привязывают к первичному ключу Главной модели (Заказа). И тогда Композитная связь работает очень хорошо.

В минишопе Василий же, в свое время почему-то сделал наоборот. Здесь Адрес является основной записью, к которой привязывается заказ. Решение мягко говоря спорное.
И я не могу переделать, потому что придется менять структуру полей. Это мажорное обновление, ломающее работу сайтов и компонентов. Внесу в план работ на будущее.

Пока откатываю реализацию твоего issue назад и будем решать удаление адреса заказа костылями.