Встановлення Xdebug, частина 1: модуль Xdebug
Наразі ми охопили багато питань, пов’язаних із роботою з WordPress і налагодженням. І це особливо вірно, оскільки це стосується роботи з інструментами та плагінами, доступними в WordPress. Якщо ви тільки приєднуєтеся до цієї конкретної серії, будь ласка, переконайтеся, що ви наздогнали такі публікації:
- Читання та розуміння журналів помилок WordPress, частина 1
- Читання та розуміння журналів помилок WordPress, частина 2
- Базове налагодження в WordPress
У попередній публікації, нагадаю, я сказав наступне:
Але якщо ви прагнете потрапити у світ професійного, практичного налагодження зі своєї IDE, то важливо розуміти, що, як і чому.
І ми нарешті готові подивитися, що для цього потрібно. Однак для того, щоб почати, нам потрібно зрозуміти дещо про Xdebug, термінологію та мати IDE, яка буде відповідати всім, хто читає цю конкретну серію.
Отже, це буде розбито на дві частини.
- Спочатку ми розглянемо термінологію, необхідну для налагодження, і переконаємося, що в нашому середовищі розробки правильно налаштовано IDE,
- Далі ми розглянемо, як правильно встановити Xdebug, а потім підключити його до середовища розробки, щоб ми могли запустити його.
Якщо ви читали різноманітний вміст у цьому блозі за останні кілька років, деякі з них можуть здатися вам знайомими. Якщо ні, нічого страшного. Пам’ятайте, що мета полягає в тому, щоб переконатися, що ми всі на тому самому рівні, коли ми продовжуємо роботу, згадану вище, і протягом решти серії.
З огляду на це, давайте почнемо.
Встановлення Xdebug, частина 1
Як згадувалося вище, цей набір публікацій слугуватиме одній із двох цілей, обидві з яких можна коротко описати (друга з яких буде описана в наступній публікації):
- Термінологія налагодження
- Встановлення IDE
Хоча багато хто з тих, хто читає це, уже знайомі з деякою термінологією (особливо якщо ви раніше користувалися інструментами на стороні клієнта або навіть інструментами на стороні сервера), і у вас уже є обраний редактор, важливо переконатися, що ми принаймні працюючи на стабільній основі.
Якщо ви впевнені у своїх навичках у двох згаданих вище пунктах, то наступна публікація, швидше за все, буде для вас цікавішою. Якщо, з іншого боку, це виходить на нову територію для вас, це повинно закласти основу для всього, що вам потрібно, щоб переконатися, що ви успішно налагоджуєте проекти в WordPress.
Крім того, це гарантує, що у вас є узгоджений набір інструментів для роботи, щоб ми могли продовжувати просуватися вперед із стандартним набором інструментів для створення максимально продуктивного середовища розробки.
1 Термінологія налагодження
Залежно від вашого досвіду ви можете стверджувати, що існує від п’яти до семи термінів, кожен з яких пов’язаний із налагодженням. Я описав це раніше в інших публікаціях на цьому сайті. Однак кожного разу я робив це з дещо іншим поглядом на зміст.
У цьому дописі я намагаюся зробити це максимально точним і точним, щоб воно забезпечувало послідовне посилання, яке ми зможемо використовувати в наступних публікаціях (і в роботі). У поточному стані ось терміни, які, на мою думку, повинні знати всі, оскільки вони стосуються налагоджувача.
- Точки зупину. Це можна вважати фундаментальними блоками налагодження. Простіше кажучи, це місця в коді, виконання яких потрібно призупинити, щоб ви могли перевірити, що відбувається в коді. Можливо, це пов’язано зі змінними; можливо, це пов’язано з функціями, можливо, це пов’язано з чимось іншим. Незважаючи на це, це важливо, тому що ви повідомляєте програмі: «Привіт, я хочу зупинити виконання програми прямо тут, у цьому рядку, щоб я міг дослідити стан програми».
- Годинники. Це виклики функцій, змінні чи інші місця в коді, які можна налаштувати так, щоб ми могли буквально бачити зміни значень під час виконання. Якщо ми говоримо про функції, то можемо мати на увазі значення аргументів, коли вони встановлюються та маніпулюються ними у функції. Якщо ми говоримо про змінні, ми говоримо про змінні; тоді ми говоримо про значення, які вони зберігають у будь-який даний момент під час виконання програми. Це може бути, коли ми встановлюємо певну точку зупину, або це може бути щоразу, коли ми виконуємо код і стежимо за станом змінної під час виконання програми.
- Почати. Ця дія просто повідомляє налагоджувачу розпочати моніторинг веб-сервера. По суті, він стежить за всім, що відбувається в програмі, і, якщо встановлено будь-які точки зупину, він готовий зупинити виконання та дозволити нам поглянути на те, що відбувається зі станом програми. Технічно ви можете почати сеанс налагодження і нічого не робити. Це не зовсім продуктивно, але можливо.
- Крок в. Припустімо на мить, що у вас є точка зупинки, встановлена безпосередньо над викликом функції або під час виклику функції. Це дозволяє нам увійти у функцію, щоб відстежувати значення кожного аргументу, те, як ними маніпулюють у функції, що функція повертає (якщо щось повертає), і все, що відбувається всередині функції.
- Переступити. З іншого боку, припустімо, що ви проходите через функцію і не впевнені, що хочете зануритися в неї. Можливо, вас цікавлять лише значення, які повертає функція, або стан програми після виконання функції, але вас не цікавить, що відбувається всередині функції. По суті, ви ставитеся до нього як до чорної скриньки. Ось що означає переступити через функцію. Тобто ви дозволяєте функції працювати, не входячи в неї, щоб спостерігати за її роботою.
- Вийти. Цей конкретний аспект налагодження корисний щоразу, коли ви опиняєтесь у функції та готові повернутися до основної лінії виконання, оскільки ви побачили все, що вам потрібно було побачити. Можливо, ви були свідками зміни значень змінної, можливо, ви бачили, як алгоритм виконує достатньо роботи, щоб знати, що він зробив те, що ви хотіли. У будь-якому випадку це дозволить вам вийти з функції, влучно названої, а потім перейти до
- Стоп. Подібно до того, як start повідомляє налагоджувачу почати слухати сервер, звертаючи увагу на контрольні точки та відображаючи інформацію про прогрес програми, stop робить якраз протилежне. Він повідомляє налагоджувачу, що ми закінчили слухати, дивитися та звертати увагу на стан програми. Це не означає, що програма зупиняється – лише налагоджувач. Отже, якщо ви закінчили звертати увагу на всю інформацію, надану налагоджувачем, тоді ви, швидше за все, зможете зупинити налагоджувач.
Останнє зауваження, яке я хотів би зробити, полягає в тому, що PHP унікальний тим, що пропонує різноманітні загальнодоступні змінні, такі як $_GET , $_POST, $_REQUEST тощо. Це також доступні нам змінні, за якими ми можемо спостерігати. Це не обмежується лише тим, що ми записали в нашому коді.
Це особливо корисно, оскільки ми переглядаємо дані про перезавантаження сторінки, запити Ajax (наприклад, під час дій GET і POST) тощо.
2 Встановлення Xdebug
Хоча це очевидно з попередніх публікацій у цій серії, я збираюся використовувати Visual Studio Code як IDE. Якщо у вас його немає, то я рекомендую цей. Однак якщо у вас є IDE, якою вам зручно користуватися, то я рекомендую це.
- Код постійно розробляється,
- має активну економіку розширень,
- добре працює з різними мовами, інструментами тощо,
- є легким і чудово поєднується з різними речами, які ми можемо використовувати в розробці WordPress (такими як PHP, HTML і JavaScript).
Крім того, Code також має надійну підтримку Xdebug. Однак, щоб переконатися, що налагоджувач встановлено належним чином, нам потрібно переконатися, що у нас встановлено розширення разом із інсталяцією PHP, що воно доступне в нашій системі та може бути виконано в нашій IDE. Ми збираємося це зробити, але спочатку нам потрібно переконатися, що Xdebug правильно встановлено.
Встановлення Xdebug
Встановити Xdebug легко. У сеансі терміналу вам потрібно буде виконати таку команду:
Коли ви це зробите, ви помітите кілька речей, які відбуваються у вікні терміналу під час встановлення. Якщо ви особливо не зацікавлені, вам не потрібно турбуватися про те, що він робить, доки він не поверне вас до командного рядка.
На цьому етапі модуль Xdebug встановлено; однак вам потрібно буде повідомити PHP, що він встановлений і де він може знайти модуль.
Щоб установити розширення з вашою поточною версією PHP, важливо знати, яку версію PHP ви встановили. Якщо ви користуєтеся менеджером пакетів, можливо, існує кілька версій, і вам потрібно буде вказати файлу конфігурації цієї версії, де знайти модуль.
І навпаки, якщо у вас встановлено одну версію, вам потрібно буде повідомити одну версію PHP, де вона встановлена. По-перше, ви можете знайти, де існує Xdebug у файловій системі, використовуючи цю команду:
Тоді вам потрібно буде оновити файл конфігурації для встановлення PHP. Для цього просто запустіть php -v з командного рядка, і він повідомить вам, яку версію ви використовуєте. Звідси вам потрібно буде знайти файл ініціалізації для версії PHP, яку ви використовуєте. Якщо під час запуску php -v ви повернетеся з таким:
Це означає, що ми використовуємо PHP 7.1.19 (хоча ваша версія може відрізнятися). Звідси ми знаємо, що потрібно шукати певний файл конфігурації PHP для цієї версії PHP. Для цього знайдіть php.ini в системному каталозі /usr/local/etc/php/7.1/ (хоча точний номер версії може відрізнятися).
Звідти відкрийте файл і додайте такий рядок коду:
zend_extension="/usr/local/lib/php/pecl/20160303/xdebug.so"Це вкаже PHP, де знаходиться Xdebug, щоб його можна було використовувати у вашій роботі.
Тестування інсталяції
Щоб переконатися, що встановлення пройшло правильно, ви можете запустити наступний код у своєму терміналі:
Потім ви повинні побачити на екрані щось на зразок наступного:
Зверніть увагу, що на знімку екрана вище ви бачите таке:
з Xdebug v2.6.0, авторське право (c) 2002-2018, Дерік Ретанс
Це означає, що модуль встановлено і PHP знає про нього.
Налаштування вашого IDE
У наступній публікації ми розглянемо зв’язування Xdebug із нашою IDE. Якщо припустити, що ви виконали кроки, наведені в цій публікації, і все пройшло добре, у вас усе готово, оскільки це стосується підготовки до налагодження проектів WordPress.
Проте, поки ми не запустимо його в IDE, це не так корисно (або складніше, ніж має бути). Тому наступного тижня ми розглянемо, як саме це зробити.