Конфликт зависимостей Guzzle в MODX 3

Сначала хотел просто обновить предыдущую заметку, но решил, что это достойно более широкого обсуждения.

Итак, юзер @Futuris установил новенький mmxForms и словил Fatal Error 500 на сервере, при попытке создать форму.

В логах нашли вот такое сообщение:
PHP Fatal error:  
Declaration of Slim\Psr7\Uri::withScheme($scheme) must be compatible with
Psr\Http\Message\UriInterface::withScheme(string $scheme): Psr\Http\Message\UriInterface
in ...
Как же так? Почему у меня работает, а у него нет?

mmxForms добавляет через Composer зависимость vesp/core, та использует Slim 4, который реализует UriInterface из Psr\Http\Message. У меня всё работает без проблем, а у юзера — фатальная ошибка.

На его сайте, почему-то, к объявлению метода withScheme добавился return type (вот этот вот хвостик : Psr\Http\Message\UriInterface), но у меня на компе функция выглядит вот так (без хвостика):


Слева — интрефейс PSR, справа — реализующий его метод в Slim 4. Хвостиков нет.

Что же это за магия, почему у юзера на сервере один из методов вдруг объявил себе тип возвращаемого значения?

А это не магия, просто на сайте еще установлено дополнение UpgradeMODX, которое тащит с собой дополнение Guzzle7, внутри которого другая версия библиотеки psr/http-message.

MODX запускается, загружает зависимости из core/vendor среди которых уже есть psr/http-message, потом опрашивает установленные дополнения и тогда Guzzle7 загружается в память, заменяя уже имеющийся там класс Psr\Http\Message\UriInterface!

И вот мы получили Fatal Error из-за пакета, который в MODX 3 вообще не нужен, потому что guzzlehttp/guzzle уже указан в системном composer.js.

Оцените весь сюрреализм ситуации: в систему ставится дополнение, которое мало того, что не нужно в ней совершенно, так оно еще и подготовлено для работы с MODX 3, и поэтому заменяет версии системных зависимостей при каждой инициализации ядра!

Вот это класс, вот это Content Manager Framework для разработчиков!

Так что если у вас есть желание поиграться с mmxForms на сайте с установленным UpgradeMODX, придётся пока отказаться от его использования и удалить дополнение Guzzle7 из админки.

Задал вопрос автору Guzzle7, зачем его дополнение вообще адаптирвоано для работы в MODX 3, если оно там не нужно и может ломать систему?

Ну и сделал Pull Request в UpgradeMODX, чтобы он не тащил ненужное в 3ю версию. Кто не хочет ждать Боба Рэя — вот уже собранный пакет без Guzzle7, можно установить вручную.

В общем, как я и предупреждал, чем больше в MODX 3 устанавливается дополнений в обход Composer, тем больше шансов у него поломаться в неизвестном месте.
Василий Наумкин
22 марта 2024, 11:29
modx.pro
1
1 062
+19

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

Максим
25 марта 2024, 08:50
0
А можно подробнее? Каким образом можно будет избежать конфликтов, даже если все дополнения будут устанавливаться через Composer? Если МоёДополнение, например, использует зависимость версии 1, а ТвоёДополнение требует версию 5, где половина методов из версии 1 отсутствует, Composer как-то будет устанавливать 2 версии одной зависимости? И как потом этим пользоваться?
    Василий Наумкин
    25 марта 2024, 10:29
    0
    Каким образом можно будет избежать конфликтов
    Composer просто не позволит установить конфликтое приложение, и ничего не сломается.

    Нужно будет поискать более подходящее приложение, или попросить автора адаптировать своё. Например, указать другие возможные версии зависимостей, как уже сделал я с vesp/core, для нормальной работы в MODX 3.
    Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
    2