Конфликт зависимостей Guzzle в MODX 3
Сначала хотел просто обновить предыдущую заметку, но решил, что это достойно более широкого обсуждения.
Итак, юзер @Futuris установил новенький mmxForms и словил Fatal Error 500 на сервере, при попытке создать форму.
В логах нашли вот такое сообщение:
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, тем больше шансов у него поломаться в неизвестном месте.
Итак, юзер @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, тем больше шансов у него поломаться в неизвестном месте.
Комментарии: 2
А можно подробнее? Каким образом можно будет избежать конфликтов, даже если все дополнения будут устанавливаться через Composer? Если МоёДополнение, например, использует зависимость версии 1, а ТвоёДополнение требует версию 5, где половина методов из версии 1 отсутствует, Composer как-то будет устанавливать 2 версии одной зависимости? И как потом этим пользоваться?
Каким образом можно будет избежать конфликтовComposer просто не позволит установить конфликтое приложение, и ничего не сломается.
Нужно будет поискать более подходящее приложение, или попросить автора адаптировать своё. Например, указать другие возможные версии зависимостей, как уже сделал я с vesp/core, для нормальной работы в MODX 3.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.