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

Ви повинні бути добре обізнані з рефакторингом, який ми робимо щодо WordPress Widget Boilerplate. Якщо ні, я рекомендую наздогнати серію до цього моменту:

• читаючи попередній пост ,
• або прочитати всю серію до цього моменту,
• і дивлячись на розробку гілки проекту на 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

Це створить саме те, що нам потрібно, щоб наш проект працював у виробничому середовищі. Ось що робить кожен прапор:

• встановлення композитора. Це просто встановлює всі залежності. Якщо у вашому каталозі постачальників уже є кілька з них, це видалить усі, окрім тих, які потрібні.
• no-dev. Це не дозволить Composer встановити пакунки в розділі require-dev своїх конфігураційних файлів (а саме, залежностей, які ми використовуємо з GrumPHP).
• ні-ансі. Це запобігає будь-якому виводу ANSI. Вам може бути байдуже запускати це чи ні. Якщо ви вирішите виконати певний тип автоматичного розгортання, використовуйте його; інакше його можна пропустити з команди.
• відсутність взаємодії. Це ще один прапорець, який використовується спеціально для середовищ, у яких ви хочете автоматично створювати проект і не потрібно займатися будь-якими запитаннями, результатами тощо.
• optimize-autoloader. Коротше кажучи, це генерує швидший автозавантажувач. Це може зайняти деякий час, залежно від розміру вашого проекту, але це окупиться під час запуску вашої роботи.
• без прогресу. Це приховає панель прогресу від показу в терміналі. Можливо, ви дійсно захочете це побачити, і якщо так, то це чудово; однак деякі середовища можуть погано обробляти певні символи (наприклад, Backspace).
• prefer-dist. Це гарантує, що інстальовані пакунки створюються за допомогою версії дистрибутива (а не менш стабільної).

все ще зацікавлені?

Якщо вам справді цікаво оптимізувати автозавантажувач для проектів поза цією публікацією, я рекомендую прочитати цю сторінку в документації Composer. Це виходить за межі того, що ми тут робимо, але може стати в нагоді під час іншої роботи, яку ви виконуєте зараз або виконуватимете в майбутньому.

Як це виглядає в Boilerplate?

Якщо ви працюєте над Boilerplate на своїй локальній машині, ви можете побачити щось на зразок цього:

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

Це велика різниця, і це невеликий проект. Уявіть, що ви робите щось набагато більше, що буде працювати у виробництві.

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

Чи включимо ми в наш каталог постачальників?

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

Навіть документація Composer говорить про це:

Найкраще, щоб усі розробники використовували Composer для встановлення залежностей. Подібним чином сервер збірки, CI, інструменти розгортання тощо повинні бути адаптовані для запуску Composer як частини завантаження проекту.

Отже, що ми маємо робити? Нам потрібен автозавантажувач і певні залежності, тому що наші користувачі не будуть знати, що запускати (і не повинні запускати!) Composer кожного разу, коли вони завантажують нашу роботу.

Через природу WordPress і роботу, яку ми виконуємо, нам потрібно буде закріпити каталог постачальників, але лише з дуже певними вимогами.

1. Ми створимо гілку, яка використовуватиметься для випуску (ми творчо назвемо це випуском, і ми зможемо об’єднати з ним development, коли це буде потрібно).
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 і теми, які обговорюються в цій публікації,
• випуск — це те, що буде використано для забезпечення робочої демонстрації.

Однак наразі перегляньте, що описано в цій публікації, і ми продовжимо це в наступній публікації.