19 апреля 2012 сама MODX в «Bringing Evolution Development Back to Life» написала: push-доступ у нескольких человек, а *«with the current workload of the MODX Team, it also serves as a barrier. That must change!»* Решением тогда назвали не форк, а Integration Manager, выбранного сообществом, с push-доступом в официальный репозиторий — *«handing over the keys to the Community ASAP»*.
23 января 2013 готовый фикс XSS в FormIt ушёл PR'ом — к 17 марта ноль реакции, а в середине марта баг подтверждён как всё ещё присутствующий в релизе. 14 ноября 2016 MODX выпустила security-релиз 2.5.2 и официально поблагодарила bezumkin, Fi1osof, Mark-H, AgelXNash и chengruiqi; в том же треде член security team написал: *«We took too long to respond to your initial email, and I'm sorry for that»*. 2 сентября 2026 сообщество снова пишет открытое письмо с тем же диагнозом: вклад есть, люди есть, процесса, превращающего их в решения, нет.
Между этими точками — наш собственный опыт: параллельные сборки, а затем в 2016 MODX сама передала Evolution команде сообщества — опять её же словами, «handing over the keys»; Evo 2.0 вышел в 2018, репозиторий позже осёл в evocms-community. Две экосистемы, два рынка дополнений, две документации и миграция, которая пережила все споры, её породившие. Мы проходили этот цикл изнутри.
Вывод простой: когда единственный способ превратить работу в решение — построить отдельный продукт, контрибьюторы не объединяются, а фрагментируются. И платит установленная база.
Поэтому предлагаю не ждать очередного ответа официалов и не плодить конкурирующие ветки, а вернуться к совместной разработке — под новым брендом, который не принадлежит ни одной компании и ни одной национальной группе (включая modx.pro и включая нас).
Что кладём в основу:
— опыт Evolution CMS: сопровождение большой установленной базы и модернизация в условиях обратной совместимости, включая работу на базе Laravel-компонентов;
— практики экосистемы Laravel: пакеты, контракты, service container — современный PHP без изобретания собственного велосипеда;
— архитектурные идеи следующего поколения, которые давно обсуждают Философ и другие: API-first, отказ от ExtJS, чистое ядро.
С одним правилом, согласованным заранее — два трека:
— Трек A — эволюция с обратной совместимостью: безопасность, современные версии PHP, DX для существующей установленной базы.
— Трек B — прогрессивный трек без ограничений совместимости: чистая архитектура проверяется прототипами, а не манифестами.
Governance с первого дня: мейнтейнеры зарабатывают права историей вклада, зоны ответственности ограничены, RFC публичные, правила передачи и отзыва прав прозрачны. Если у официалов появится реальный процесс — интеграция на столе; срок 30 сентября — это срок для MODX, не для нас. Но после четырнадцати лет одного и того же цикла сообщество, которое все эти годы тащило проект на старой памяти, обязано само себе дать работающую альтернативу.
Мы больше не ждём разрешения. Название, как и всё остальное, выберем вместе. Кто с нами?
MODX Evo/Revo Сейчас привлекает многих тем, что можно использовать чужие наработки без проблем. А с новой админкой что? Опять проходить все круги ада — Tickets, miniShop и бла-бла-бла… Думаю это никому не нужно будет. Но, как бы не хотелось чего-то новенького да удобненького, большинство все равно будет пользоваться стареньким и привычненьким.
Опыт Evo тому пример. Я лично выступал инициатором реноваций, но всегда это заканчивалось неудачей. И так продолжалось до тех пор, пока я не написал 100% совместимый шлюз от DBAPI в Eloquent. Дальше стало проще — бек можно развивать вместе с админкой, но энтузиазма лично у меня уже не осталось.
github.com/maksatweb/compressor.io-php по крону натравите на папку. Ну или разработайте более умный алгоритм с сохранением списка уже оптимизированных картинок. У меня еще ни разу не возникало ситуации, когда CompressorIO сделал картинку битой, увеличил размер или потерял в качестве.
Есть проекты, которые ограничены NDA. Какие-то проекты я даже не могу указывать в своем профиле как разработчик и за это в свое время была доплата, поскольку клиент параноик. Какие-то CRM системы я хоть и могу указать, но они приватные и доступны только через VPN.
Как я уже говорил, мне совершенно не интересно тебе что-то доказывать. Поэтому демонстрировать именно тебе проекты доведенные до стадии production у меня нет ни малейшего желания.
Я ничего не имею против топиков не связанных с modx на этом сайте. Но на мой взгляд, эти топки не должны выходить за рамки вольного пересказа возможностей других технологий. Иначе сайт превратиться из сообщества modx в помойку с набором несвязанных между собой технических статей. Один только топик про minecraft это верх профильности и информационной кладези. Можно я рядом создам топик про сервера для Counter Strike?
Когда PHP + JS разрабатывается одним человеком, то тут выбирай что хочешь. Но когда это разные люди или даже комманды. То GraphQL позволяет им работать независимо друг от друга.
В общем я не говорю, что REST это плохо. Я говорю о том, что когда твое API выходит за рамки 2-3 методов, то GraphQL способен упростить жизнь как при разработке, так и в поддержке.
Например, раньше я документировал API через raml.org
Мне казалось это верх удобства. Но сейчас в моем арсенале появился еще один инструмент.
З.Ы. Похоже тема топика уже более чем раскрыта. Всем спасибо за внимание:-)
Ну или возьмем пример из топика. Что сделал ТС? Он подцепился к API modx.pro который разработал Василий и завернул ответ в GraphQL. И тут напрашивается резонный вопрос, а зачем нам этот промежуточный слой в виде уже существующего /assets/components/extras/action.php, если у нас есть доступ к коду и можно сразу сформировать GraphQL
Единственное, где может пригодится пример из топика — API к каким-то сотороним сервисам, к коду которых нет доступа, агрегирование нескольких API в один и т.п. Но все это задачи частного порядка.
А теперь откроем официальный сайт graphql.org/code/ и увидим серверную реализацию GraphQL на C#, Go, Java, PHP, Python, Ruby, etc… Для PHP указано аж 2 библиотеки. И одна из них webonyx/graphql-php взята за основу для Railt, который по своей сути является лишь синтаксическим сахаром для официального серверного пакета.
Так что кем бы ни был придуман GraphQL, но кидаться в омут npm пакетов и изучать шаманство в JS еще совсем не обязательно имея на руках проект PHP.
19 апреля 2012 сама MODX в «Bringing Evolution Development Back to Life» написала: push-доступ у нескольких человек, а *«with the current workload of the MODX Team, it also serves as a barrier. That must change!»* Решением тогда назвали не форк, а Integration Manager, выбранного сообществом, с push-доступом в официальный репозиторий — *«handing over the keys to the Community ASAP»*.
23 января 2013 готовый фикс XSS в FormIt ушёл PR'ом — к 17 марта ноль реакции, а в середине марта баг подтверждён как всё ещё присутствующий в релизе. 14 ноября 2016 MODX выпустила security-релиз 2.5.2 и официально поблагодарила bezumkin, Fi1osof, Mark-H, AgelXNash и chengruiqi; в том же треде член security team написал: *«We took too long to respond to your initial email, and I'm sorry for that»*. 2 сентября 2026 сообщество снова пишет открытое письмо с тем же диагнозом: вклад есть, люди есть, процесса, превращающего их в решения, нет.
Между этими точками — наш собственный опыт: параллельные сборки, а затем в 2016 MODX сама передала Evolution команде сообщества — опять её же словами, «handing over the keys»; Evo 2.0 вышел в 2018, репозиторий позже осёл в evocms-community. Две экосистемы, два рынка дополнений, две документации и миграция, которая пережила все споры, её породившие. Мы проходили этот цикл изнутри.
Вывод простой: когда единственный способ превратить работу в решение — построить отдельный продукт, контрибьюторы не объединяются, а фрагментируются. И платит установленная база.
Поэтому предлагаю не ждать очередного ответа официалов и не плодить конкурирующие ветки, а вернуться к совместной разработке — под новым брендом, который не принадлежит ни одной компании и ни одной национальной группе (включая modx.pro и включая нас).
Что кладём в основу:
— опыт Evolution CMS: сопровождение большой установленной базы и модернизация в условиях обратной совместимости, включая работу на базе Laravel-компонентов;
— практики экосистемы Laravel: пакеты, контракты, service container — современный PHP без изобретания собственного велосипеда;
— архитектурные идеи следующего поколения, которые давно обсуждают Философ и другие: API-first, отказ от ExtJS, чистое ядро.
С одним правилом, согласованным заранее — два трека:
— Трек A — эволюция с обратной совместимостью: безопасность, современные версии PHP, DX для существующей установленной базы.
— Трек B — прогрессивный трек без ограничений совместимости: чистая архитектура проверяется прототипами, а не манифестами.
Governance с первого дня: мейнтейнеры зарабатывают права историей вклада, зоны ответственности ограничены, RFC публичные, правила передачи и отзыва прав прозрачны. Если у официалов появится реальный процесс — интеграция на столе; срок 30 сентября — это срок для MODX, не для нас. Но после четырнадцати лет одного и того же цикла сообщество, которое все эти годы тащило проект на старой памяти, обязано само себе дать работающую альтернативу.
Мы больше не ждём разрешения. Название, как и всё остальное, выберем вместе. Кто с нами?
Я сейчас о программировании на процессорах. Нужна новая админка — бери, да пиши.
MODX Evo/Revo Сейчас привлекает многих тем, что можно использовать чужие наработки без проблем. А с новой админкой что? Опять проходить все круги ада — Tickets, miniShop и бла-бла-бла… Думаю это никому не нужно будет. Но, как бы не хотелось чего-то новенького да удобненького, большинство все равно будет пользоваться стареньким и привычненьким.
Опыт Evo тому пример. Я лично выступал инициатором реноваций, но всегда это заканчивалось неудачей. И так продолжалось до тех пор, пока я не написал 100% совместимый шлюз от DBAPI в Eloquent. Дальше стало проще — бек можно развивать вместе с админкой, но энтузиазма лично у меня уже не осталось.
Если кому интересно, то вот реализация для artisan под laravel gist.github.com/AgelxNash/0b6faaa7978e3456f3cbd3ef06b365da
Но по теме ветки комментариев. Мы начали разговор за реальные кейсы на GraphQL. Я понимаю, что тебе тема безопасности не важна, на SEO срать и т.д. Но если твой девиз хуяк-хуяк и в прод, то есть разработчики/студии которые стараются выпускать все-таки качественный со всех сторон продукт. И именно им в первую очередь будет познавательно узнать о реальных кейсах, а не каких-то абстрактных типо агрегирования нескольких API в один.
Но даже разбирая реальные кейсы, вместо накидывая путей решений ты тыкаешь носом в свои обрывки кода, отправляешь смотреть проекты и наработки. Но при этом на конструктивную критику ни в каком направлении не принимаешь. Если бы мы обсуждали абстрактные пути решения, статьи с того же хабра, сторонние репозитории и т.п., то диалог мог быть бы абсолютно другим. Скорее всего, мы бы поговорили за подходы к реализации как там сделано и как можно по другому. Какие плюсы и минусы выбранных реализаций и т.д. Но нет, ты тешишь свое ЧСВ показывая именно свои нарабокти, но не готов их обсуждать в негативном ключе. При этом пытаешься ущипнуть меня тем, что я якобы ничего не способен реализовать. Но не задумывался ли ты о том, что
Столько лет прошло, а ты так и не осознал мысль, что если кто-то способен найти твои ошибки, то значит этот кто-то знает больше твоего. Да, это не всегда так. Иногда это говорит о невнимательности разработчика, но этот случай явно не про тебя. Уж очень часто ты диалог заканчиваешь фразой «до безопасности доберусь, когда действительно понадобится».
Но в будущем, я все-таки думаю у Railt-а хорошие перспективы, т.к. код без жесткой завязки на фреймворк. А это значит, что его можно брать за основу не только в Laravel.
В любом случае, если бы я раньше увидел этот топик, то давно бы тебе показал это youtu.be/xETUOC4M4m4
И если бы обошлось без визгов, то мы бы конструктивно поговорили на тему ограничения прав доступа в GraphQL запросах. Затронули бы тему раскрытия путей /var/www/modxclub.ru/modxclub-3.0/ и еще много чего.
— показать, что GraphQL это не серебрянная пуля. И на реальных проектах все может оказаться несколько сложнее.
— Очередной раз подчеркнуть, что разбирая тонкости какой-то технологий, мы все дальше углубляемся в лес.
Хотя, если бы мы обсуждали не абстрактную вещь в стиле «смотрите какая крутая штука есть. на ней можно делать то и се», а разбирали реализацию GraphQL хотя бы для modx_site_content + TV, то такой материал вызвал бы
— намного больше интереса в сообществе
— позволил бы углубиться в тонкости технологии с пользой для CMS и т.п.
Про Go запрос был шутки ради. Но на всякий случай оставлю это тут github.com/gopherjs/gopherjs
На мой взгляд, агрегирование нескольких API в один, это задача частного уровня. А вот права доступа более чем насущная проблема, которая будет интересна большему кругу читателей.
github.com/VadimDez/Counter-Strike-JS
и
Одно и то же разными словами.
А насчет углубления в документацию, соглашусь с комментатором из соседнего топика modx.pro/development/18727#comment-112808 тем более,
есть свое сообщество graphql.org/community/ и много мануалов в сети.
Я ничего не имею против топиков не связанных с modx на этом сайте. Но на мой взгляд, эти топки не должны выходить за рамки вольного пересказа возможностей других технологий. Иначе сайт превратиться из сообщества modx в помойку с набором несвязанных между собой технических статей. Один только топик про minecraft это верх профильности и информационной кладези. Можно я рядом создам топик про сервера для Counter Strike?
Когда PHP + JS разрабатывается одним человеком, то тут выбирай что хочешь. Но когда это разные люди или даже комманды. То GraphQL позволяет им работать независимо друг от друга.
В общем я не говорю, что REST это плохо. Я говорю о том, что когда твое API выходит за рамки 2-3 методов, то GraphQL способен упростить жизнь как при разработке, так и в поддержке.
Например, раньше я документировал API через raml.org
Мне казалось это верх удобства. Но сейчас в моем арсенале появился еще один инструмент.
З.Ы. Похоже тема топика уже более чем раскрыта. Всем спасибо за внимание:-)
В общем получается такая картина, есть язык запросов — GraphQL. А есть серверная реализация этого языка запросов. Схема в общем случае на выходе одна и не важно чем и как ты ее генерируешь.
Если мы берем за аксионму тот факт, что GraphQL это чисто JS, а проект на PHP, то реализация API потребует абсолютно другого технологического стека. И бизнес логика сервисного слоя будет дублироваться на двух языках. Это приведет к удорожанию стоимости всего проекта. Одно дело, когда мы берем данные в сыром виде из базы. Другое дело, когда уже добавляется какая-то логика.
Ну или возьмем пример из топика. Что сделал ТС? Он подцепился к API modx.pro который разработал Василий и завернул ответ в GraphQL. И тут напрашивается резонный вопрос, а зачем нам этот промежуточный слой в виде уже существующего /assets/components/extras/action.php, если у нас есть доступ к коду и можно сразу сформировать GraphQL
Единственное, где может пригодится пример из топика — API к каким-то сотороним сервисам, к коду которых нет доступа, агрегирование нескольких API в один и т.п. Но все это задачи частного порядка.
А теперь откроем официальный сайт graphql.org/code/ и увидим серверную реализацию GraphQL на C#, Go, Java, PHP, Python, Ruby, etc… Для PHP указано аж 2 библиотеки. И одна из них webonyx/graphql-php взята за основу для Railt, который по своей сути является лишь синтаксическим сахаром для официального серверного пакета.
Так что кем бы ни был придуман GraphQL, но кидаться в омут npm пакетов и изучать шаманство в JS еще совсем не обязательно имея на руках проект PHP.