С момента своего появления в 2003 году WordPress прошел долгий путь развития.

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

В результате растущей популярности, за последние пару лет я и моя команда стали регулярно получать заказы на строительство все более сложных WordPress веб-сайтов и приложений. По мере увеличения размеров этих проектов увеличивались и практические умения нашей команды. Однако мы заметили, что сохранение различных зависимостей конкретно взятого проекта в режиме синхронизированной разработки становится для команды все труднее. Когда разработчики присоединялись к проекту в произвольный момент времени, версии плагина становились не синхронизированными, и приходилось использовать различные релизы WordPress ядра. Вскоре мы поняли, что ситуация быстро выходит из-под контроля, что приводит к появлению ряда расхождений в базах кода, а также повышению вероятности появления ошибок в наших проектах.

В этой статье я поделюсь с вами историей о том, как моя команда использовала инструмент для управления PHP зависимостями под названием Composer. Этот инструмент позволяет упорядочить процессы разработки, а также поддерживать последовательность и надежность сохранения зависимостей WordPress проекта, над которым работает целая команда разработчиков.

Данная статья структурирована следующим образом:

• Мы начнем с контекстной информации, связанной с кратким введением в особенности управления зависимостями. В том числе мы постараемся разобрать, почему это важно и какие выгоды у вас появляются от этого процесса.
• Далее мы познакомимся с инструментом Composer и прежде чем перейдем к особенностями использовать его для управления WordPress зависимостями рассмотрим базовые основы.
• Наиболее важная часть статьи, в которой будет приведено описание модификации существующего проекта с использованием Composer для управления зависимостями (для этого мы воспользуемся GitHub репозитарием).
• Мы рассмотрим способ аккуратного определения самого WordPress ядра как Composer зависимости, а также узнаем, как сохранить собственные плагины, используя приватные GitHub репозитарии.
• Мы рассмотрим список специализированных ресурсов, которые позволят вывести ваши навыки работы с Composer на более высокий уровень.

Если вы готовы, то давайте начнем.

Что такое зависимость?

В первую очередь начнем с самого важного. Давайте определим, что мы понимаем под термином «зависимость». Как правило, зависимость – это библиотека, фреймворк или компонент, который обычно предоставляется третьей стороной, и от которого зависит функциональность вашего веб-сайта. Зависимость может представлять собой простую библиотеку преобразования данных или целостный фреймворк.

Представьте себе типичный веб-сайт, который зависит от нескольких библиотек. Каждая из этих библиотек в свою очередь обеспечивает стандартные функциональные возможности, на которых основывается ваш код. Эти элементы являются неотъемлемой частью базы исходных текстов веб-сайта. По этой причине очень важно, чтобы все разработчики в любой момент времени работали с идентичным набором зависимостей.

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

Зависимости в контексте WordPress.

Итак, что же собой представляют зависимости в контексте WordPress?

Типичный WordPress проект содержит несколько зависимостей. Они могут включать в себя следующее:

• Плагины. Многие плагины обеспечивают функциональность, которая имеет решающее значение для работы веб-сайтов.
• Темы. Хотя большинство тем уже имеет необходимые настройки, родительская тема может определяется, как зависимость.
• WordPress ядро. Это базовый фреймворк, без которого не будет функционировать веб-сайт!

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

Например, представьте себе ситуацию, в которой Разработчик А и Разработчик Б одновременно работают над одним и тем же WordPress проектом. В этом проекте используется плагин под названием Advanced Custom Fields (ACF — расширенные пользовательские поля). Функциональность веб-сайта зависит от версии 3 этого плагина. Однажды Разработчику А потребовалось реализовать новую функцию, но он обнаруживает, что версия 3 ACF не обеспечивают требуемую ему функциональность. К счастью, новая версия этого плагина может решить проблему. Разработчик А скачивает и обновляет ACF до версии 4 и в два раза быстрее реализует новую функцию. К сожалению, Разработчик Б не знают о модернизации и продолжает работать над другими функциями с помощью плагина третьей версии. В этом случае возникает очень серьезная проблема, поскольку два разработчика работают с различными зависимостями, что, по сути, означает существование двух различных баз исходных кодов. Естественно, что этот пример немного надуманный, но он наглядно демонстрирует суть проблемы.

Небольшие команды с хорошей непосредственной связью между участниками могут легко избежать появления подобных проблем. В больших распределенных командах проблема быстро может выйти из-под контроля и значительно увеличить вероятность появления ошибок в рамках кода проекта — ошибок, которые могут и будут вызывать серьезную головную боль у всех участников проекта (обычно все эти ошибки всплывают в день запуска!).

Преимущества использования инструмента управления зависимостями.

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

Преимущества подхода с использованием инструмента управления зависимостями включают в себя следующее:

• Последовательность. Все члены команды могут быть уверены, что зависимости проекта ограничены определенными версиями. Разработчики получают гарантии того, что работа ведется с идентичной платформой.
• Видимость. Зависимости проекта четко определены в одном месте и, таким образом, легко могут быть просмотрены всеми участниками проекта.
• Простота использования. Управление осуществляется при помощи одного инструмента, который упрощает и оптимизирует установку, а также обновляет процессы.

«Почему я не могу просто выполнить проверку в системе управления версиями и избежать лишних трудностей?»

Этот вопрос часто возникает в ходе дискуссий, посвященных системе управления зависимостями. Вопрос, как правило, задается после следующих размышлений:

Почему я должен решать проблему изучения и внедрения нового инструмента в свой рабочий процесс, когда я могу просто выполнить проверку всех зависимостей непосредственно в системе управления версиями, которая отлично работает?

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

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

Во-вторых, обеспечивается повышенный уровень видимости для тех случаев, когда ваши зависимости модернизируются. Например, вам когда-нибудь приходилось сталкиваться с ситуацией, когда нужно было что-то взять из репозитория, но конкретная библиотека перестала работать, поскольку другой разработчик изменил зависимость и не сообщил вам об этом? Если все ваши зависимости будут зарегистрированы в системе управления версиями, то вполне возможно, что при попытке использования последнего обновления из репозитария, вы не будете уведомлены об обновлении зависимости. Для сравнения, инструмент управления зависимостями требует от вас выполнения определенной команды, которая позволяет обновить зависимости, обеспечивающие (я надеюсь) четкую обратную связь в соответствии с изменениями библиотеки. Такой подход снижает вероятность пропуска изменения в одной из ваших зависимостей и соответственно снижаются риски появления ошибки.

Тем не менее, всегда следует помнить о том, что использование специального инструмента управления зависимостями не обязательно означает отказ от проверки сторонних библиотек в системе управления версиями (или, что вы вообще можете прекратить использование системы управления версиями). Многие разработчики рекомендуют этот подход, поскольку он позволяет избежать использования дополнительных инструментов и как следствие критических точек отказа для процесса развертывания приложения. В этой дискуссии могут звучать различные точки зрения, и каждая из них может быть по-своему верной, поэтому я не буду вдаваться в какие-то подробности.

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

Использование Composer для управления зависимостями.

Наши обсуждения посвящены тому, как WordPress разработчики могут использовать преимущества системы управления зависимостями. Мы рассмотрим, как можно использовать PHP инструмент под названием Composer.

Большинство языков программирования имеет систему для управления зависимостями, а Node.js NPM и Ruby Bundler являются яркими примерами этого. Composer представляет собой PHP представление, и в последние годы оно зарекомендовало себя как инструмент управления зависимостями для PHP.

Composer следует концепции «пакетирования». Отдельные группы (в основном) PHP кода могут быть описаны с помощью манифест файла, который содержит метаданные о каждой упаковке (в том числе собственные зависимости).

Как указано на официальном сайте, Composer предоставляет следующие возможности:

• объявление зависимых библиотек для вашего проекта,
• автоматизация установки зависимых библиотек.

К счастью, эти возможности отлично сочетаются с целями нашей статьи, что, безусловно, является хорошей новостью!

Примечание: я хорошо знаком с PEAR библиотекой, которая в течение некоторого времени была доступна для PHP. Обсуждение основных отличий Composer и PEAR выходит за рамки данной статьи. Для получения дополнительной информации вы можете прочитать статью Фила Сторджина, который также любезно предоставил первоначальный технический обзор, под названием «Пакеты: движение вперед для PHP».

Определение пакета с помощью Composer.

В Composer, каждый проект представляет собой пакет. Чтобы определить пакет, просто добавьте composer.jsonfile в корень каталога проекта. Полная composer.json схема является исчерпывающей, но ключевым элементом все же является оператор require, в котором подробно описываются зависимости проекта, наряду с номером версии или диапазоном. Например:

"require": {
    "vendor/package" : "1.3.2", 
    "vendor/package2": "1.*", 
    "vendor/package3": ">=2.0.3"
}

Обратите внимание, что мы определяем каждый из пакетов, которые нам понадобятся и предоставляем широкий спектр для обозначения версии пакета, от которой зависит работоспособность проекта. Более подробную информацию касательно определения Composer пакетов вы можете получить, обратившись к официальной документации.

Где искать пакеты.

По умолчанию Composer будет выполнять поиск определенных пакетов в Packagist, своем официальном онлайн-хранилище. Тем не менее, существует возможность идентификации своего собственного репозитория (что мы и сделаем позже для установки наших WordPress плагинов с официального репозитория).

Использование Composer для управления зависимостями WordPress проекта.

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

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

Проект: адаптация существующего WordPress проекта под использование Composer для управления плагинами.

Далее мы акцентируем свое внимание на возможности преобразования WordPress проекта под использование Composer для управления зависимостями.

Все фрагменты кода, которые мы будем рассматривать по ходу статьи, доступны в GitHub репозитарии. Вы можете быть уверены в правильности классификации релизов, каждый из которых соответствует ключевым моментам в процессах ниже.

Если вы готовы, то давайте начнем.

1.Пересмотр текущего проекта.

Для ускорения процесса вы можете клонировать копию фиктивного проекта, который я предварительно создал. Для удовлетворения целей настоящей статьи, я буду считать, что у вас уже выполнены все необходимые настройки Git и что вы прежде уже работали с GitHub.

Для начала вы можете клонировать копию фиктивного проекта, который я предварительно создал. (Увеличенная версия изображения).

Чтобы приступить к работе с копией кода, выполните следующие действия:

1. Клонируйте репозитарий .git clone­­ --recursive git@github.com:getdave/smashingmag­-wordpress-­composer.git
2. Поставьте отметку 1.0.0 для тега .git checkout tags/1.0.0

Не забудьте запустить исходный Git клон с помощью --recursive флага, который будет гарантировать, что все подмодули также клонированы.

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

Каталог нашего проекта. (Увеличенная версия изображения).

Первое, что может показаться необычным при просмотре кода, это то, что WordPress ядро хранятся, как Git подмодуль в каталоге wp (если вам не хватает содержимого wp каталога, запустите git submodule update ­­init из корня каталога вашего проекта). Это позволит вам избежать выполнения проверки на наличие WordPress ядра в хранилище. Для достижения этой цели необходимо выполнить пользовательскую конфигурацию, но это относительно простой процесс (если вы заинтересованы в получении дополнительной информации, то Антти-Юсси Ковалайнен написала на эту тему подробную статью).

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

Прежде всего следует отметить несколько моментов:

• Будем считать, что для аргумента используется несколько плагинов, необходимых для обеспечения функционирования веб-сайта.
• Исходный код для всех плагинов был зарегистрирован непосредственно в Git репозитарии.
• У нас отсутствует явный процесс отслеживания и управления версиями зависимостей нашего плагина.

2.Установка и инициализация Composer.

Теперь все готово для того, чтобы начать адаптацию нашего проекта под использование Composer. Если вы еще не установили Composer, то нужно это сделать.

Установка и инициализация Composer (Увеличенная версия изображения).

Раньше установка Composer была довольно сложным процессом, но буквально за последние месяцы она была ощутимо улучшена. Тем не менее, процесс установки может отличаться в зависимости от особенностей конкретно взятой платформы, поэтому лучше всего ознакомиться с документацией по установке, находящейся на официальном сайте. Я предпочитаю использовать Если вы хотите прочитать полностью статью, посетите сайт наших спонсоров