Сергей Шлоков

Я бы всё-таки не стал рассматривать REST в реализации MODX. Мало того, что сам стандарт уже старый и ограниченный, так ещё и в MODX он хрен знает как поддерживается. Многие серверы по умолчанию отключают опасные методы. Как в этом случае реализовывать глаголы? Костылями как в Laravel? Есть смысл обратить внимание на JSON-API или OpenAPI, в которых решены многие проблемы REST.

По сравнению с другими у GraphQL сложнее порог входа. Нужно учить язык. JSON-API в этом плане проще. И масштабируемее. Можно начать с простого REST, а закончить сложными запросами. Есть ещё OpenAPI. В общем только выбирай.

Так мы вроде эту парадигму и обсуждали (и тут).
А по API что скажешь?

Какие есть предложения по API? RestAPI, JSON-API или GraphQL?

Константин, не шали. Прокляну! ))

CMPGenerator

По поводу последнй цитаты… Представляете уровень его самомнения? Он не фанат статических методов. Не нравиться, не используй. А кому то нравится. И что? Пшли на… Просто удивительно!

Ну я писал про свой PR. И именно в нём Джейсон и высказался наконец-то. Ибо в Слаке он тогда ответил «нафиг», а на просьбу объяснить просто забил.

Этот PR завязан на того же Джейсона. Требуется его благоволение, чтобы добавил. Да ещё и вопрос куда. В третью версию — значит выбросить в пропасть. А во вторую вряд ли добавил бы.
А идея с админкой — это альтернатива, которая полностью исключает необходимость обращения к этому товарищу. Это просто обычный компонент, но не совсем обычный. ))

Современные тенденции требуют использования модных JS фреймворков. И тут я полностью выключаюсь из процесса ибо я не дизайнер, не верстальщик и у меня нет большого опыта работы с Vue/React/Angular и т.п. фреймворками. Могу чисто языком поработать ))

По моему опыту скажу, что было бы отличным решением разработать, что сейчас делает Дмитрий Лукьяненко: Evo с Laravel.

Таких как Дмитрий в лагере Revolution не нашлось. Именно поэтому и был предложен более простой вариант. Но я не уверен, что даже этот вариант сообщество потянет. Это раз.
А в третьих, что там напилит Дмитрий покажет время. И если напилит. И то что получиться, думаю, будет интересно ему и ещё троим-четверым (не в обиду Дмитрию). И пока Revo не скатилась до уровня Evo нужно принимать срочные меры. Иначе через несколько лет его постигнет судьба младшего брата.

После публикации этого поста Марк обратил внимание на мой PR (@Иван Бочкарев приложил руку) с возможностью расширения класса modX, дающий разработчикам больше контроля над ядром, ибо можно создать свой класс приложения и не ждать милости от core-разработчиков. Марк высоко оценил данную возможность.
Но вот пришел главный и поставил жирную точку. Цитата:

I am not necessarily in favor of making the modX class itself more extensible, at least not in the current architecture. We already have too much flexibility at times.

Т.е. MODX и так слишком гибкий. Харэ.

I'm concerned that encouraging extensions to the modX class would open up a whole new set of problems and make upgrade paths even more difficult.

Каким боком разработчика ядра должно касаться то, что делает пользователь MODX, самостоятельно расширяющий систему. Твоя задача дать эту возможность, а дальше не твоя забота. Но нет, ни в какую он (Джейсон) не хочет давать контроль над ядром, даже на уровне пользователя.

I'm also not a fan of using static instance methods to retrieve MODX as a dependency. Dependencies should be explicit, in my opinion.

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

Ну что я могу сказать. Этот человек делает всё, чтобы MODX остался там, где он есть.

Это постхук должен быть.

Поавильно последний вариант. Только я бы использовал str_replace вместо parse. А в ифе вызови

log_error($content);

И посмотри, что в лог пишется.

«Ядро без дополнений… понятно, что не ядро...»

Как хочешь, так и понимай. Сколько лет MODX, а базового решения для апи нет. Сделать универсальное решение — большое дело. Хотя бы через компонент.

Он не завязан на бекэнд. Поэтому с ним меньше всего проблем.

Во первых, ещё ничего не делается. А во вторых, само ядро не трогается.

Задача как раз начинать не с ядра.

Вот тут и вылазит проблема завязки на специфичный бекэнд. Совместимости нет.

Главный продукт — минишоп. Начинать нужно с него.

Пока обсуждаем идею. Роудмап — следующий шаг.

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