Статья написана от лица Дэвида Хайеса.
Composer пользуется популярностью в широком пространстве PHP разработки. Разработчики, которые в основном сфокусированы на WordPress, скорее всего, уже имеют некоторое мимолетное знакомство с этим инструментом. Возможно, вы натыкались на этот проект ранее, слышали о нем на WordCamp или на встречах. Или, возможно, вы видели некоторые новости на нашем сайте, которые говорили о том, что BuddyPress (и другие проекты) предпринимает шаги по его поддержке.
Composer просто великолепен. Я думаю, что это – самое интересное, что только происходило с PHP в последние пять лет. WordPress тоже великолепен. Я пользуюсь WordPress уже почти десять лет, и я не могу порекомендовать вместо него что-то другое для реализации красивого, многофункционального процесса публикации в сети. Однако я не считаю, что эти два компонента можно объединить друг с другом, как того желают другие, и об этом мы и поговорим в статье.
Не волнуйтесь, если вы не знаете, что собой представляет Composer – мы начнем с его описания. Затем мы немного коснемся того, почему WordPress является такой прекрасной системой, и поговорим о том, как их можно совместить друг с другом — совместить несколько неловко, грубо, но все же.
- Что собой представляет Composer?
- Что делает WordPress великолепной системой?
- Как Composer и WordPress могут работать в связке
- Почему Composer и WordPress не настолько совместимы, как арахисовое масло и желе
- В каких случаях Composer и WordPress являются выигрышной комбинацией?
- Composer следует использовать с умом
Что собой представляет Composer?
В своей самой простой версии Composer представляет собой менеджер зависимостей для PHP. То есть это способ, которым я могу получить внешний код – библиотеки, классы, все то, что нужно вызвать, — написанный другими людьми, убедившись в том, что он будет загружен для моего использования, и мне не придется снова об этом волноваться. Многие другие языки предлагали решения этой проблемы – решения разного качества. В Ruby можно привести Gems. Для фронтэнд-разработки на JavaScript есть некоторая стандартизация Bower. В Python известность набрал pip. Все они играют одинаковую роль, однако их реализации различаются.
Большинство людей работают с зависимостями следующим образом – они используют код других людей, который используется для решения разных проблем. Без инструментов, таких как Composer, все становится неаккуратным и бессистемным. Если вы хотите получить дружественную к пользователям библиотеку обработки даты, вы переходите к поисковой системе, находите несколько сотен строк кода, копируете их в файл, после чего стараетесь понять, как работать с этим кодом, и никогда не узнаете о том, что автор этих строк впоследствии обнаружил гигантскую дыру в защите или установил проблемы с производительностью, да и поправить самостоятельно это у вас не получится.
Менеджеры зависимостей сами беспокоятся о ситуациях, когда код, который вы хотите использовать, ссылается на другие библиотеки, классы и т.д., которые вами не подключены. Это создает серьезную головную боль. Решая эти проблемы, Composer также помогает убедиться в том, что полученные версии программного обеспечения работают со всеми библиотеками вашего приложения.
Благодаря Composer вам не нужно выполнять длительный копипастинг, вы получаете мощное решение всех проблем с зависимостями, и вы можете легко получать улучшения производительности, патчи безопасности, новые возможности и т.д.
К примеру, вы можете сообщить Composer о том, что вы желаете использовать библиотеку парсинга даты, как, к примеру, Carbon, задать код для загрузки зависимостей Composer еще до того, как вы будете работать с ними (с помощью простого включения vendor/autoload.php;), и вы получите готовую среду. Когда Carbon или любая другая зависимость будут обновлены, вы сможете быстро получить новую версию при помощи запуска простой команды обновления в Composer.
Что делает WordPress великолепной системой?
Поскольку вы и так читаете наш блог, буду краток: WordPress – это простая в использовании CMS с богатой экосистемой плагинов и тем, которые позволяют упростить выполнение широкого спектра задач.
Система WordPress создавалась с учетом простоты использования – особенно для конечного пользователя. Средний пользователь WordPress, который теряется при упоминании PHP-кода, может легко изменить внешний вид или поведение сайта, просто установив новую тему или некоторые плагины напрямую через простой пользовательский интерфейс. Даже в случае с коммерческими плагинами и темами конечный пользователь может полагаться на обновления, доступные в несколько кликов. Пользователи получают обновления безопасности для базового кода WordPress, даже не зная об этом.
Как Composer и WordPress могут работать в связке
Как Джош Поллок указал в прекрасной статье о Composer, есть три базовых цели объединения WordPress и Composer:
- Чтобы управлять зависимостями тем и плагинов, которые вы разрабатываете
- Чтобы управлять темами и плагинами, используемыми на сайте
- Для общего управления зависимостями сайта
Мы рассмотрим два последних пункта, поскольку они представляют собой самый популярный способ взаимодействия людей с Composer.
Почему Composer и WordPress не настолько совместимы, как арахисовое масло и желе
Словом, WordPress великолепен и прост в использовании для людей, чуть более продвинутых в техническом плане, нежели средние пользователи. Composer великолепен – просто идеален – для разработчиков. Но разве две прекрасные вещи в своем объединении не приводят к появлению лучшей вещи? Другими словами: мне нравится арахисовое масло, мне нравится желе, и я считаю, что сэндвич с арахисовым маслом и желе – это лучшая еда, изобретенная в Америке. Итак, почему мне не нравится комбинация из Composer и WordPress?
Нельзя сказать, что они бесполезны вместе. Я считаю, что они вполне могут взаимодействовать, но я не думаю, что решение «вести целый WordPress-сайт с Composer», принимаемое все чаще, является правильным. Мы заботимся об одной проблеме — WordPress слишком неуклюж в управлении и развертывании для разработчиков, – создавая другую – неудобный опыт взаимодействия для обычных людей, которые просто хотят установить новый плагин.
В целом, пытаясь втиснуть Composer в WordPress, мы засовываем квадратную деталь в круглое отверстие. WordPress сфокусирован на простоте использования для конечных пользователей – достаточно перейти в панель администратора, найти плагин в репозитории WordPress.org или загрузить zip-архив, полученный от продавца, — что концептуально противоречит использованию Composer для установки WordPress.
Изменение поведения, а также требование более глубоких знаний делает Composer противоположностью простого опыта взаимодействия для большинства людей. Для сайтов, где имеются отдельные разработчики или администраторы с обширными навыками, такой подход, возможно, будет мудрым, однако для большинства WordPress-сайтов это будет проигрышной комбинацией.
В каких случаях Composer и WordPress являются выигрышной комбинацией?
Даже для большинства ситуаций, связанных с WordPress, я считаю, что Composer показывает себя хорошо только в одной из них: когда у вас имеются некоторые зависимости в теме или плагине. В таком случае я искренне рекомендую использовать дуэт Composer и WordPress. Он идеален. Если у вас есть проект, для которого вам не требуется поддержка вплоть до PHP 5.2, и в котором вам действительно нужен некоторый вспомогательный код, Composer станет для вас идеальным средством получения внешнего кода и легкого поддержания его в актуальном виде (автозагрузка, возможность Composer, которая была нами до этого момента проигнорирована, представляет собой прекрасное дополнение).
Для разработки тем и плагинов Composer подходит идеально. Если вы создаете плагин, который можно было бы улучшить за счет добавления прекрасных библиотек парсинга даты, таких как Carbon, парсера Markdown или каких-то других решений, обязательно используйте Composer для подключения всех компонентов. Для более специфичных WordPress-решений, как, к примеру, CMB2 или TGM Plugin Activation, лучше всего воспользоваться Composer, чтобы избежать древнего копипастинга.
Composer следует использовать с умом
WordPress и Composer не бесполезны при использовании в связке, нет. Однако решение «вести весь сайт WordPress с Composer» подходит только для активного использования WordPress с девелоперскими целями. Если вы уже используете что-то по типу Capistrano для развертывания, шагните дальше и попробуйте Composer. Для казуальных пользователей WordPress, даже для тех, кто уже изменял тему или плагин ранее, Composer станет неудобным излишеством.
Являясь разработчиком, вы должны знать, как использовать Composer для задания комплексных зависимостей в плагине или теме, и затем упаковать все ваши зависимости Composer так, чтобы они не были заметны конечному пользователю. Пусть пользователи пребывают в блаженном неведении относительно того, что вы вообще использовали Composer. Позвольте им сохранить свой удобный и комфортный поток операций WordPress с базовой безопасностью и простыми обновлениями. Именно таким путем мы сможем объединить все самое лучшее от WordPress и Composer!
Источник: wptavern.com