AdminRevolution. Быть или не быть?
Привет, друзья!
Есть тема для дискуссии. Как вы знаете, дела в лагере разработчиков MODX не очень. Если глянуть на список пользователей, то многие из топа уже покинули этот лагерь. Недавно сообщество потеряло главного амбассадора. Да и номер первый, как мы знаем, с MODX контактирует только на старых проектах. Конечно это удручает. Но такова жизнь. Так происходит везде. Это не ноу-хау MODX. Рынок разработки стремительно меняется. Приходят новые технологии, языки, подходы. Сайты становятся сложнее. Рынок простых CMS сужается. Конкуренция становиться жёстче. И тут MODX сильно проигрывает. Несмотря на то, что он не хуже Вордпресса, Джумлы и Битрикса, новых разработчиков он привлекает всё меньше и меньше. И это самое плохое. Старые и опытные разработчики будут уходить какую бы супер-пупер систему вы не сделали, а вот новых привлечь — задача наиважнейшая.
Нужно заниматься популяризацией и продвижением. Митапы, статьи на популярных ресурсах (Хабр, Медиум и т.п.), следовать в тренде web разработки. Ещё один из важных моментов — нужные дополнения. Судя по вопросам половина кейсов (в России) — это miniShop и всё, что с ним связано. Т.е. хорошие решения тоже популяризируют MODX.
Многие приводят в пример YII. В тяжёлые для него времена нашлись энтузиасты и подхватили падающий флаг. У MODX они тоже есть. Но, к сожалению, самым узким местом является команда core-разработчиков. Они уже не у одного энтузиаста сбили желание хоть что-то сделать для MODX. Я попробовал в мягком режиме обойти эту проблему и предложил решение с расширением главного класса (тут и тут). Но чуда не случилось. Джейсон отмёл данный вариант не объясняя причин. Патамушта.
Но есть ещё один вариант, который не требует никаких разрешений и одобрений со стороны этих «собак на сене». Нет, не форкнуть. Реализовать свою админку. Например, на том же VueJS. Представляю как многие ухмыльнулись. Да, это может помочь. Поясню. Как вы знаете (а я обращаюсь именно к опытным разработчикам), у админки своя точка входа в отличие от фреймворков. Также как и у WP, Joomla. Поэтому ничто не мешает сделать ещё одну. Всё это можно сделать в виде компонента. Ну или того же Composer. Она будет также через коннекторы работать с ядром. И в ней реализовать все самые любимые фишки MODX. А главное — избавить новичков от страха учить ExtJS. ))
Я знаю, что многие из вас скажут. Да, это много работы. Но я уверен, что за тот же год активной работы нашей группы над MODX3, (который, я уверен, никогда не выйдет) можно было бы сделать более менее рабочее решение. И тут я хочу высказать крамольную идею. Необходимо изменить подход. Не разрабатывать в админке бекэнд для дополнений. Всё это нужно вынести на фронт, как это делают для фреймворков. И тут можно применить любые технологии. Оставить только вещи типа настроек, прав, работы с контентом и дополнениями. Да и для контент-менеджеров можно свой интерфейс сделать. Т.е. админка только для администраторов. Это существенно упрощает задачу.
Но всё это упирается в один самый важный вопрос — что делать с существующими дополнениями? У меня только один ответ — переделывать. Я, например, готов. И даже больше скажу, хочу. Сделать такое дополнение, которое можно будет поставить и на MODX и на Ларавел. Я знаю, есть люди поумнее меня. Может они найдут более компромиссное решение. Тут всё упирается не только в желание, но и возможности.
Вот такая тема. Без технических подробностей и конкретных решений. Просто «для подумать». Возможно это даст толчок другой идее. Может быть дело дойдёт до прототипа. А там и корифеи подтянутся со своими знаниями и предложениями.
Update 17.09.2019
Демо прототипа.
Есть тема для дискуссии. Как вы знаете, дела в лагере разработчиков MODX не очень. Если глянуть на список пользователей, то многие из топа уже покинули этот лагерь. Недавно сообщество потеряло главного амбассадора. Да и номер первый, как мы знаем, с MODX контактирует только на старых проектах. Конечно это удручает. Но такова жизнь. Так происходит везде. Это не ноу-хау MODX. Рынок разработки стремительно меняется. Приходят новые технологии, языки, подходы. Сайты становятся сложнее. Рынок простых CMS сужается. Конкуренция становиться жёстче. И тут MODX сильно проигрывает. Несмотря на то, что он не хуже Вордпресса, Джумлы и Битрикса, новых разработчиков он привлекает всё меньше и меньше. И это самое плохое. Старые и опытные разработчики будут уходить какую бы супер-пупер систему вы не сделали, а вот новых привлечь — задача наиважнейшая.
Нужно заниматься популяризацией и продвижением. Митапы, статьи на популярных ресурсах (Хабр, Медиум и т.п.), следовать в тренде web разработки. Ещё один из важных моментов — нужные дополнения. Судя по вопросам половина кейсов (в России) — это miniShop и всё, что с ним связано. Т.е. хорошие решения тоже популяризируют MODX.
Многие приводят в пример YII. В тяжёлые для него времена нашлись энтузиасты и подхватили падающий флаг. У MODX они тоже есть. Но, к сожалению, самым узким местом является команда core-разработчиков. Они уже не у одного энтузиаста сбили желание хоть что-то сделать для MODX. Я попробовал в мягком режиме обойти эту проблему и предложил решение с расширением главного класса (тут и тут). Но чуда не случилось. Джейсон отмёл данный вариант не объясняя причин. Патамушта.
Но есть ещё один вариант, который не требует никаких разрешений и одобрений со стороны этих «собак на сене». Нет, не форкнуть. Реализовать свою админку. Например, на том же VueJS. Представляю как многие ухмыльнулись. Да, это может помочь. Поясню. Как вы знаете (а я обращаюсь именно к опытным разработчикам), у админки своя точка входа в отличие от фреймворков. Также как и у WP, Joomla. Поэтому ничто не мешает сделать ещё одну. Всё это можно сделать в виде компонента. Ну или того же Composer. Она будет также через коннекторы работать с ядром. И в ней реализовать все самые любимые фишки MODX. А главное — избавить новичков от страха учить ExtJS. ))
Я знаю, что многие из вас скажут. Да, это много работы. Но я уверен, что за тот же год активной работы нашей группы над MODX3, (который, я уверен, никогда не выйдет) можно было бы сделать более менее рабочее решение. И тут я хочу высказать крамольную идею. Необходимо изменить подход. Не разрабатывать в админке бекэнд для дополнений. Всё это нужно вынести на фронт, как это делают для фреймворков. И тут можно применить любые технологии. Оставить только вещи типа настроек, прав, работы с контентом и дополнениями. Да и для контент-менеджеров можно свой интерфейс сделать. Т.е. админка только для администраторов. Это существенно упрощает задачу.
Но всё это упирается в один самый важный вопрос — что делать с существующими дополнениями? У меня только один ответ — переделывать. Я, например, готов. И даже больше скажу, хочу. Сделать такое дополнение, которое можно будет поставить и на MODX и на Ларавел. Я знаю, есть люди поумнее меня. Может они найдут более компромиссное решение. Тут всё упирается не только в желание, но и возможности.
Вот такая тема. Без технических подробностей и конкретных решений. Просто «для подумать». Возможно это даст толчок другой идее. Может быть дело дойдёт до прототипа. А там и корифеи подтянутся со своими знаниями и предложениями.
Update 17.09.2019
Демо прототипа.
Комментарии: 148
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Смысл делать такие фундаментальные правки раздельно от MODX ядра?
— Релиз MODX 3 уже 2 года ждут
— Релиз EVO 2 уже год ждут
Форк есть смысл делать только ради того что б уйти от MODX LLC и их последнего слова что и как делать.
Но скажу я вам что без имени MODX будет сразу куча работы в плане маркетинга ибо обьяснить что это тот же MODX но называется теперь по другому будет крайне сложно и на это нужно много ресурсов.
Поэтому как по мне логичней организовывать сообщество и продавливать MODX LLC.
Идея шикарная. Хоть я и не «профессиональный разработчик», но готов помочь тестированием/отладкой/вёрсткой/временем.
Отдельное спасибо за выражение в сторону core-разработчиков:
Грустно посмеялся.
Нужно 2 дополнения для MODX:
— RestApi, которое будет работать как бэкенд для любых админок и устанавливаться на любой свежий MODX. Api должно реализовывать текущий функционал админки MODX через её процессоры.
Я уже делал что-то подобное для своего мобильного приложения, хоть это и не Rest. Можно посмотреть, ради интереса, только не берите за основу.
Внимание, сам RestApi не обязательно писать на MODX, он должен просто работать с MODX, но базироваться может хоть на Slim3 + Eloquent, если разработчикам так удобнее.
— VueManager, который будет ставиться и предоставлять альтернативный менеджер, работающий с этим API. Тут только frontend приложение с основным функционалом. Второй этап — продумать его расширение дополнениями. У Vue.js есть, например, система событий на которую можно подписываться и что-то делать.
С самого начала нужно писать тесты и документировать API (это можно делать и автоматически). Тогда это не просто взлетит, а придаст второе дыхание системе. Любители React.js смогут написать свою админку — Api-то общий и понятный.
При таком подходе, над дополнениями могут работать 2 независимых команды. Кому-то по душе бэкенд, кому-то фронтенд.
Дальше очередь за дополнениями. Некоторые будут работать со старой админкой, некоторые — с новыми, это уже на совести их авторов. Пусть победит сильнейший!
Ну а в очень дальнем будущем, RestApi можно будет и вовсе отвязать от MODX и использовать с каким-то другим ядром. Потому что это Api является уровнем абстракции, под которым можно заменить что угодно — и фронтенд об этом не узнает.
И тогда мы получим свою MODX-Like CMS, которая будет работать на тех же идеях, но написанную с нуля и без тяжелого наследия времён Etomite CMS.
А вот тут я мимо. Знания самые базовые.
Абсолютли )
Если работать с тем, что есть — у нас опять будут разные костыли, потому что нынешние процессоры завязаны на нынешнюю админку и от этого нужно избавиться. Плюс, автоматическая генерация документации будет возможна только по новому API.
А вот как появится такое API (хотя-бы для работы хоть с чем-то простым), тогда можно начинать и фронтенд. Дальше обновляется API и за ним идёт админка.
В моём представлении — вот так.
Можно долго обсуждать и принимать решения, но пока у проекта не появится паровозик, который его потащит — проект никуда и не поедет.
На данный момент, насколько я понимаю, никакая ORM вообще не нужна, потому что мы будем работать с готовыми объектами и процессорами MODX, делая к ним запросы, получая ответ, обрабатывая и отдавая в чистом виде наружу.
RestApi — это просто слой абстракции над ядром MODX со всеми его сущностями.
Объекты MODX работают через xPDO, никуда от него не денешься. Не писать же сразу все свои modResource, modDocument и т.д. с их логикой — это уже точно не поднять.
Но с кодом ссори пока не помогу. Все, что нужно обращайтесь.
Как по мне стоит просто сделать MODX-Like Admin Panel на базе одного из популярных фреймворков.
если же делать совсем по уму и все через REST то прийдем к тому что можно будет и бек менять и фронт, главное что было API Френдли.
Сейчас пилю Evo 2.0 на базе компонентов Laravel, но в перспективе смотрю в сторону как раз такого решения.
Да понятно что потеряем обратную совместимость но получим современный удобный инструмент.
Ибо на текущий момент:
REVO — нужно потратить очень много времени что б переписать систему и тонну дополнений что б привести все в норму и соответствия текущим трендам.
EVO — ближе по коду к текущим трендам но большие печали по маркетплейсу.
Я бы предложил перевести разговор в плоскость что нас держит в философии MODX и что нужно перенести на свежие рельсы.
Странно слышать такой вопрос от человека, который не первый год пилит свою систему. Новая админка ничего не ломает и может работать параллельно со старой. А в дальнейшем, если взлетит, то следующий шаг — постепенное отвязывание от старого ядра.
Например, пилотные серии «Игры престолов» провалились.Никто не бросился делать сразу все сезоны. Было принято решение сделать всё заново с другими актерами и сценаристами. И в итоге грандиозный успех.
Да и то что хорошие специалисты уходят а не помогают развивать систему тоже говорит что есть проблемы.
Вообщем я за то что б открыто обсудить проблемы и варианты. А один из вариантов и есть MODX-Like Admin Panel for Laravel(или любой другой фреймворк).
А если серьёзно — такой подход ничем никого не обязывает и ни к чему не привязывает. Учитывая, как обстоят дела с финансированием и свободным временем у разработчиков — это единственный, на мой взгляд, реальный вариант хоть что-то сделать.
Выкинуть MODX никогда не поздно, но не нужно это делать в самом начале.
Для примера я долгое время считал что MODX Parser очень крут и удобен и что это и есть ядро MODX но на деле FENOM(в REVO) и BLADE, TWIG(в EVO) куда удобней стандартного парсера и отлично вписывается в философию MODX.
А самое интересно что получилось это все совместить:
— хочешь стандартный парсер да не вопрос
— хочешь шаблонизатор и в нем снипеты да тоже не вопрос
— хочешь что б в шаблонизаторе не было сниппетов(выносим их в контроллер) тоже не вопрос
p.s. Рекомендую потратить время и вникнуть в соседние технологии и понять в чем плюсы и отличия парсера и стороннего шаблонизатора:) Ведь понять что лучше для чего можно только сравнив.
— MODX Шаблонизатор
— Fenom Шаблонизатор
Я верю в это сообщество, но, думаю, что правильный путь выбрать будет очень непросто. Некоторые решения (REST-расширение, например) вполне очевидны, но вот выбранная архитектура может больно «аукнуться» позже. Трендовые решения (React/Vue/Angular/Ember) дают быстрый старт, но имеют пару фатальных недостатков — они «смертны» (да, Реакт и Вью через 3 года станут жуткими архаизмами или на столько видоизменятся, что будут иметь мало общего с тем, что вы видите сейчас) и однонаправленны — выбирая архитектуру под React, мы практически полностью (ну или в большей степени) делаем её несовместимой с Angular/<ваш любимый фреймворк>.
Я не смею предлагать, но вижу наиболее сильный формат в поиске решений — дебаты. Т. е. должен возникнуть положительный конфликт, когда все заинтересованные стороны (а не один разработчик) принимают решение о векторе (или закладывают точку для ветвления/масштабирования). Своего рода роадмап, но не решений, а обсуждений: RestAPI — на каком языке (может, это вообще микросервис на Go или SaaS-платформа)? Какой API-фреймворк? Работа через API MODX или напрямую с БД? Типизация? Валидация? SDK? Админка — а что на счёт Headless CMS? Может, какой-то DSL для обратной совместимости? React/Vue/Angular/etc? Монорепозиторий (lerna + yarn workspace) или независимые компоненты?. Плюс такого подхода ещё и в том, что параллельно с доводами в пользу своего решения «кандидат» сам будет заинтересован в наибольшей понятности своего предложения. И сразу понятно, какие компоненты системы могут кем курироваться. Стабильно в течение какого-то времени (неделя? месяц?) «комитет» принимает решение (после того, как споры вокруг какой-то темы стабилизировались (утихли или разделилился на несколько лагерей).
Со своей стороны предлагаю опыт в клиентской и серверной шаблонизации, DSL, SSR, сборщиках, компонентном подходе и вёрстке, UX/UI.
Возьмём Vue.
Двунаправленный биндинг? Но он существует еще со времен Backbone.
Шаблонизация? Но это было еще в Mustache и есть даже в ExtJS Modx.
Компоненты? Ну каждый их реализовывал как хотел, а история с инкапсуляцией компонентов/виджетов/отдельных частей интерфейса/назови как хочешь — оочень бородатая. БЭМ — тому свидетельство.
Vuex — как единое место хранения данных? Это всё тот же Storage из ExtJS, но чуток переработанный.
Все это было 10-15 лет назад и концептуально, ну вообще никак не поменялось.
Взять инструменты сборки.
Почти всё, что есть сейчас было еще в первых версиях Ruby on Rails. Многое: склейка спрайтов, склейка JS, переменные в CSS и т.п. не нужно нынче, т.к. стало частью стандарта или неактуально с приходом http2. А концептуально ноги инструментов сборки растут из бородатого Make, 1977 года рождения. C Babel — больше вреда чем пользы: дополнительное звено в разработке и увеличивает бандл полифилами и страдает время сборки. А что даёт? Возможность использовать самые-самые последние, «синтаксически сахарные» в большинстве своём, конструкции языка? А раньше то как жили? Простенько, банально не использовали, пока поддержка этих конструкций в браузерах не достигала 90%.
Бесспорно движение во фронтэнде есть, но технологически никуда не ускакал, а вполне себе итерационно развивается, ровно как и всё остальное.
Веб-воркеры, сервис-воркеры, сокеты, модули, PWA, работа в оффлайне и т. д. — всё то, что будет иметь каждый конкурентный продукт в ближайшие годы. Конечно, все эти технологии не должны навязываться выбранной CMS/CMF-системой, но ещё хуже, когда они противоречат.
Восстребованной будет та система, которая минимизирует время + ошибки + порог вхождения + тестирование и отладку + кастомизацию и/или расширяемость. Я использовал MODX, когда для этих условий не было аналогов, но это время прошло. Быть разработчиком и не развиваться — значит, быть плохим разработчиком.
Вы явно не понимаете о чём говорите) Действительно, зачем этот vue вообще нужен, когда есть лодашевый _.template()? Всего одна маленькая функция для шаблонизации! Не ну а чо, берём её, придумываем свою реализацию компонентов и вперёд пилить интерфейсы)
Чуток?) Я вам по секрету покажу:
вот и всё, что нужно для глобального хранилища данных. И чего они там в своих MobX'ах и Vuex'ах всё усложняют?)
Нынче важна не склейка js в один большой мегафайл, а наоборот — модульность и асинхронная загрузка только того, что действительно необходимо в данный момент времени на данной странице (code splitting и вот это всё).
И действительно, чего это все до сих пор парятся с svg-спрайтами — подключали бы на страницу по одному, делов-то.
HTTP2 придё и порядок наведё!Что за идеализация http2?> страдает время сборки
SSD реально решает эту проблему. Но в современном фронтенде самую жирную часть времени сборки отнимает SCSS (который, внезапно, пришёл из руби-мира). Тут могу только посоветовать на стилус переходить.
> больше вреда чем пользы: дополнительное звено в разработке
Вы это дополнительное звено никак не почувствуете. А вообще, js — это дополнительно звено в разработке между пикселями на экране и машинным кодом, php — это дополнительное звено в разработке между http-запросом и тем же самым машинным кодом на сервере. Продолжать, думаю не стоит)
И касательно babel'я. Babel же в сути своей — прекрасен! Вы только вдумайтесь — это тулза, написанная на javascript, которая делает javascript из javascript! Это же просто волшебно)
> увеличивает бандл полифилами
Дак ему за это просто нижайший поклон! Вы действительно не видите преимущества в том, чтобы один раз написать код, который будет работать максимально везде?
Вы действительно не видите преимущества в том, чтобы писать максимально читаемый и понятный другим разработчикам код, который будет работать везде?
> А раньше то как жили?
Раньше мы писали килотонны лапши:
Тяжёлое наследие, что поделать. Зато сейчас просто и понятно:
Это ведь не просто сахарок — это банально ускоряет разработку, повышает читаемость, сокращает количество набираемого кода. Нахрена писать Object.assign({}, obj), если можно написать { ...obj }? Но при этом object-rest-spread ещё только в черновиках стандарта и не имеет поддержки даже в последнем v8, а я уже без него жить не могу, потому что пишу так 5-6 дней в неделю на протяжении последних 2-3 лет.
И мне не пришлось ждать 3-4-5-6 лет, пока эта фича появится в 90% браузеров и платформ. Это же круто, чёрт побери!
Я даже на последней ноде, когда делаю бэкенд, юзаю babel. Просто именно поэтому.
И как заметил Роман выше — речь не про новые плагины галереек. Типа, ну накуя оно всё это нужно, если раньше галерейки работали без вот этого вот всего?!
Просто то количество бизнес-логики, которое сейчас приходится писать во фронтенде — несоизмеримо в разы больше, чем раньше. Вот просто в разы. И если бы сейчас не было Vue — я бы повесился писать всё это на jQuery/Backbone/Ember'е/ExtJS'е. Конечно и раньше были большие и сложные проекты — я ж не отрицаю. Но 6-7 лет назад для этого требовался штат из десятков JS-разработчиков (просто потому что кода надо было писать в десятки раз больше). То сейчас командой в 3-5 человек можно поднимать сопоставимые по уровню проекты за приемлемое время и деньги. Более того, в такую команду гораздо легче добавить новых разработчиков — они быстрее въезжают, ведь гораздо меньше кода для изучения и в нём используются уже общепринятые концепции, а не выдумывались какие-то свои.
Ну и по всем пунктам присоединяюсь к комментарию Романа выше.
В любом случае все варианты будут сводится к неким костылям, так что тут либо выбрать самый красивый костыль, либо форкнуть и развивать своими силами.
Evo похоронили, мир не рухнул.
Где найти столько желающих потратить своё время за ноль рублей?
Главный продукт — минишоп. Начинать нужно с него.
Как хочешь, так и понимай. Сколько лет MODX, а базового решения для апи нет. Сделать универсальное решение — большое дело. Хотя бы через компонент.
Mark Hamstra
I think we first need a rest API and then to think about a new frontend. And there's also a mab decision about that from last year.
When there's an API, the frontend framework can be more easily changed in the future. Or there could be different ones even.
Нравится дерево ресурсов, нравится PDOTools, но главное, можно сравнительно быстро сделать магазин с интеграцией с 1С.
Не нравится что все шаблоны чанки в БД. Не нравятся эти дебильные поля типа LongTitle который ни разу не были нужны. Не нравятся ТВ-костыли. Да и добавление свойств товарам в Минишопе — тоже пойди пойми как лучше сделать. Не нравится сложность создания собственных модулей. Ну то есть вот этих CMP или как оно.
Я хочу быстро накидать схему для БД под мои нужды, как это делается в какой-нибудь Strapi или Directus. И вывести всё это на фронт привычными средствами без всяких там реактов или вью. Потому что у них свои недостатки и, как уже говорилось, они не вечны. Но при этом, чтоб можно было и ими пользоваться если захочется. Поэтому мне нравится концепция Философа с его ПризмойЦМС, но там нод.джиэс и вот это вот всё.
Может MODx или новая MODx-Like CMS предоставить это в обозримом будущем? Есть смысл сохранять обратную совместимость для поддержки старых модулей или большая часть сообщества сидит здесь из-за минишопа и PDOTools, которые с новым API могут стать лучше? Не станет ли поддержка обратной совместимости тормозом? Сколькими дополнениями вы реально пользуетесь? У меня, помимо ПДОтулс и Минишопа это MSearch2, Office, CodeMirror ну + платёжные системы и 1С. Полезные мелочи типа Units можно не рассматривать — их можно самому за вечер переписать.
А по поводу пилить 10 лет… Ну давайте 10 лет пинать труп. Вон рядом ребята джумлу с вордпрессом пинают, а мы чем хуже? Мне кажется концепции ЦМС с жёстко прописанными полями в одной табличке и допполями в другой несколько устарели. И никакая быстрая админка эти косяки не исправит. Смысл тогда?
… или я всё не так понял и пойду-ка я спать.
Два раза пишут одно и тоже в поле pagetitle / longtitile, ведь далеко не все страницы имеют тайтл отличный от h1? Ну и плюс MODX генерирует url по полю pagetitile, а в нем находиться title, который по определению обычно более длинный чем h1 и будут получаться очень длинные URL.
Я делаю так h1 — это pagetitle, а в head проверка — если longtitle пуст то берем в title значение тоже что и для h1, если заполнен — то ставим в тайтл значение из longtitle.
title нужен в первую очередь для SEO и он может отличаться от заголовка страницы
А если нужно задать отличный от него title то прописывать его в longtitle
Но это дело вкуса.
«Из коробки» Октябрь полное противопоставление MODX с т.з. перегруженнсоти функциональностью последнего, он очень аскетичен, ничего лишнего. Все, что нужно ставится плагинами, даже система пользователей («из коробки» только один админ). И e-commerce там такой же модульный на базе Shopaholic.
каждое второе сообщение на modx.pro от Павла, это сообщение в сторону октября. Ну серьезно, это даже не смешно. Давайте теперь каждый из нас будет постоянно говорить о наиболее импонируемых CMS. Почему нет?!
P.S. Называя людей никчемными за минус в интернете, вы подписываетесь в собственной никчемности. На это предлагаю закончить, так как топик совсем о другом.
По моему опыту скажу, что было бы отличным решением разработать, что сейчас делает Дмитрий Лукьяненко: Evo с Laravel.
По поводу плагинов.
Я уже года 2 не скачиваю никакие плагины и сниппеты, кроме pdoTools, FormIt, Search, TinyMCE, MIGX, Collections.
Всё остальное я пишу сам.
Поэтому лично мне пофиг на совместимость (что её не будет) в новых версиях.
Для меня в идеале:
- Мне нужна админка, как сейчас EVO/REVO (смысл, твшки, чанки).
- Чтобы по-умолчанию на файлах (чтобы парсило папку с шаблонами и чанками, по примеру Grav CMS). Но можно было бы в настройках включить «Хранить чанки и сниппеты в базе».
- Под капотом Laraver (что угодно, лишь бы современное, масштабируемое), с которым что угодно можно сделать.
Коротко: админка и философия от MODX + чанки на файлах как у Grav CMS + безграничные возможности Laravel.Смысл в том, чтобы можно было бы делать сайты «как раньше», но и есть возможность собрать самолёт. И всё из коробки (подтянуть любую библиотеку через composer).
А в третьих, что там напилит Дмитрий покажет время. И если напилит. И то что получиться, думаю, будет интересно ему и ещё троим-четверым (не в обиду Дмитрию). И пока Revo не скатилась до уровня Evo нужно принимать срочные меры. Иначе через несколько лет его постигнет судьба младшего брата.
Ребят. Не взлетит. Да и самим понятно. Я скептик, но не отговариваю.
Не так это делается.
Пробуйте, если заняться нечем. Подумайте лучше еще раз.
Мне нужна удобная CMS для одностраничников (пятистраничников) и сложных проектов (веб-аппликаций) в одном движке.
С админкой, как в EVO/REVO.
Вот тебе, например, для чего нужна обратная совместимость?
Но вот пришел главный и поставил жирную точку. Цитата:
Т.е. MODX и так слишком гибкий. Харэ.
Каким боком разработчика ядра должно касаться то, что делает пользователь MODX, самостоятельно расширяющий систему. Твоя задача дать эту возможность, а дальше не твоя забота. Но нет, ни в какую он (Джейсон) не хочет давать контроль над ядром, даже на уровне пользователя.
Разработчик добавил этот метод в ядро, но пользоваться им, он считает, плохо. Хотя в том же ядре полно использований статических методов. И примеры из смежный более успешных продуктов не убедительны.
Ну что я могу сказать. Этот человек делает всё, чтобы MODX остался там, где он есть.
А идея с админкой — это альтернатива, которая полностью исключает необходимость обращения к этому товарищу. Это просто обычный компонент, но не совсем обычный. ))
Современные тенденции требуют использования модных JS фреймворков. И тут я полностью выключаюсь из процесса ибо я не дизайнер, не верстальщик и у меня нет большого опыта работы с Vue/React/Angular и т.п. фреймворками. Могу чисто языком поработать ))
— да будет так! Очень интересно.
Любители фронтенда сами подтянутся, когда им будет куда отправлять запросы для получения данных.
А по теме: каждый день захожу читаю, интересно, но от себя пока нечего добавлять… только слово НАДО что-то делать и развивать, а то как тут уже много раз писали застрянем в аналоговом веке и все тут…
Только политоты накинуть на вентилятор, молодец.
но справедливости ради: в целом так говорят.
github.com/modxcms/revolution/pull/13900#issuecomment-390403195
Собственно, с тех пор я как-то и перестал спорить. Тут люди десятилетиями работают, им виднее.
Но пока никто не взял и не сделал — остаётся только ждать, увы.
Кто может уже помогает, а не размышляет.
Я сейчас о программировании на процессорах. Нужна новая админка — бери, да пиши.
MODX Evo/Revo Сейчас привлекает многих тем, что можно использовать чужие наработки без проблем. А с новой админкой что? Опять проходить все круги ада — Tickets, miniShop и бла-бла-бла… Думаю это никому не нужно будет. Но, как бы не хотелось чего-то новенького да удобненького, большинство все равно будет пользоваться стареньким и привычненьким.
Опыт Evo тому пример. Я лично выступал инициатором реноваций, но всегда это заканчивалось неудачей. И так продолжалось до тех пор, пока я не написал 100% совместимый шлюз от DBAPI в Eloquent. Дальше стало проще — бек можно развивать вместе с админкой, но энтузиазма лично у меня уже не осталось.
А по API что скажешь?
Я в своих проектах для решения подобной задачи просто использую DSL (Loopback 4), который нивелирует разницу между выбираемой технологией под абстаркцию описания типов (по аналогии, как это делается в MODX, когда описывается схема таблицы в XML). В этом случае мы сможем решить ещё и проблему поддержки нескольких типов БД — MySQL, PostgreSQL, NoSQL.
Лично я для старта выбрал Swagger, т.е. OpenAPI спецификацию. Она более читабельна, чем JSON-API.
1) Тип ресурса
2) Метод
3) Критерий
Таким образом мы получим запросы типа:
Конечно же сервер должен вернуть нам JSON.
Ну а понимание того, что мы хотим сделать с ресурсом, нам даст метод запроса (GET, POST, UPDATE ...).
Сам класс компонента должен проверить права (тут есть вопросы!), корректно определить пожелания пользователя из запроса, произвести валидацию данных, дернуть соответствующий процессор и вернуть ответ!
Если админка только для разработчика, то для обращения по апи пользователь должен быть авторизован в текущем контексте и иметь соответствующие права.
Вродь как этого достаточно для старта, или я опять не вижу кучу подводных камней?
Событие onPageNotFound тут не при чем.
С другой стороны — может это и к лучшему? Глаголы изначально не рассматриваются, работаем с базовой частью.
P.S. Да это угроза-).
Я новичок в Modx(буквально пару недель назад начал активно им пользоваться) так что не кидайтесь пожалуйста тапками.
Вероятнее всего никого не удивлю, но не столько мне как большинству моих друзей(по большей части дизайнеров\фронтенд разрабов) в Modx не хватает GUI редактора(может даже с функционалом по типу — создал блок (самый простой как в блогах — с заголовком картинкой и текстом) и выделив несколько тэгов вставил как чанк — для того что бы программист понимал что к чему когда садится редактировать код в лучшую сторону) по этому они остаются на WP, на котором лично мне ужас как не нравится работать.
В случае если будет GUI редактор дизайнеры, к примеру, могли бы делать наброски, структурировать их в чанки, давая им имена и тем самым облегчая задачу «понимания» кода программисту. Думаю это привлекло бы внимание начинающей аудитории, так как учитывая чистый html css на выхлопе, возможность кастомизировать множество вещей и относительную простоту граф редактора выходит очень(имхо) привлекательная cms как для программиста так и для дизайнера
Надеюсь мое мнение было кому-то полезным
Несколько месяцев назад у нас сменились СЕО специалисты и те что пришли — скорее всего ранее работали только с WordPress. На wordpress есть куча визуальных редакторов для страниц (WPPageBaker, Elementor) которые позволяют основываясь на bootstrap разметке создавать в админке контейнеры, дробить их на колонки и выводить разноплановую информацию. И теперь для меня на modx настал маленький ад. Потому что специалисты просят выводить информацию на странице в совершенно случайном порядке — у этой новости пишем два предложения, потом набор из 5 иконок с текстом, потом еще абзац текста, потом слайдер с изображениями, потом адаптивную таблицу с ценами, потом два абзаца текста и что-то еще. А следующей новости — все совершенно по другому… Стоит привести верстку страницы к желаемому виду, завести новые поля у шаблона страницы новости, показать всем как и что заполнять, как на следующий день принимается решение что все нужно по другому либо же что вот эта свежая новость должна выглядеть совершенно иначе, а старые — пусть выглядят как и были. И так по 30 проектам. И было бы действительно не плохо иметь возможность установить дополнительно визуальный редактор, и пусть бы они сами это лепят.
Извиняюсь за преждевременный коммент и спасибо за совет =)
У MODX есть недостатки: сайт тупит когда много ресурсов и tv, нет дополнений таких как чат, форум, делать компоненты на продажу не слишком выгодно (для большей части аудитории хватает бесплатных и на платные мало покупателей, не считая конечно office и msearch). С tv, наверно, можно было сделать галочку «хранить в отдельной таблице» и, при ее включении, создавать для tv таблицу с типом value определенном правилами tv и переносить в нее все данные этой tv.
Уф. Высказался. Не очень мне нравится разговоры про новый MODX и отказ от обратной совместимости.
Фаритwww.slimframework.com/2015/02/23/modx-cms-and-slim.html
П.С. Какие-то странности с уровнем комментариев. Писал в корень — показывает 3 точки, хотя ссылки на parent нет.Во-вторых, про это уже говорили. Данное решение изучалось. Оно оказалось крайне ограниченное. Ничего кроме items/15 вы не получите.Т.е. статью с комментариями одним запросом никак не получить. И поля никак не указать. Так что на этом серьезное API не сделаешь.
В-третьих, сам Джейсон недавно в обсуждениях на Github писал, что делает API через Slim. Т.е. даже сам сапожник не носит свои сапоги.
В-четвертых, задача попробовать минимизировать зависимость от core-разработчиков.
И в-пятых, третья версия MODX планировалась на Slim 3. Возможно наше решение даст толчок для реализации этих планов.
Так что всё пока логично. А вас, товарищ, мы из групповухи вычеркиваем.)
Во-первых и вторых — это не готовое API, и не и инструкция по его созданию, а базовые классы, которые можно расширять, кому как нужно, и да — это далеко не самое удобное решение.
В-третьих, сам Джейсон, я более чем уверен, имел в виду, что когда ему нужно создать API-based решение использует Slim (а Джейсон, правда сапожник?)
В-четвертых — В-пятых, третья версия планировалась на Slim 3, да, планировалась (в 2015), но не как надстройка над MODX 2, правильно? Я так понимаю в далеком 2015 сапожник Джейсон мечтал о PSR-7 и думал о Slim 3 и XPDO 3. Но тяга к обратной совместимости и прочие факторы дают о себе знать