Про перспективы 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.