Comments 4
а зачем нужен менеджер пакетов для вп? ну типо там же пхп и вордпресс, зачем туда лишняя прослойка?
Это решает сразу несколько задач:
Ядро и плагины теперь зависимости, которыми можно гибко управлять. Например запретить обновление одного конкретного плагина или откатить ядро на две версии назад одной командой, а потом вернуть как было.
Можно подключать в проект любые php-библиотеки из composer централизованно. Подключить какой-нибудь Sentry например.
Можно делить одну и ту же зависимость между несколькими плагинами. Например, мне нравится шаблонизатор twig, и я хочу использовать его во всех своих плагинах. Чтобы делать это без менеджера зависимостей мне пришлось бы включить код twig'а в каждый плагин в отдельности.
В репозитории хранится только мой код, за который я несу ответственность. Случайное изменение кода сторонних плагинов меня больше не касается, потому что оно не хранится в репозитории и пересобирается из источника при каждом деплое.
Для больших проектов это удобнее во всех отношениях. И для разработки и для тестирования и для доставки на сервер и для обслуживания.
Хороший материал, особенно для тех, кто продолжает воспринимать WordPress исключительно как CMS, которую можно собрать через админку и потом поддерживать по FTP. Отдельный респект автору за подход с Composer + Bedrock и разделением собственного кода и зависимостей. Идея «один блок — один сборщик» тоже выглядит очень здраво для долгоживущих проектов: меньше связности и проще обновлять отдельные части без риска потянуть за собой весь фронтенд.
Большое спасибо
Структура современного WordPress-сайта. Composer, Docker, Bedrock