Читання та розуміння журналів помилок WordPress, частина 2

Минулого разу ми розглянули наступне:

1. налаштування констант налагодження,
2. пошук файлу журналу помилок,
3. розуміння того, як читати файл журналу,
4. розуміння трасування стека
5. розуміння того, як читати стек

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

Інша справа, якщо ви хочете зрозуміти, як записати інформацію у файл для дослідження та налагодження вручну.

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

Розуміння журналів помилок WordPress, частина 2

Який взагалі сенс писати в журнал помилок? Я маю на увазі, чи це взагалі частина процесу налагодження?

З попереднього посту :

Але як щодо випадку, коли ми хочемо щось викинути, щоб отримати уявлення про те, що бачить WordPress або PHP? Це теж корисно.

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

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

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

Розуміння функцій PHP

Для запису в журнал помилок важливо розуміти дві функції PHP:

1. error_log
2. print_r

Що стосується функції error_log, зауважте, що її призначення:

Надіслати повідомлення про помилку визначеним процедурам обробки помилок

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

З цією метою потрібно мати можливість використовувати print_r у поєднанні з error_log. print_r робить наступне:

Друкує зрозумілу людині інформацію про змінну

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

Зокрема, як зазначено в посібнику:

Якщо ви бажаєте отримати вихід print_r(), використовуйте returnпараметр. Якщо для цього параметра встановлено значення TRUE, print_r() повертатиме інформацію, а не друкуватиме її.

Отже, загальна ідея написання нашого значення масиву, скажімо, $exampleArray, виглядала б приблизно так :

<?php

error_log(print_r($exampleArray, true));

Але як бути в контексті WordPress?

Запис значень до журналу помилок у WordPress

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

Для цього припустімо, що ми реалізували версію шаблону реєстру. У нашій реалізації шаблону ми також маємо метод під назвою start, який ми можемо викликати, коли всі наші об’єкти буде додано до реєстру.

Це може виглядати приблизно так:

<?php

/**
 * Starts all of the objects stored is the registry by calling
 * the `start` method that's available on each of the objects.
 */
public function start()
{
    foreach ($this->storage as $obj) {
        $obj->start();
    }
}

Тепер, що стосується реалізації, це просто. Але що, якщо ми хочемо побачити, які об’єкти викликаються через кожну ітерацію циклу.

Ідея цього полягає в тому, що ми можемо перебирати збережені об’єкти та викликати метод для кожного з них. Це ґрунтується на ідеї, що кожен з об’єктів має метод, доступний для кожного з них (який може бути виконаний інтерфейсом ).

По-перше, виникає запитання: чому ми можемо це робити? Через характер системи керування подіями WordPress, можливо, ми хочемо переконатися, що кожен об’єкт, який ми очікуємо, запускається.

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

<?php

/**
 * Starts all of the objects stored is the registry by calling
 * the `start` method that's available on each of the objects.
 */
public function start()
{
    foreach ($this->storage as $obj) {
        error_log(print_r($obj, true));
        $obj->start();
    }
}

Це призведе до наступного результату:

Тут ви можете побачити об’єкт; це простір імен, це значення властивостей (включно з тим, чи є властивості приватними, захищеними, загальнодоступними тощо).

Звідти ви можете трохи налагодити, якщо вихідні дані ви не очікували, або, можливо, ви можете використати це, щоб перевірити, чи ваш код робить те, що ви очікували.

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

Використання встановлених плагінів

На цьому етапі ми розглянули основні аспекти налагодження коду за допомогою журналів помилок.

Але тепер нам потрібно звернути увагу на плагіни, які обговорювалися кілька публікацій тому. Після цього ми з часом перейдемо до Xdebug.

Але далі ми розглянемо інструменти, доступні нам із самого WordPress.