Виджеты WordPress: рефакторинг, часть 6

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

• читая предыдущий пост ,
• или прочитав всю серию до этого момента,
• и глядя на ветку разработки проекта на GitHub.

Что касается кодовой базы, сейчас мы находимся в хорошем состоянии. Мы начали реорганизовывать большую часть кода в меньшие, более специализированные классы. И мы только что настроили реестр, чтобы мы могли начать работать с экземплярами объектов в плагине без необходимости слишком большой связи.

Но есть проблема, с которой мы сталкиваемся, и она связана с пространствами имен и автозагрузкой. Я немного говорил об этом пару лет назад, но не так, как это относится к Composer.

И это то, что мы собираемся рассмотреть в этом посте.

Шаблон виджета WordPress: рефакторинг, часть 6

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

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

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

И это автозагрузчик.

Определение автозагрузчика

Прямо из мануала:

Для библиотек, в которых указана информация об автозагрузке, Composer создает vendor/autoload.phpфайл. Вы можете просто включить этот файл и начать использовать классы, предоставляемые этими библиотеками, без дополнительной работы:

Если вы до сих пор следили за кодом, то вы увидите, что мы на самом деле уже используем автозагрузчик, сгенерированный Composer.

Сначала мы определили необходимую конфигурацию :

{
    "name": "wordpress-widget-boilerplate/wordpress-widget-boilerplate",
    "description": "An organized, maintainable boilerplate for building widgets using WordPress best practices.",
    "type": "wordpress-plugin",
    "license": "GPL-3.0-or-later",
    "homepage": "https://github.com/tommcfarlin/WordPress-Widget-Boilerplate",
    "authors": [
      {
        "name": "Tom McFarlin",
        "email": "tom@pressware.co",
        "homepage": "https://pressware.co"
      }
    ],
    "support": {
      "issues": "https://github.com/tommcfarlin/WordPress-Widget-Boilerplate/issues"
    },
    "config": {
      "preferred-install": "dist",
      "platform": {
          "php": "7.1"
      }
    },
    "repositories": [
      {
        "type": "composer",
        "url": "https://wpackagist.org"
      }
    ],
    "require": {
      "php": "7.1",
      "composer/installers": "^1.4"
    },
    "require-dev": {
        "friendsofphp/php-cs-fixer": "^2.13.1",
        "jakub-onderka/php-parallel-lint": "^1.0.0",
        "phpmd/phpmd": "^v2.6.0",
        "nikic/php-parser": "^4.0",
        "ocramius/proxy-manager": "^2.0.0",
        "phpro/grumphp": "^0.13.1"
    },
    "scripts": {
      "test": [
        "./vendor/bin/grumphp run"
      ]
    },
    "minimum-stability": "stable"
  }

Затем мы начали включать его в бутстрап плагина (который мы сегодня доработаем):

Но здесь есть проблема: как нам загрузить только те классы, которые нам нужны для распространения?

Иными словами: в процессе разработки мы используем множество библиотек, чтобы гарантировать, что мы пишем высококачественный код, соответствующий стандартам. Но мы не хотим раздавать 10 МБ данных тем, кто использует наш проект.

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

Сначала я покажу вам команду, а затем объясню, что она делает:

$ composer install --no-dev --no-ansi --no-interaction --optimize-autoloader --no-progress --prefer-dist

Это создаст именно то, что нам нужно, чтобы наш проект работал в производственной среде. Вот что делает каждый флаг:

• установка композитора. Это просто устанавливает все зависимости. Если у вас уже есть несколько из них в вашем каталоге поставщиков, это удалит все, кроме тех, которые необходимы.
• нет-дев. Это не позволит Composer устанавливать пакеты в разделе require-dev файлов конфигурации (а именно, зависимости, которые мы используем с GrumPHP).
• но-анси. Это предотвращает любой вывод ANSI. Вам может быть все равно, запускать это или нет. Если вы решите выполнить какое-либо автоматическое развертывание, используйте его; в противном случае его можно опустить в команде.
• нет взаимодействия. Это еще один флаг, который используется специально для сред, в которых вы хотите автоматически построить проект и не задавать вопросы, вывод и тому подобное.
• оптимизация-автозагрузчик. Короче говоря, это создает более быстрый автозагрузчик. Это может занять некоторое время, в зависимости от размера вашего проекта, но это окупается при запуске вашей работы.
• нет прогресса. Это скрывает индикатор выполнения от отображения в терминале. Возможно, вы действительно захотите это увидеть, и если да, то это здорово; однако некоторые среды могут плохо обрабатывать определенные символы (например, backspace).
• предпочитать-расстояние. Это гарантирует, что установленные пакеты будут сделаны с использованием версии дистрибутива (а не чего-то менее стабильного).

Все еще заинтересован?

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

Как это выглядит в Boilerplate?

Если вы работаете над Boilerplate на своем локальном компьютере, вы можете увидеть что-то вроде этого:

Но если вы запустите команду, указанную выше, вы увидите что-то вроде этого:

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

Исходя из опыта, я могу сказать вам, что проекты могут быстро достигать 20 МБ или более зависимостей, если вы используете различные сторонние библиотеки для таких вещей, как ведение журнала, HTTP-запросы и инструменты качества кода.

Включим ли мы в наш каталог поставщиков?

Люди часто говорят, что вам не следует включать каталог поставщика в систему управления версиями, и на то есть веская причина: он может быть огромным.

Даже в документации Composer об этом говорится:

Лучше всего, чтобы все разработчики использовали Composer для установки зависимостей. Точно так же сервер сборки, CI, инструменты развертывания и т. д. должны быть адаптированы для запуска Composer в рамках начальной загрузки их проекта.

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

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

1. Мы создадим ветку, которая будет использоваться для релиза (мы творчески назовем ее релизом, и мы можем объединить с ней разработку, когда это необходимо).
2. Мы позаботимся о том, чтобы каталог поставщика не был частью файла gitignore; однако мы позаботимся о том, чтобы каталоги .git в каталоге поставщика игнорировались (это все еще может занимать много места).

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

Создание ветки релиза

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

$ git checkout -b release

Это займет весь код, над которым мы работаем, а затем создаст с ним новую ветку. Так как это будет ветвь, которую мы используем, чтобы действовать как то, что будут использовать наши пользователи (мы поговорим о master в следующем посте).

Сначала просмотрите файл composer.json и убедитесь, что он включает следующее:

"autoload": {
    "psr-4": {
        "WordPressWidgetBoilerplate": "src/",
        "WordPressWidgetBoilerplateSubscriber": "src/Subscriber/",
        "WordPressWidgetBoilerplateUtilities": "src/Utilities/",
        "WordPressWidgetBoilerplateViews": "src/Views/"
    }
},

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

$ composer install --no-dev --no-ansi --no-interaction --optimize-autoloader --no-progress --prefer-dist

Теперь нам нужно обновить gitignore.

Обновление того, что мы игнорируем

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

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

*.DS_Store
*.log
wp-config.php
wp-content/advanced-cache.php
wp-content/backup-db/
wp-content/backups/
wp-content/blogs.dir/
wp-content/cache/
wp-content/upgrade/
wp-content/uploads/
wp-content/mu-plugins/
wp-content/wp-cache-config.php
wp-content/plugins/hello.php

/.htaccess
/license.txt
/readme.html
/sitemap.xml
/sitemap.xml.gz

/vendor/**/.git
/vendor/bin
composer.lock

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

Затем зафиксируйте свои изменения. Возможно, вам придется указать следующее, если вы работаете в терминале:

$ git push --set-upstream origin release

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

Добавление функциональности

Теперь, когда у нас есть все необходимые элементы, пришло время начать использовать Composer, автозагрузчик, наши абстрактные классы и наш реестр, чтобы начать добавлять некоторые базовые функции в WordPress Widget Boilerplate, чтобы нам было что показать в нашей работе. .

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

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

А пока просмотрите то, что описано в этом посте, и мы вернемся к этому в следующем посте.