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

Потому что не будет проблем с обновлением MODX

С этим компонентом ничего особо не планируется. Если есть желание профинансировать какие-то доработки — мои контакты в профиле.

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

Для редиректа в MODX существует метод SendRerdirect

//1 - это номер страницы куда нужен редирект
$url = $modx->makeUrl(1);
$modx->sendRedirect($url);

По идее этого наверное и достаточно в вашем сниппете.
Пардон — а вы знаете что такое сниппет?

Читаем документацию. ChangePassword имеет параметр postHooks — где можно перечислить скрипты, выполняемые после завершения основных действий. Под хуками-скриптами понимаются сниппеты. Пишите сниппет с нужным вам кодом, и указываете его в параметре postHooks
Как сделать редирект встроенными возможностями MODX вы понимаете? Какой код сниппета писать понимаете?

Да и не нужно кому то предоставлять доступ к своей машине. Сделал изменения — отправил ветку руководителю проекта. Он уже у себя ее протестирует.
Я обычно больше переживаю за синхронизацию баз данных, системных настроек, лексиконов и всего того что вынужденно находится в базе.

Можно потренироваться делать пулл-реквесты на docs.modx.pro.
Вчера буквально видел в документации office битые ссылки. Нужно их заменить на рабочие и сделать PR.

Схема ровно та же, что описана ниже. Я у себя локально на машине запускаю dev-сервер где веду разработку. Все что нужно тестирую — делаю коммит в отдельную ветку гита. Далее делаю PR руководителю проекта, который сливает изменения к себе, проверяет работу и если его все устраивает сливает все с мастером.
Все приведенные выше «Проблемы» — надуманы.
Маленький накопитель? Ну поставь побольше, какие проблемы то. Подключи внешний накопитель, Заведи себе отдельный компьютер в конце концов.
Нанимаемых разработчиков уговаривать не нужно. Нужно предоставлять рабочие машины. Это факт. Либо ставить перед фактом.
Вывести проект на локальной машине в сеть не так то просто? Серьезно? Это решается одной записью в hosts. Даже если я упрощаю то все сводится к готовым описанным в документации решениям.

А что мешает разработчику запустить dev-сервер у себя на локальной машине?

Еще не довольные. Все примеры вызовов через jQuery написаны.

как оказалось в pdoMenu команда &checkPermissions=`list` выполняет нужные функции:

Не в pdoMenu. Ты немного в заблуждение вводишь, или сам не разобрался еще. Это единый общий параметр всего семейства pdoTools. Работает во всех сниппетах и, по идее, должен работать во всех компонентах, которые используют в своем ядре класс pdoTools

Интересный плагин, первый раз вижу. Спасибо за наводку.
А он только готовый массив данных преобразует, или как нормальная пагинация может сходить на сервер за новой порцией данных?

Все 100 методов, количеством которых вы не довольны, находятся НЕ непосредственно в JQuery объекте, который вы получили в результате выборки, а в его прототипе. А это означает, что если вы создадите 100 таких объектов, они все будут ссылаться на один прототип.

Почему тогда. если распечатать объект в консоли, он распечатается как объект с Персональными свойствами. Прототип у него обычный — object.
Как по мне — я вижу на экране не наследование, а большой объект с копией всех свойств.

Я кстати и не спорю — а скорее сам разобраться пытаюсь.

Да легко. Распечатай в консоли и сравни два вызова одного и того же DOM-элемента. Посмотришь насколько более загруженный стал элемент если его создали через jQuery вызов.

let $element = document.querySelector('.class_element');
let $element = $('.class_element');

К примеру в свойства узла добавлены всяческие onclick, onmouseover и десятки других возможных событий. И не важно используешь ты их или нет.
Распечатать обычный JS узел кстати не удастся, потому что отдельный его экземпляр не создается в принципе. Тебе будет выдана ссылка на DOM-element, без хранения его в памяти.
А чтобы добавить событие в JS узел — нужно писать addEventListener.

Вот не поверишь — встречаются индивиды.
Буквально на днях установил человеку скрипт на чистом JS. А он мне жалуется что не работает.
Я ему говорю может кэш браузера, попробуй другой, попробуй почисти, а он мне начинает рассказывать что на трех компьютерах попробовал и везде не работает. И через час мы все таки выяснили, что у него на всех трех компах XP стоит, на который даже хром давно не обновляется. Ну и классика жанра — IE.

Ну тогда

{$_Всем_MODX}

А может активно живет и свой хлеб отрабатывает. Больно хвалит Лекторию именно в момент запуска

Раз уж зашел холивар про jQuery позволю и я себе вставить свои пять копееек.
Давайте немного структурируем информацию и разберемся, почему и зачем сейчас все отказывются от jQuery.
Что это? Дань моде? Да здравствует Ванильный JS?
Да вот нет. Причин на самом деле две. Одну из них выше упомянули. Использование в компоненте jQuery — это лишняя зависимость для проекта в целом.. Да скорее всего он и так подключен. Тот же miniShop2 до сих пор требует jQuery. Кстати совсем немного. Скрипты минишопа написаны на чистом стареньком JS пятой версии. Но в нескольких местах пока еще используется jQuery. При желании можно переписать и отказаться от зависимости.

Вторая причина, которой я здесь в обсуждении не увидел это дополнительная нагрузка на память. Дело в том, что jQuery сильно нагружает используемые DOM-элементы собственными свойствами и методами. Грубо говоря, добавляя под сотню (не считал) свойств в каждый используемый элемент. И это все висит в памяти, чтобы браузер в любой момент мог использовать все дополнительные методы каждого элемента.

Современный веб — он же про оптимизацию и быстродействие верно? Так что приходится избавляться.

Давайте также до кучи разберем почему вообще jQuery получил такую популярность исторически.
Причин собственно так же две. Начну с конца.
Во-первых, jQuery дал возможность использовать короткие вызовы для различных популярных действий. И это частично по прежнему актуально. Те же методы show(), hide(), classToggle() и тому подобное все еще короче, чем то же самое на чистом JS. Но напоминаю эти методы и еще куча других нагружают узлы DOM дерева, независимо от того пользуетесь ли вы ими.

Во-вторых кроссбраузерность. Раньше у каждого браузера были свои собственные движки JS, которые по разному реализовали те или иные возможности. Либо вообще не реализовали. Jquery давал возможность не задумываться для какого из браузеров пишется код. Магия внутри преобразовывала все как надо. все изменилось с приходом на рынок Chrome и его движка для рендера JS V8. Он получился насколько качественным, что его стали использовать и другие браузеры, и даже портировали в NODE JS. и даже те браузеры которые не стали его использовать — все равно волей неволей стали подстраиваться под лидера рынка. Таким образом от проблем кроссбраузерности мы практически избавились и для решения этой проблемы jQuery стал не нужен.
Ну и не нужно забывать что движок JS и сам упрощается. Все ранее недоступные или сложные возможности становятся все проще и доступнее.

Надеюсь такой мини-ликбез будет кому то полезен. Спасибо.

У тебя всегда доступен объект $modx->resource
Пиши условие, проверяй у него content_type или как там, не помню сейчас на лету.

Ну… приходится иметь дело с тем, что предложили авторы. Моя задача была показать основные принципы работы из коробки.
Посмотрим — может получится реализовать вариант OpenAPI. Но вообще вряд ли.
Проще подготовить собственную надстройку к MODX, по-моему.