Про перспективы MODX 3

Последние полгода работаю в голландской компании Sterc, в основном, с MODX 3, хотя и не собирался. Не то, чтобы мне это очень нравилось, но деньги платят отличные.

Sterc интенсивно проводит апгрейды своих клиентов на 3ю версию MODX, в ходе которых обнаружилась очень неприятная проблема, и это — Composer. Да-да, тот самый composer, который мы дружно в MODX запихивали, стал причиной больших проблем. Точнее, не он сам, а его реализация.



Несмотря на прикрученный composer, MODX 3 всё еще использует свой собственный формат дополнений. Более того, MODX не устанавливает composer.json по умолчанию, предлагая уже скачанную директорию core/vendor со всеми зависимостями.

Любое дополнение, которому тоже нужные какие-то зависимости, также притаскивает их с собой, в архиве. В момент инициализции ядра, система проходит по всем зарегистрированным namespaces и пытается подключить из них файл bootstrap.php, который загружает всё, ему нужное.

Установлено 10 дополнений — будет загружено 10 bootstrap.php, каждый из которых может подгрузить в систему свои зависимости. Чуете, чем попахивает?

Правильно — зависимости дополнений могут быть одинаковыми, но разных версий! Из-за того, что у вас нет одного общего composer.json, вы не можете разрулить зависимости. И если 2 пакета будут требовать, ну не знаю, nesbot/carbon или ramsey/uuid разных версий, один из них может поломаться, обращаясь к несуществующему методу.

Еще раз — 2 пакета требуют 1 зависимость, и загружают её по очереди, но разных версий. MODX никакой проверки не делает, и в любой момент ваш сайт может сломаться. Вы никак не можете это отследить и предупредить, о потенциальном конфликте никто не знает, пока он не произойдёт.

Лично я столкнулся с этим впервые, когда ядро MODX подключалось внутри очередей Laravel для всяких консольных дел, типа импорта больших данных. Это отлично работало на MODX 2, но после перехода на 3ку всё сломалось, потому что они оба загружали thephpleague/flysystem разных версий.

Именно для этого и нужен единый общий composer.json, чтобы проверить все требуемые версии и разобрать конфликты. Но у нас его в системе нет.

Или есть?

На самом деле любой пользователь MODX 3 может запросто скачать свежий composer.json из официального репозиторий и сделать composer update, чтобы обновить зависимости системы. Ничего не сломается, при условии, что зависимости от вашей версии MODX. Новый MODX обновлялся пока только 3 раза, не думаю, что там разные пакеты.

Ладно, обновились — а как это поможет в установке сторонних дополнений? А дополнения тоже должны устанавливаться через composer. Насколько я знаю, таких дополнений раньше просто не было. А пару дней назад появился первый пример — sterc/csp. Меня попросили написать пакет для управления заголовком Content-Security-Policy и особо не ограничивали, так что я придумал новый вид дополнений для MODX.

Установка через composer
composer require sterc/csp --with-all-dependencies

Установка в CMS производится консольным скриптом, который идёт в комплекте:
composer exec sterc-csp install



Будут созданы нужные таблицы, прописан namespace, пукт меню и плагин. Удаление идёт почти теми же командами, но в обратную сторону:
composer exec sterc-csp remove
composer remove sterc/csp

Это всё. Никаких проблем с зависимостями (а если и будут — вы разрулите их до установки пакета), не нужно заходить в админку для установки\удаления, нет привязки к репозиторию MODX. Кликаем на GIFку внизу, чтобы увидеть саму работу дополнения.



Можно брать исходники и писать свои дополнения, там всё нарочно избыточно: и TypeScript с Vue 3, и полноценное API через Vesp, и модели Eloquent — можно делать любой функционал. По идее, тут можно написать еще несколько заметок «как именно этим разрабатывать», но мне пока лень.

Дальше всё зависит от вас. Или подобный формат дополнений приживётся, или MODX 3 будет нестабильным глючным куском кода, который можно сломать установкой новой версии дополнения в любой момент.
На мой взгляд очевидно, что старый формат транспортных пакетов дополнений в MODX 3 использовать нельзя, и всех нужно переводить на composer.

Ну а лично я дорабатываю последнюю неделю и увольняюсь, с MODX мне работать не нравится. Отдохну месяцок и продолжу заниматься развитием Vesp.
Василий Наумкин
23 июня 2023, 19:35
modx.pro
1
1 739
+17

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

Дима Касаткин
23 июня 2023, 19:55
0
Спасибо Василий! Уже можно сказать десятилетиями, привносишь в MODX полезные и прогрессивные вещи. Системный подход твоих решений — впечатляет.

Очень надеюсь что формат приживется. А ещё надеюсь, получится сделать для этого формата дополнений GUI, чтобы его использование было также дружелюбно и к тем, кто с консолью обращается не часто… И дополнения «привычно» можно было ставить из админки.

Кажется, описанное в заметке решение — будущее дополнений для MODX3. Надеюсь, как минимум MODSTORE заинтересован в поддержке такого формата!
    Іван Клімчук
    23 июня 2023, 21:42
    +3
    Это будущее давно уже настоящее везде, где есть Composer. А для платных (ну или просто приватных) репозиториев есть даже такая тула — github.com/composer/satis.
    Ну или можно заплатить денег пакаджисту и публиковать там packagist.com/pricing
    Вопрос в том, что аудитория MODX всячески сопротивляется подобным нововведениям, потому что это ж программированию учиться нужно, а они привыкли на коленке все собирать, чтобы хоть как-то работало, особо не вдаваясь в нюансы.
      Дима Касаткин
      23 июня 2023, 22:39
      0
      потому что это ж программированию учиться нужно, а они привыкли на коленке все собирать
      Иван, ну не стоит преувеличивать. Конечно, программисты с личным развитием всё время хотят усложнять свои проекты, и одновременно упрощать свои инструменты. Поэтому да, конечно для тех, кто развивает платформу, в т.ч. MODX, желание привнести крутых навороченных штук, не обращая внимания на порог вхождения, естественно) Однако если посмотреть с другой стороны: для вас, крутых разработчиков, и для некоторых других (например, с очень большой натяжкой, для меня, еле догоняющего) это «проект», а для очень многих — инструмент!

      Ничего плохого в том, чтобы инструмент оставался простым, до определенного, конечно, предела, вовсе нет!
        Дима Касаткин
        23 июня 2023, 22:41
        0
        Я к тому, что до текущего момента, можно было комфортно на хорошем уровне делать проекты с MODX, применяя ряд инструментов: тот же PHPstorm, git GUI «fork», WinSCP и админку MODX, с приятными интерфейсами, не являясь при этом консольным гиком, которому достаточно созерцания прекрасного в мигающем курсоре на черном фоне.

        Все-таки composer это совсем не про программирование, а тоже инструмент, который в рамках MODX, мог бы, условно, мало чем отличаться от текущего менеджера пакетов с функционалом зависимостей.

        Вон сделали же GUI modxminify чтобы не собирать вручную в коде бандлы как в minifyx. Я вот не пользуюсь им, но много где видел, и соглашусь что это блин удобно для проектов где не обязательно весь код держать под git-ом (А такие бывают? — бывают)))

        Идея контролировать git-ом через composer.jsom даже версии установленных пакетов в систем мне лично очень нравится, но полностью отказываться от удобного GUI-менеджера пакетов навсегда, все-таки больше похоже на шаг назад. MODX не конкурирует с Laravel, в котором куча консольных инструментов и даже веб-сервер вроде как есть свой вместо nginx/apache, это давно ясно и ничего плохого в этом нет. А вот проигрывать в удобстве админки ещё и Wordpress было бы вообще печально.
      Баха Волков
      23 июня 2023, 21:15
      0
      Мне интересно, если они в курсе, то как объясняют сложившуюся ситуацию
        Іван Клімчук
        23 июня 2023, 21:44
        +3
        Баха, никак. Я раньше подобное предлагал, когда ездил на тусовки. Ответ был такой, что это сложно, это ж программирование изучать нужно, команды какие-то запускать, а мы привыкли кнопочки клац-клац и красиво.
        Александр Мельник
        24 июня 2023, 10:19
        +1
        Насколько я понимаю, должно произойти нечто подобное, что произошло с opencart.
        Есть opencart, разрабатываемый американским разработчиком, есть отдельный (форк? не люблю я этот жаргон, скоро совсем уже нормальных слов не останется) — ocstore, который хоть и базируется на opencart но делается отдельными разработчиками, со своими модулями и дополнениями.
          Дима Касаткин
          24 июня 2023, 15:38
          0
          Может и должно, но не происходит)

          Потому что на MODX и в том виде, как сейчас есть, довольно комфортно работается… может не всем, как всегда :)

          Да и новая версия недавно вышла, сейчас есть смысл развивать и адаптировать дополнения, чем и занимается в основном местное сообщество! И здесь с ocstore можно провести аналогию в том, что для minishop (который сам является дополнением к MODX) есть и появляются новые свои дополнения. И не только он, есть и другие компоненты, которые образуют свою экосистему, работая дополняя друг друга.
            Дима Касаткин
            24 июня 2023, 15:41
            0
            Я на всякий случай уточню, что оригинальный менеджер пакетов, который был и есть в MODX2, в MODX3 никуда не делся и он работает ровно также, как и 10 лет назад. Для кого-то в этом и проблема (типа старый уже, надо менять), а кто-то видит в этом стабильность)))

            Предложенное автором поста решение актуально при использовании новой, альтернативной возможности подключать внешний код в MODX-проекты. Эта возможность встроена в движок с версии MODX3, но как следует из поста, имеет проблемы, которые к нашей всеобщей полагаю радости, при прямых руках и светлой голове, решаемые :)

            А получившийся метод реализации как мне кажется, имеет больший потенциал т.к. вылился в некий альтернативный способ установки дополнений, основанный на развитом и популярном менеджере пакетов composer, который ещё даже не существовал или был в зародыше (судя по wiki), когда в MODX появился в текущем виде свой пакетный менеджер с установкой дополнений через админку.
              Василий Наумкин
              25 июня 2023, 05:38
              +4
              Дима, ты всё перепутал.

              В MODX 3 старый «стабильный» менеджер пакетов приводит к возможности добавить в систему конфликтующие дополнения. Как с самой системой, так и друг с другом.

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

              Перечитай еще раз, если не понял, о чём я пишу.
                Дима Касаткин
                26 июня 2023, 21:33
                0
                Спасибо, перечитал несколько раз, и если на этот раз правильно понял :), то всё что я написал выше, верно, но только для пакетов, собранных «по-старинке» без автозагрузки через bootsrap.php, так?

                Сейчас для MODX3 большинство дополнений как раз такие (т.к. адаптированы, но сделаны были для MODX2) поэтому проблема и не проявляется массово?

                Я ещё перед тем как первый коммент написать, я проверил исходные коды популярных дополнений: FormIt, Minishop2, MIGX, pdoTools, ImageCropper, Formalicious, CKEditor Resizer и некоторых других и нигде нет bootstrap.php которые по 10 раз должны (или могли) бы загружаться, как описано в статье.

                Может кто-нибудь привести примеры хотя бы 1 или лучше 2 дополнений, где есть автозагрузка через bootstrap.php, которые потенциально могут сломать друг друга? Мне тема показалась довольно серьезной, хочу проверить!
                  Николай Савин
                  27 июня 2023, 10:15
                  0
                  Автозагрузка обычно через Autoload.php происходит. Я вот тоже не разу ни встречал bootstrap.php.
                  А так композерных пакетов внутри MODX с наличием composer.json сколько угодно. ZoomX, modRetailCRM, HibrydAuth навскидку
                    Дима Касаткин
                    27 июня 2023, 12:27
                    0
                    Так эти пакеты аффектятся описанной особенностью работы MODX 3 с композером или нет?

                    Если я правильно понял, самого факта того, что где-то в подпапках лежит конфиг composer.json и разработчик для обновления вендорных исходников вручную запускает composer, не достаточно, чтобы возникла возможность коллизии.

                    А чтобы эффект проявился, нужно чтобы пакет специально использовал в новом стиле composer:
                    система проходит по всем зарегистрированным namespaces и пытается подключить из них файл bootstrap.php
                    Такие пакеты кто-нибудь встречал? Дайте ссылку плиз, я не могу найти
                      Василий Наумкин
                      27 июня 2023, 12:48
                      0
                      Таких пакетов уже довольно много, хоть бы и новый pdoTools. Видишь, здесь грузится свой собственный autoload.php, который может содержать любые зависимости?

                      Теперь представь, что так может делать любое дополнение в MODX 3. Кто-то будет тестировать свой пакет на совместимость со всеми остальными в репозитории? Очень сомневаюсь.

                      А значит, с каждым новым дополнением, с каждой новой версией, с каждым месяцем у тебя всё больше шанс словить проблему.

                      Это есть и во 2й версии, просто там этот шанс гораздо ниже, но отнюдь не нулевой.
                    Василий Наумкин
                    27 июня 2023, 12:55
                    0
                    1. pdoTools
                    2. Collections
                    3. Tagger
                    4. SimpleSearch
                    5. FormIt
                    6. SeoSuite
                    7. Formalicious
                    8. GoogleAnalytics
                    9. ModxDashboardWidgetsPack
                    10. QRNFCGenerator
                    Это те, что на вскидку вспомнил, потому что работал с ними недавно. Если покопаться, найдутся еще.
                      Дима Касаткин
                      27 июня 2023, 13:48
                      +1
                      Хм, cтранно, что поиск на github не находиn bootstrap.php

                      Ну теперь очевидно, что даже приведенный список пакетов означает актуальность уровня «уже» а не «скоро», как в начале показалось. И со временем будет расти…

                      Тогда получается, что одним best practice by Василий не обойтись, ведь родной менеджер пакетов всё ещё работает, и надо всё равно во встроенный механизм автозагрузки как-то добавлять проверку.

                      Беглый гуглинг показал, что не только с MODX 3 так бывает ¯\_(ツ)_/¯ например у движка Википедии похоже было подобное (ссылка ниже)

                      Но существуют решения (которые прямо сейчас в MODX конечно не поддерживаются):
                      • как встроенными средствами composer-а через специальный формат записи конфигурации ( stackoverflow )
                      • так и инструменты, помогающие это автоматизировать, например wikimedia/composer-merge-plugin

                      Наверное с эти уже пора отправляться с issue к MODX Core team, чтобы уточнить возможность прикрутить это, или нечто подобное к существующему механизму, если не для автоматизированного решения проблемы, то хотя бы для вывода предупреждений о конфликтах версий зависимостей при установке пакета… Или уже обсуждается, и я опять не осилил поиск на гитхабе?)))

                      В любом случае, ещё раз спасибо @Василий Наумкин и @Николай Савин за пояснения!
              Stanislav Ovv
              26 июня 2023, 09:35
              0
              Мне одному кажется, что, куда не сунься, от MODX 3 непросто попахивает, а прям смердит.
                Дима Касаткин
                26 июня 2023, 21:43
                +2
                Вы специально зарегистрировались, чтобы это написать? Попробуйте лучше MODX 3 в деле! Это быстрый и удобный движок, на котором легко запускать простые и сложные сайты. А техническое несовершенство и постоянные новые и суровые вызовы для программистов найдутся и в любом другом движке. Разного рода запахи короче говоря, есть абсолютно у них у всех)
                  Stanislav Ovv
                  26 июня 2023, 22:08
                  -1
                  Да я одно понял, читая заметки, что основные знаменитые модули/сниппеты из маркета у ребят нет особого желания нормально допиливать с 2 на 3, так как не видят смысла и профита в этом. А ждать 4 версию в обозримом будущем не скоро, т.к. западные мейнтэйнеры уже старые, ленивые пердуны без особых идей и молодого запала, которым особо своё детище похоже не интересно. Да и на 2ке новые проекты делать уже такое себе занятие, конечно можно, так как уже все проверенно временем и стабильно работает. Кончился похоже modx.
                    Артур Шевченко
                    26 июня 2023, 23:02
                    +3
                    Сколько вы в этом году задонатили сообществу, чтобы адаптация того же MiniShop2 с 2 на 3 шла активнее? Или сколько PR отправили, чтобы помочь с адаптацией? Давайте угадаю — нисколько. И не смотря на это, работа идёт. Более того, pdoTools, FetchIt и MigX уже адаптированы, а этим набором можно очень много всякого реализовать.
                    А 4-ю версию ждать в ближайшее время и правда не стоит, но Modx ещё поживёт.
                      Дима Касаткин
                      27 июня 2023, 01:53
                      0
                      Западные мейнтейнеры и правда не особо отжигают) Тут сложно спорить :) Но релиз выпустили, работы идут, и фиксы и фичи есть, то что работает — не ломают (тоже не плохо, так не везде удаётся :)))

                      Да и на 2ке новые проекты делать уже такое себе занятие, конечно можно, так как уже все проверенно временем и стабильно работает.
                      А «такое себе занятие», в смысле что мало развлечения, «слишком» проверено и стабильно? Ну такой себе недостаток :)

                      На самом деле есть что улучшать и в двойке, и возможно некоторые фичи, которые попали в 3й релиз, вышли бы лучше для двойки (имхо), но так или иначе релизу 3 уже больше года, смысл говорить о 4 есть только в разрезе решения каких-то глобальных проблем, а даже описанные в статье косяки с composer возможно при исправлении потянут всё-таки на релиз минорной версии, т.к. в ряд ли обратная совместимость сломается от реализации проверки версий подключаемых пакетов…
                        Максим
                        07 июля 2023, 08:19
                        +3
                        Кончился похоже modx.
                        Wordpress вон живёт и вроде не скоро еще собирается умирать)) Хотя, на мой взгляд, там проблем поболее… Так что…
                          alex87.ru
                          19 сентября 2023, 22:30
                          0
                          Проблемы есть везде) Wordpress много движков переживет, только из-за того что самый распиаренный и имеет тьму тем и дополнений) Школьник сможет сайт наклепать за день (часто за пару минут с премиум шаблонами, которые плагины поставят, все настроят и демо данные импортируют). С MODX немного другая история… С 3й версией, пока правда все печально для начинающих особенно: они ее ставят по старым инструкциям, ставят несовместимые плагины и все ломается) или обновляют рабочий сайт на 2йке и каюк сайту)) Даже в оф документации по 3ке по дополнениям (https://docs.modx.com/3.x/en/extras), указаны несовместимые компоненты (и их там хватает)
                            Максим
                            20 сентября 2023, 08:53
                            0
                            Да, проблемы есть в modx-3…
                    Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
                    24