MODX на Golang

365 1
Всем привет! Заранее извиняюсь за выбор раздела для данной заметки, но в разделе «Вопросы» я врятли бы получил бы достойный фидбек.

Предисловие


Я наблюдаю за движением modx и cms в уже больше пяти лет, и так получилось, что за последние годы веб-разработка разделилась на две вселенные которые не видят друг друга: программисты на фреймворках использующие весь арсенал современного разработчика и разработчики на CMS, которым этот инструментарий не доступен, но нужда в нем все больше, отчего вторые перетекают в лагерь первых.

Проблема миграции


При переходе например на Laravel такие разработчики довольно быстро сталкиваются со следующими проблемами:
  1. Скорость разработки
  2. Отсутствие вменяемых инструментов управления для клиента
  3. Сложность деплоя/поддержки сервисов
В общем все то, что им давала CMS безвозмездно, но взамен они получают крутой инструментарий, который в итоге клиенту оказывается не сильно то и нужен. В итоге, не редко получается, что такому разработчику приходится либо пытаться усидеть на двух стульях, либо вернуться назад на CMS т.к. там можно заработать больше денег за единицу времени

Почему MODX?


Я давно вынашиваю идею скрещивания современных возможностей веба и CMS, за это время я перепробовал почти все CMS, все админки для laravel, а также не малое количество headless cms, и даже несколько никому неизвестных, но очень амбициозных проектов, ни одна админка/cms/hedless cms и рядом не идет с удобством админки modx'a, а современные концепции разработки никак не вписываются в их философию

Снова CMF?

Да, я предлагаю воскресить идею CMF, то, за что многие влюбились в modx, гибкость и простота разработки, по моему мнению MODX — это тот случай, когда удалось усидеть на двух стульях, и по моему мнению на данный момент ни одна система не дает такую же свободу действий, скорость разработки, удобство админ панели как modx

Почему Golang?


Я думаю я не скажу откровение сказав что отток разработчиков из PHP огромен по следующим причинам:
  1. Узконаправленность
  2. Динамическая типизация
  3. Прожорливость ресурсов
  4. Отсутствие многопоточности и ее управлением
  5. Концепция Born to Die
  6. Медленная скорость выполнения
И многие — многие другие минусы вытекающие из концепции скриптового ЯП

Golang же достаточно прост, чтобы иметь порог входа не сильно выше чем у PHP, в 10 раз быстрее PHP, имеет строгую типизацию и типобезопасные переменные (привет TS), он многопоточен и имеет серьезный инструментарий для управления потоками (каналы), а также имеет строгие требования к архитектуре (запрет на циклические импорт и куча дополнительных инструментов «из коробки»)

MODG


Итак главные концепции переноса modx на golang:
  1. Сохраняем текущий интерфейс полностью (modx 3 like), но переносим фронтенд на vuejs 3
  2. Сохраняем текущий функционал полностью и архитектуру БД, но чанки, шаблоны, плагины, сниппеты становятся файловыми, кеширование выносится в redis и только в него
  3. Вместо поиска по системе через like реализовываем легковесный и ресурсонетребовательный полнотекстовой поиск, например через MeiliSearch
  4. Реализовываем функционал создания новых типов ресурсов, а также генерации миграций для них с динамическим подтягиванием новых полей из схемы базы данных (название полей тянем из словаря)
  5. Реализовываем простую систему очередей и их управлением/созданием через Redis
  6. CLI установщик, сборщик проекта и утилита управления dev/prod средой
Это главные и основные концепции, главная задача на первое время — перенести все на новый ЯП, сохранить текущий функционал (т.к. он работает) и дать разработчикам доступ к новым современным и эффективным инструментам

Что нужно от сообщества?


На данный момент — ничего, просто фидбек о том, что вы думаете по этому поводу и нужна ли такая система сообществу, альфа версию я буду писать один от фронтенда до бекенда, как только будет определена архитектура, работать основной функционал, как только можно будет с помощью этого инструмента реализовать простой блог, тогда я буду просить от хабр и modx сообщества помощи в развитии проекта

Когда ждать

Работа предстоит не маленькая даже для минимально работающей версии, я думаю если проект вообще не затухнет на этапе получения фидбека, на реализацию нужно не менее 8-12 месяцев
Pavel Zarubin
13 сентября 2022, 13:59
modx.pro
1 204
+5
Поблагодарить автора Отправить деньги

Комментарии: 39

Pavel Zarubin
13 сентября 2022, 15:52
+4
В телеграмм чате с активной аудиторией пришли к мнению что у такого решения ЦА — не modx разработчики, modx разработчикам не нужны все эти многопотоки, очереди, скорость и т.д., modx разработчикам нужно чтобы они в админке смогли на проде наклацать сайтик, да на хостинге его развернуть одной кнопочкой. Видимо, они правы, ушла эпоха и что то «среднее» людям не надо, либо за очень дорого делаем на фреймворке, либо за очень дешево делаем на cms заливаем и забываем. Возможно они и правы, от своей идеи не отказываюсь, оставлю этот спич на всякий случай, вдруг кто что умное скажет, но при проектировании системы ориентироваться на комьюнити modx уже явно не буду.
Хочу выразить благодарность всем выразившем свое мнение и участвовавшим в дискуссии, всех с праздником!
    Misha Bulic
    13 сентября 2022, 21:06
    +1
    Мне в Modx не хватает нормального деплоя через Git. У вас будет эта проблема решена?
    И что конкретно вас так вставляет в админке Modx?
      Pavel Zarubin
      13 сентября 2022, 21:45
      +1
      > У вас будет эта проблема решена?
      Golang компилируется в один файл, все что вам нужно для деплоя, залить этот файл на хостинг, нет ни конфигов, ни кучи файлов, вместе с CMS будет идти утилита деплоя, через которую вы сможете залить изменения одной кнопкой и/или командой, соответственно все изменения храните хоть в гите, хоть где либо еще)

      > И что конкретно вас так вставляет в админке Modx?
      В первую очередь это конечно же дерево ресурсов, возможность перейти из любой точки, в любую другую парой кликов, для заказчика это очень удобно, т.к. он видит структуру сайта наглядно, а также может ее поменять обычным перетаскиванием.
      Также очень нравится идея что все есть ресурс и это «все» также видно в дереве)
        Иван Климчук
        14 сентября 2022, 09:22
        0
        Тулинг в Go хороший, соглашусь. Но как ты правильно заметил в прошлом комментарии, для сайтоделов это слишком большой оверхед. Одной кнопкой будет работать, когда все хорошо, а вот если что не так, go даже не скомпилирует бинарник. Жопы будут гореть знатно, когда оно не будет собираться :)
          Pavel Zarubin
          14 сентября 2022, 14:58
          0
          для сайтоделов это слишком большой оверхед
          Я думал на счет этого очень долго, сужу по своей компании: мы бы большое количество сервисов из тех, что у нас есть реализовали бы на CMS, но ни одна CMS не дает функционала, который нам нужен, а фреймворки — дают его слишком много, от чего разработка длится кратно дольше, чем если бы сервис был реализован на CMS
          Я считаю, что у такой ниши, которым нужно что то среднее между CMS и фреймворком есть своя аудитория, но она молчит и делает сервисы на laravel на каждый чих подключая новую библиотеку и пробуя очередную бесполезную админку, потому что десяток других админок показали себя хреново

          > go даже не скомпилирует бинарник
          Лучше когда все заработает, как с PHP, зальется на прод, а потом окажется что в богом забытом модуле, который не упустили QA все отвалилось?)
          Уж лучше пусть не компилируется) У го стектрейс даже более понятен, чем у PHP за счет отсутствия такого массивного ООП и магии, так что думаю это не большая проблема )
            Иван Климчук
            14 сентября 2022, 22:22
            0
            То, что нет ООП, в некоторых случаях скорее минус, чем плюс. Бизнес-логику по DDD без ООП не построишь, а на Go это будет очень многословно (там есть ООП, просто непривычный). Тем более что в последних версиях PHP достаточно неплохо со строгой типизацией, а если еще обложить все Psalm и прочими штуками, вполне себе можно писать пуленепробиваемый бизнес-код. А узкие места оптимизировать за счет микросервисов на быстрых языках, типа Go или Haskel.

            Куча библиотек на каждый чих — это обратная сторона популярности. Аудитория огромная и каждый думает, что напишет лучше, потому и плодят кучу никому не нужных пакетов сомнительного качества, а это потом вырождается в деградацию кодовой базы. Но не спорю, для некоторых проектов проще собрать что-то минимальное на независимых от фремфорка компонентах, благодаря PSR стандартазации сейчас есть достаточно неплохой набор.
              Pavel Zarubin
              15 сентября 2022, 22:13
              0
              а на Go это будет очень многословно
              Не более многословно, чем в текущей кодовой базе modx'a я думаю, к тому же, как ты правильно заметил, подобие ООП в го есть, только более строгое (запрет на рекурсивный импорт вводит свои коррективы), менее перегруженное (нет трейтов, наследование более простое (копирование методов и свойств), одна папка — один пакет, который не должен зависеть от других пакетов (запрет на рекурсивный импорт опять же))
              Да и это в целом уже не забота конечного потребителя продукта все же

              PHP достаточно неплохо со строгой типизацией
              Она там не безопасная, как и на тайпскрипте например, только еще более не безопасная )))
              Виталий Батушев
              20 сентября 2022, 09:08
              0
              Про магию я не был бы столь категоричен. Особенно после продавливания дженериков. Пришедшие с Java и PHP граждане постоянно атакуют, требуя волшебства.
              Да и почему без конфигов? Я делаю минисервисы с конфигами, не пересобирать же бинарник всякий раз, когда нужно просто поменять какой-то параметр.
                Pavel Zarubin
                20 сентября 2022, 22:59
                0
                Особенно после продавливания дженериков.
                Которыми пользоваться — моветон

                граждане постоянно атакуют, требуя волшебства.
                Да? Не слышал такого, можно пример где и какие именно граждане такого просят?)

                когда нужно просто поменять какой-то параметр.
                Вы на проде в рантайме меняете параметры? Ну что ж, у вас стальные яйца, но так никто не делает, обычно даже php приложение собирается в кубере с новыми конфигами в том числе, и уже «на горячую» один контейнер подменяется на другой, это вроде как общепринятая практика и стандарт, по крайне мере другого я не видел там, где есть хоть мало мальский один вменяемый девопс. А при таком подходе без разницы бинарник там, или миллиард конфигов, один фиг надо собирать контейнер содержимое которого не меняется
        Роман
        13 сентября 2022, 22:10
        0
        По мне идея очень хорошая, прогрессивная. Вопрос тут есть один, насколько удобно будет расширяться данный функционал. Возможно стоит начать с каких-то микросервисов(экспорт, импорт и тому подобное)?
          Алексей Соин
          14 сентября 2022, 08:46
          0
          Использование golang это конечно круто, но тогда для использования такой cms уже не подойдёт обычный шаред хостинг, следовательно это для заказчика удорожание затрат на сервер, а для разработчика время на настройку этого самого сервера, также как и момент с кешированием в redis, это всё поднимает цену для затрат заказчика на сервер. Даже если всю эту систему упаковать в докер, то всёравно для разработчиков будет лишний гемор с поддержкой сервера (хостер систему перезагрузил, служба докер отвалилась и тд), ну и плюс интересно сколько разрабов работающих с modx готовы перейти в ряды go разработчиков.
            Pavel Zarubin
            14 сентября 2022, 14:37
            0
            > уже не подойдёт обычный шаред
            Кто вам такое сказал? Golang — не питон, он не требует дополнительного ПО для запуска и компилируется в бинарник, подойдет любой шаред, где есть вомзожность запуска бинарника, всеми любимые шареды поддерживают эту функцию, тот же таймвеб/бегет и т.д., а на помойках в принципе не стоит размещать свой сервис.

            > интересно сколько разрабов работающих с modx готовы перейти в ряды go разработчиков.
            Большинство modx разрабов и php то не знают, и это не плохо, для большинства modx разрабов ничего не поменяется в корни, а работа с апи cms может быть практически одинаковой.
              Алексей Соин
              14 сентября 2022, 14:54
              0
              Насчёт питона, сейчас какраз большинство шаред хостингов его поддерживают из коробки(например beget, timeweb, regru, jino и тд) и проблем с запуском сайтов на тойже джанге вообще нет, а вот по поводу работы с бинарниками, не нашёл инфы о их запуске на шареде бегета, знаю только что у них на шареде работает запуск бэка на других языках через Passenger, а если скрипты запущены как демоны то они их автоматически прибивают. Можешь прислать пример скрипта на Go и как его запустить на бегете?
                Pavel Zarubin
                14 сентября 2022, 15:01
                +2
                > Можешь прислать пример скрипта на Go и как его запустить на бегете?
                Без проблем, я сейчас заканчиваю вторую заметку из цикла, отвечаю на вопрос «как и почему GO быстрее php в 10 и более раз не смотря на бенчмарки» (опять же по мотивам телеграмм-обсуждения), третья значит будет про деплой на самый обычный шаред, раз так сильно эта тема волнует)
                  Алексей Соин
                  14 сентября 2022, 15:13
                  0
                  Наконецто на сайте интересные статьи будут на почитать))))
            Иван Климчук
            14 сентября 2022, 09:29
            +8
            В телеге меня пока нет, потому выскажусь здесь, тем более что @Иван Бочкарев просил это сделать.

            Я всеми руками за то, чтобы поменять архитектурный подход в проектированию MODX. Разбить систему на отдельные компоненты, разделись нормально фронт и бек, чтобы можно было админку писать на чем угодно, кому vue, кому react, но сделать что-то подобное на headless cms с API. Это разумно и это стоит сделать, иначе на MODX можно ставить крест. Какие плюсы это дает расписывать не буду, не один раз высказывался да и они очевидны.

            Насчет Go у меня большие сомнения. Особенно в части переписать вообще все. Это смена парадигмы в целом, на хостинг систему не поставишь, а ведь большинство использует систему именно для простых сайтов, которые лежат на обычном хостинге, в редких случаях на VPS. Следовательно, Go — это смена вообще всего, резкое увеличение порога вхождения, что на текущем этапе, когда в сообществе людей и так кот наплакал, аудиторию найти будет сложно. Из сообщества Go люди не придут, это так не работает, много раз уже видел подобное :)

            Но! Если решить архитектурные проблемы, когда MODX будет компонентным фреймворком, тогда отдельные системы можно переписывать на чем угодно, хоть на том же Go. И такой подход используется сейчас весьма активно в PHP мире. Когда базовая бизнес-логика описана на PHP, потому что есть ядро разработчиков, которые владеют знаниями и могут это нормально поддерживать. А критические подсистемы в плане нагрузки, пишутся на Go и внедряются на уровне отдельных сервисов. В таком случае это будет пушка-бомба!

            Это мое мнение, можно не соглашаться и спорить, это приветствуется.
              Николай Савин
              14 сентября 2022, 10:39
              +1
              С возвращением. Сообществу тебя очень не хватало!
                Pavel Zarubin
                14 сентября 2022, 14:45
                0
                > на хостинг систему не поставишь
                Почему? Я уже выше писал:
                Golang — не питон, он не требует дополнительного ПО для запуска и компилируется в бинарник, подойдет любой шаред, где есть возможность запуска бинарника, всеми любимые шареды поддерживают эту функцию, тот же таймвеб/бегет и т.д., а на помойках в принципе не стоит размещать свой сервис.
                когда в сообществе людей и так кот наплакал, аудиторию найти будет сложно
                Возможно я сильно наивен, но помимо новой аудитории, я рассчитывал вернуть большое количество старой, ну или хотя бы их заинтересовать. От большинства тех, кто ушел с modx, я слышал что ушли только по одной причине — моральное устаревание, т.е. им нравится и идея, и парадигма и концепция modx, им не нравилось то, что под капотом

                Но! Если решить архитектурные проблемы, когда MODX будет компонентным фреймворком, тогда отдельные системы можно переписывать на чем угодно, хоть на том же Go. И такой подход используется сейчас весьма активно в PHP мире. Когда базовая бизнес-логика описана на PHP, потому что есть ядро разработчиков, которые владеют знаниями и могут это нормально поддерживать. А критические подсистемы в плане нагрузки, пишутся на Go и внедряются на уровне отдельных сервисов. В таком случае это будет пушка-бомба!
                А вот это очень интересная идея, не думал в этом направлении, спасибо, но это утопия, modx — монолит, который чтобы разбить — нужно приложить больше усилий, чем уничтожить и создать заново. Возможно я ошибаюсь и в третьей версии, что-то изменилось, ее я не щупал, но насколько слышал — нет
                  Иван Климчук
                  14 сентября 2022, 22:33
                  0
                  В 3 версии мало что изменилось, но так как там уже есть полноценный композер, ее начинать разбивать на компоненты чуточку легче, чем 2 версию. Вроде как Марк загорелся идеей заняться нормально архитектурой, но по его словам, особо никто не проявил интереса на MODXpo, а я по понятным причинам не мог :)
                  Артур
                  15 сентября 2022, 21:08
                  0
                  разделись нормально фронт и бек, чтобы можно было админку писать на чем угодно, кому vue, кому react, но сделать что-то подобное на headless cms с API.
                  Может глупость спрошу, но разработчики ядра этого не понимают? А если понимают, почему не делают? Рук не хватает?
                    Иван Климчук
                    15 сентября 2022, 22:05
                    0
                    Именно что рук и времени (мозги то вроде есть). Я вот в СИЗО, например, 4 месяца сидел, а мог бы чего толковое сделать :) У кого-то свои, другие причины.
                      Артур
                      15 сентября 2022, 22:56
                      0
                      Понятно. Всё как всегда.
                  Павел Голубев
                  15 сентября 2022, 12:27
                  +2
                  Много ли разработчиков на Modx упирается именно в производительность php? Обычно самый большой затык — БД.

                  Для распараллеливания — есть корутины, для не умирания — Swoole с ReactPhp.
                    Pavel Zarubin
                    15 сентября 2022, 22:20
                    0
                    Для распараллеливания — есть корутины, для не умирания — Swoole с ReactPhp.
                    Это все доступно modx разработчику? Главный посыл — дать CMS разработчику современный инструментарий, для этого надо все разрушить и построить с нуля, а если все равно строить с нуля, то какой смысл это делать на медленном и глупом PHP? Все равно конечному пользователю CMS без разницы что там под копотом, главное сохранить идею и дать максимум возможностей от текущего развития веба
                      Евгений Шеронов
                      16 сентября 2022, 21:40
                      0
                      то какой смысл это делать на медленном и глупом PHP
                      Да перестань ты так хэйтить PHP. Например, python для Web медленнее)

                      А ты на Go перешёл до PHP8?)
                        Pavel Zarubin
                        17 сентября 2022, 13:12
                        0
                        А ты на Go перешёл до PHP8
                        Я на го не «перешел», у нас в компании все еще большая архитектура, и PHP в ней занимает 70%, по этому я каждый день пишу и на том и на том :)
                        И да, мы стараемся поддерживать в актуальном состоянии всю инафраструктуру, по этому php актуальный и его фишки используются)) В php 8 нет ничего такого волшебного и замечательного, чтобы разделить эпоху до php 8 и после)))

                        Да перестань ты так хэйтить PHP.
                        Надеюсь сегодня допишу заметку по сравнению PHP vs Nodejs vs Swoole vs Go в круде, просто хочу объяснить что нет смысла конкретно привязываться к PHP, к тому же в рамках CMS, вы же не пишите практически код используя CMS, CMS — это законченный и полноценный продукт
                          Pavel Zarubin
                          17 сентября 2022, 13:17
                          0
                          Ну и еще замечательная статья на эту же тему:
                          habr.com/ru/post/688548/
                            Дмитрий
                            23 сентября 2022, 13:52
                            +2
                            Вот этот истеричный высер на замечательную статью не тянет вообще, там автор либо тролль, либо пациент Кащенко с биполярочкой.
                      Anton
                      15 сентября 2022, 13:02
                      +1
                      Лично мне очень хотелось бы вот что:
                      1. Перенос админки на Vue 3
                      2. На файлах
                      3. Известный шаблонизатор Blade или Twig
                      4. Интеграция с composrer
                      Всё остальное можно самому прикрутить.

                      Ну а если нужно еще больше, то это уже не MODX, а Laravel.
                        Иван Климчук
                        15 сентября 2022, 22:13
                        0
                        Composer в 3 версии уже есть, остальное — нужно делать.
                          Лёша
                          16 сентября 2022, 12:50
                          0
                          Так чтоб на файлах — ZoomX же есть
                          Wassi Wassinen
                          15 сентября 2022, 20:50
                          +7
                          Скромное мнение.
                          Вы подходите не от проблем MODx, а от какого-то своего глобального видения. Это не хорошо и не плохо, но не удовлетворяет основные запросы сообщества MODx.

                          Для начала — что такое, в большинстве своем, сообщество MODx? Моё мнение (я могу ошибаться) составлено на основе чтения форумов, поиска решений, взаимодействия с разработчиками и т.д. Путь был долгим — начинался ещё на bezumkin.ru

                          Так вот, сообщество MODx, на мой взгляд, это:
                          Категория 1: 40% новичков, которые что-то могут установить, немного настроить по мануалам и копипастом, а итоге хотят получить работающий продукт с приемлемым соотношением затраты\качество. Эти люди не хотят становиться программистами.
                          Категория 2: 20% совсем зелёных программистов, которые еще не знают что им нужно, но что-то нужно сделать уже завтра.
                          Категория 3: 20% разработчики с средним знанием, которые пришли за скоростью внедрения и кастомизацией.
                          Категория 4: 20% довольно грамотные разработчики, которые по разным причинам готовы сидеть на MODx и выпускать компоненты.

                          Если представить, что мои характеристики и пропорции верны, то для 80% сообщества все эти нововведния не нужны. Всё должно просто работать, ставиться пакетами, гибко настраиваться под SEO. Если еще есть готовым магазин и фильтры — вообще класс. Можно ничего не менять.

                          И есть 20% — для которых важно, чтобы всё было «по последнему слову моды». Чтобы деплоилось, параллелилось, редактировалось из правильного редактора, собиралось и вот это всё.

                          На мой взгляд, такой подход не найдёт отклика у большинства. Нужно для начала описать проблемы, которые критичны для 80% сообщества. Попробовать прийти к наиболее изящному для всех категорий пользователей MODx решений (оставаясь в парадигме существующей структуры админки, логики чанков, шаблонов, шаблонизатора, плагинов, модулей и т.д.). И искать решение под эту структуру. Чтобы CMF не превратился в Laravel (с которым всё равно не получится тягаться). А вот растерять существующее сообщество получится очень быстро.

                          Теперь попробуйте представить, что вы первая категория пользователей, которые составляют 40%. Задайте им вопрос (я сам таким был; я помню каково это). Всё, что вы говорите они даже понять не могут. Им нужно больше мануалов и готовых кейсов.
                          Для них админка тормозит в большом каталоге. Это да.
                          И с мобилки коряво админка отображается. Это два.
                          Сайт начинает тупить при 20000 тикетов или если вызов коряво оформил. Это три.
                          И как-то сложно всякие &where прописывать.
                          Да, и пожалуй, всё. Остальное (сказал бы я в то время), пожалуйста оставьте как есть. И побольше готовых решений, в которых нужно как можно меньше кодить рукой.

                          Вторая категория (20%) совсем зелёных программистов.
                          Всё то же самое. Пожалуйста, больше мануалов и дайте разобраться. Мне и так сложно.

                          Третья категория (20%) программистов среднего уровня.
                          Больше возможностей для кастомизации админки, желательно на чем-то внятном. Лучше без extJS. Что-то понятное и более легкое. Но чтобы структура осталась та же. И что-то с шаблонизатором, пожалуйста.

                          Четвертая категория (20%) грамотный разработчик.
                          По большому счёту, то же самое, что и третья категория, но есть вопросы к реализации взаимодействия с БД.
                          Остальное — индивидуально и встречается редко.

                          Есть, конечно же, гуру. Но они мыслят не категориями CMF. А отдельным API, кодингом в текстовом редакторе, параллельными запросами и прочими интересностями для интересностей (и для 2% проектов из всех проектов, которые можно было бы сделать на MODx).

                          Напомню, это всего лишь скромное мнение. Не удержался, т.к. давно на MODx и искренне люблю этот проект. :)
                            Pavel Zarubin
                            15 сентября 2022, 22:41
                            0
                            Большое спасибо за столь развернутое мнение! В целом согласен полностью, но есть одно НО, ради которого и затевалась вся эта идея. Да, ты прав, 80% разработчиков — это не нужно, но ты не учитываешь тот факт, что 20% из последней категории задают все остальное развитие для тех 80%, создают инфраструктуру и улучшают и расширяют платформу, а их как раз modx и не уважает, именно по этому он растерял большую часть своей аудитории из тех 20%.
                            Я сужу по себе например, как только я научился +- программировать, как только технически вырос до того, чтобы создавать архитектурно серьезные дополнения с правильным кодом, с правильным подходом, с соблюдением PSR и ООП modx дал мне под сраку, как ты его не верти, как не крути, но ты постоянно упираешь в хреновые архитектурные решения, постоянно упираешься в отсутствие PSR, в хреновый установщик, в отсутствие нормального дебага и т.д.
                            Я думаю из тех, кто ушел, таких как я — большинство, этот след прослеживается по их коду и их компонентам, а без них не будет никакой инфраструктуры, не будет нормального магазина, не будет нормального билдера запросов, чтобы where было не сложно было писать, а также не будет производительных запросов, чтобы тикеты при 20000 через pdoTools не тупили. Так вот главная твоя мысль, как я понял, дорабатывай то, что есть. Но то, что есть устарело безумно.
                            Я правда пытался, года два назад сообщество взяло под контроль разработку modx 3, в то время я хотел переработать XPDO, разработать REPL утилиту, разработать аналог tinker'a для modx (был опыт внедрения в Yii, по этому четко понимал что хочу получить), нормальную ротацию логов и логирование в целом и еще много всего было в планах, прошла неделя, две, три, а я не код писал, я боролся с ужасным легаси, который невозможно не уничтожив переписать
                            Просто нужно признать что MODX устарел сильно безвозвратно, его надо уничтожить и создать копию с теми же идеями, но с нуля, а если писать с нуля, какой смысл делать это на PHP, который и сам все больше с каждым годом уходит в стагнацию, а nodejs и go оттяпывают куски обрастая сильным комьюнити и инфраструктурой
                              Wassi Wassinen
                              16 сентября 2022, 20:12
                              +1
                              Павел, я хочу сказать, что вы молодец. Идея классная.
                              В целом — воодушевляет, что есть люди готовые к такому свершению.
                              Мой предыдущий пост не о том, что ничего не нужно делать. Скорее о том, чтобы не поломать изюминку MODx и не усложнить жизнь большинству.

                              Если всё же решитесь и будет нужна консультация по части юзабилити, интерфейсов, маркетинга и автоматизации процессов — пишите в личку. Чем смогу, помогу. Можно не только по вопросу MODx :)
                                Wassi Wassinen
                                16 сентября 2022, 20:16
                                +1
                                Так же, речь шла о том, что можно сначала попробовать, например, заменить админку. И двигаться постепенно шагами, которые не требуют столь глобальных трудозатрат и действий.
                                В рамках своего скромного понимания процесса — есть возможность допилить MODx без таких глобальных изменений. Убрав 80% проблем.

                                А уже после можно думать о том, чтобы переписывать всё с нуля. Если в этом останется необходимость.
                              Misha Bulic
                              16 сентября 2022, 19:03
                              0
                              Ещё вопрос, как будет реализован функционал тем для сайта?
                                Pavel Zarubin
                                17 сентября 2022, 13:13
                                0
                                Пока этого вопроса даже не стоит, первоочередная задача сохранить — то, что есть сейчас
                                  Misha Bulic
                                  17 сентября 2022, 19:48
                                  +1
                                  Ну дак а смысл переписывать один в один. Тут и так всё работает. А вот над функционалом тем нужно думать и закладывать в архитектуру. Популярность вордпресса как раз в темах платных. Чтобы сайт могли установить даже школьники. То что там будет GO 80% по барабану.
                                  Без тем будет ещё одна система для разработчиков.
                                    Алексей Смирнов
                                    26 сентября 2022, 13:28
                                    0
                                    Думаю, что в MODX это будет в любом случае отдельный компонент.
                                    Например как сейчас есть для modx2 MagicThemes.
                                Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
                                39