Інструменти для написання кращого коду WordPress: Composer
Хоча я вважаю, що назва цієї серії та статті для кожної з них досить зрозумілі, є інші речі, які я хочу зробити з цією серією, на відміну від інших серій, які я написав до цього моменту.
Зокрема, дві речі, які я намагаюся зробити, це дві:
- зберігайте кожну статтю відносно короткою (порівняно з попередніми статтями),
- зосередьтеся на одному предметі за раз і тримайте його опис коротким.
Оскільки це вміст членства, я не проти, щоб він був трохи довшим, ніж зазвичай, але я також не хочу, щоб він був настільки довгим, що за ним важко стежити. Я хотів би, щоб це було коротке читання з чимось практичним, що ви можете застосувати після читання кожного допису.
І одна з речей, яка дуже допомагає писати кращий код WordPress, це Composer.
Кращий код WordPress із Composer
Якщо ви читали цей блог протягом тривалого часу, то ви знаєте, що я фанат Composer (проте я далеко не єдина людина, яка працює в WordPress).
І хоча я написав про це певний матеріал, я не написав нічого з конкретною метою, щоб ви почали працювати з цим до кінця прочитання однієї короткої статті.
До цього моменту нам доведеться піти на певні компроміси: а саме, я надам зразок файлу конфігурації разом із способом організації каталогу вашого плагіна. Потім у наступній публікації я поясню деякі функції Composer.
Що таке Композитор?
По-перше, важливо зрозуміти, що таке Composer. І легко переказати визначення, як зазначено на сайті, чи не так? Це менеджер залежностей для PHP.
Але по-перше, що таке залежність?
Однак у деяких це викликає кілька запитань:
- Що таке залежність?
- Навіщо мені ними керувати?
І якщо ви копнете трохи глибше, ви можете виявити, що це менеджер пакунків, і це просто викликає ті самі запитання, за винятком того, що ви просто замінюєте «залежність» на «пакет», і ви повертаєтеся з того місця, з якого почали.
Тому я зроблю все можливе, щоб зробити це якомога зрозумілішим:
Залежність або пакет, частина програмного забезпечення, яку використовує ваш код. Це може бути щось, на що він спирається для функціональності під час виконання, наприклад спосіб робити HTTP-запити, або це може бути бібліотека для перетворення масивів у XML.
Composer полегшує включення цих пакетів у вашу бібліотеку, дозволяючи:
- завантажте та включіть пакет у свій плагін,
- автоматично завантажувати плагін під час виконання,
- спростіть для вашого плагіна створення екземпляра або виклик плагіна за потреби.
Це означає, що нам не потрібно засмічувати каталоги нашої кодової бази безліччю файлів, доданих вручну, і це означає, що ми не маємо повсюдного використання включати чи вимагати.
Вони матимуть своє місце, про яке я розповім у наступній публікації, але їх не потрібно буде автоматично встановлювати. Натомість ними керуватиме Composer. Отже, менеджер залежностей є частиною його призначення.
Тепер, коли ви його встановили, у вас є певний контекст.
Використання Composer
Написати цей конкретний розділ дещо складно, оскільки всі ми маємо різні потреби, чи не так? Але принаймні всі ми можемо скористатися автозавантажувачем.
Це те, що ми всі можемо використовувати.
Ось що я зроблю:
- Я створю основний каталог плагінів,
- Створіть необхідні файли для керування плагіном,
- Налаштуйте простий файл Composer,
- Виконайте його
А потім я покажу тобі результати. Ми можемо отримати доступ до бібліотек сторонніх розробників чи інших функцій у майбутній публікації (або майбутніх серіях, насправді).
Але, якщо нічого іншого, це покаже вам, як використовувати Composer для визначення автозавантажувача, щоб ви могли зосередитися на написанні коду, а не на питаннях, чи включені класи.
Каталог плагінів
Зазвичай я структурую свої плагіни так:
- є файл початкового завантаження, який читає WordPress,
- є каталог src, у якому зберігаються всі каталоги та файли PHP,
- є каталог ресурсів верхнього рівня, де зберігаються зображення, файли JavaScript і файли Sass,
- і є папка постачальника, створена Composer для розміщення залежностей і автозавантажувача.
Іноді можуть бути інші дивні папки, як-от папка inc або lib, але це дуже нерегулярно на даний момент у моєму типі роботи. І через це я не буду турбуватися про це для цієї публікації.
Натомість мій каталог виглядає приблизно так.
Каталог постачальника відсутній, оскільки я ще не створив файл Composer, який використовується для виконання. Але ми побачимо це до кінця публікації.
Приклади файлів
Давайте налаштуємо зразок файлу в плагіні. І коли я кажу зразок, я також маю на увазі простий.
Цей файл матиме одну мету: надрукувати повідомлення на інформаційній панелі під час входу в WordPress.
Однак пам’ятайте, що мета цього не полягає в тому, щоб показати, як написати добре архітектурний плагін. Замість цього він показує, як створити автозавантажувач, щоб файли плагіна генерувалися автоматично.
Отже, завантажувальна програма плагіна виглядає так :
А файл, який конкретно відповідає за відображення повідомлення, виглядає так :
А якщо вас цікавить HTML-файл, він також простий :
Я сказав тобі, що це просто.
Конфігураційний файл Composer
Цей конкретний файл може бути як простим, так і складним за потреби. Для цієї публікації ми зробимо це просто. Мета цієї публікації — просто дати їй назву, опис, ліцензію, авторів, а потім, як налаштувати автозавантажувач.
Подивіться сюди, а потім я поясню, що ви бачите трохи нижче:
{
"name": "tommcfarlin/sample-plugin",
"description": "A sample plugin used for a blog post.",
"type": "wordpress-plugin",
"license": "GPL-3.0-or-later",
"authors": [
{
"name": "Tom McFarlin",
"email": "tom@tommcfarlin.com",
"homepage": "https://tommcfarlin.com"
}
],
"autoload": {
"psr-4": {
"SamplePlugin": "src/"
}
}
}По-перше, ім’я, опис, тип і ліцензія повинні бути досить простими для слідування. Область автора також прямолінійна.
Зараз нас хвилює автозавантаження. Це повинно бути досить чітко.
Коротше кажучи, у нас є директива для PSR4, про яку ви можете прочитати більше, а потім, де знаходиться простір імен. Отже, у наведеному вище прикладі все в просторі імен SamplePlugin знаходиться в src.
Це те, що повідомляє автозавантажувачу, де шукати певні файли. А в нашому випадку буде просто шукати клас Messenger .
Запущений композитор
Тепер, коли ми розглянули самі основи файлу конфігурації Composer, настав час запустити його. Згадайте, що ваш каталог плагінів має виглядати приблизно так:
У вашому терміналі введіть таку команду :
І ви повинні побачити щось на зразок цього:
Якщо припустити, що все пройшло добре, ви зможете увійти в WordPress і активувати плагін.
Бачити все разом
Після активації плагіна ви зможете перейти на інформаційну панель свого сайту. Там ви повинні побачити сповіщення, яке можна закрити, і воно виглядає точно так, як ми бачили на початку публікації:
Якщо ви зайшли так далеко, то все готово! В іншому випадку ще раз перевірте свій синтаксис, щоб переконатися, що все добре. Якщо щось не так, ймовірно, що ви не змогли б зайти так далеко, і якщо припустити, що у вас встановлено базові константи налагодження, тоді ви, швидше за все, побачите, де існує проблема.
Це ще не все
У Composer є багато іншого, і я настійно рекомендую прочитати документацію до нього. Дещо з цього я розповім під час перегляду інструментів, які планую розглянути пізніше в цій серії, але наразі я рекомендую ознайомитися з деякими умовностями.
О! І я не рекомендую перевіряти каталог постачальників у вашому репозиторії. Пізніше це може стати величезним каталогом, і це може підірвати ціль Composer.
У наступному дописі я розповім чому. Деякі люди роблять це, і це нормально, і я робив це раніше, але важливо бути розсудливим, коли ви це робите.
Зробіть помилку, не зробивши цього. І я поясню чому в наступному пості.