WordPressin virhelokien lukeminen ja ymmärtäminen, osa 1

Samalla kun tutkimme edelleen, mitä tarkoittaa olla riippumaton WordPress-kehittäjä, tarvittavia työkaluja ja erilaisia ​​strategioita, jotka voivat parantaa osaamistamme, olen käynyt läpi erilaisia ​​vakioita, laajennuksia ja työkaluja, jotka auttavat meitä.

Jos olet vain törmännyt tähän viestiin, suosittelen tutustumaan oppaani alkuperäisiin WordPress-virheenkorjaustyökaluihin sekä sarjan tähän mennessä oleviin muihin viesteihin.

Loppujen lopuksi pidän tärkeänä, että me kaikki työskentelemme samalla pohjalla – tai jollain läheisesti liittyvällä – kun käymme tätä tietoa läpi.

Loppujen lopuksi Xdebugin kaltaisen työkalun käyttö on välttämätöntä, mutta meidän on pyrittävä siihen (uteliaisille kirjoitin lyhyen oppaan tästä hieman yli vuosi sitten).

Aloitetaan nyt kuitenkin perusasioista. Edellisessä viestissä poistuin seuraavalla lausunnolla:

Seuraavassa viestissä alamme tarkastella, mitä tarvitaan WordPressin luoman virhelokin tutkimiseen ja kuinka ymmärtää näkemämme tiedot.

Ja sitä haluan tarkastella tänään, koska jos ei muuta, se antaa sinulle jotain käytännöllistä, josta voit työskennellä.

WordPressin virhelokien ymmärtäminen, osa 1

Ennen kuin menen liian pitkälle tähän, haluan käsitellä yhtä kysymystä, jonka sivuston jäsen on esittänyt.

Nimittäin minulta kysyttiin:

Milloin aiomme tarkastella oliokeskeisiä periaatteita?

Vaikka olen käsitellyt tätä hieman aiemmassa sarjassa, yritän käsitellä sitä tarkemmin myöhemmin tässä sarjassa.

Aloitetaan kuitenkin virhelokien tarkasteleminen tämän jälkeen.

Vakioiden määrittäminen

Jos et ole määrittänyt vakioita wp-config.php- tiedostossasi, suosittelen, että teet sen nyt, koska se antaa sinulle parhaan mahdollisen tarkkuuden tutkiessasi mahdollisia ongelmia.

Jos et ole perillä, muista lukea tämä viesti (ja jos olet, varmista, että seuraavat vakiot on määritetty asetustiedostossasi):

Kun ne ovat paikoillaan, sinulla on kaikki mitä tarvitset nähdäksesi tiedot näytöllä, mutta myös WordPressin luomassa virheenkorjauslokissa.

Missä loki on?

Tämä voi vaihdella ympäristösi luonteesta riippuen; Kuitenkin useimmissa tapauksissa löydät debug.log – osoitteen wp-sisältöhakemistosta, joka sijaitsee laajennusten, teemojen ja lataushakemistojen yläpuolella .

Kuten yllä olevan kuvakaappauksen esikatselusta näet, virheenkorjaustiedostossani on paljon sisältöä. Tarkastellaan sitä tarkemmin seuraavassa osiossa sekä kuinka se ymmärretään. Sillä välin kuitenkin tarkista, onko tämä tiedosto edes olemassa. Jos on, voit mennä eteenpäin ja tutkia tiedoston sisältöä. Ymmärrät tai et ymmärrä paljon tapahtuvasta, mutta tiedoston sisältö tarkoittaa, että jokin teemassa tai laajennuksessa laukaisee erilaisia ​​PHP-varoituksia, -ilmoituksia ja -virheitä, joita WordPress kerää ja tallentaa lokitiedostoon.

Mitä lokitiedosto edes tarkoittaa?

Tämä ei välttämättä tarkoita, että jokin olisi rikki, mutta se osoittaa, että jokin ei toimi niin kuin sen pitäisi, sitä ei havaita ja käsitellä oikein ohjelmatasolla tai se yksinkertaisesti tekee jotain, mitä sen ei pitäisi tehdä.

Sen ei tarvitse näyttää tältä (mutta se voi!).

Kehittäjänä meidän tulee pyrkiä varmistamaan, että koodimme ei luo mitään, mikä kirjoitetaan virhelokiin.

Yksi asia on tehdä se kehitystyössä, koska voimme saada käsityksen siitä, mitä teemme ja miten WordPress toimii. Se on kuitenkin toinen asia, että jokin, jonka julkaisemme tuotantotasolla, tuottaa tällaisia ​​asioita.

Virhelokin lukeminen

Ilmeisesti virhelokin lukeminen on muutakin kuin sen avaamista. Monille ensivaikutelma on, että se voi olla joukko ammattislangia. Minäkin ymmärrän sen. Mutta kun ymmärrät, mitä se näyttää sinulle, on paljon helpompi ymmärtää.

Katsotaanpa siis todella yksinkertaista esimerkkiä. Tämäkään ei ole keksitty esimerkki. Itse asiassa tämä on peräisin laajennuksesta, jonka parissa työskentelin. Virheloki sisältää seuraavat tiedot :

[05-Jul-2018 19:43:53 UTC] PHP Fatal error:  Uncaught Error: Class 'EasyEmailExportAdminEmailExportSubmenu' not found in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php:37
#8 /U in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 37
[05-Jul-2018 19:44:03 UTC] PHP Warning:  include_once(./src/Admin/EmailExportSubmenu.php): failed to open stream: No such file or directory in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25
[05-Jul-2018 19:44:03 UTC] PHP Warning:  include_once(): Failed opening './src/Admin/EmailExportSubmenu.php' for inclusion (include_path='.:/usr/local/Cellar/php/7.2.5/share/php/pear') in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25

Huomaa, että yllä olevassa sisällössä on kolme riviä. Paras tapa toimia virhelokeja luettaessa on aloittaa alhaalta ja siirtyä ylöspäin. Tämä johtuu siitä, että suorituksen aikana suoritettavat asiat toimivat pinossa.

Lyhyt poikkeama pinoista

En mene käsitteen tietojenkäsittelytieteen määritelmään, mutta koodi suoritetaan ja toimii siten, että funktioita esiintyy ja aivan kirjaimellisesti tietokoneen muistissa pinotaan päällekkäin.

Siten viimeisin juokseva asia tulee aina olemaan ylhäällä, missä sen alkujuuri on alhaalla. Koska kirjoitamme koodia jo olemassa olevaan sovellukseen, se on WordPress; silloin koodimme on todennäköisesti aina yläosassa.

WordPress-virhelokien ymmärtäminen: Se ei ole tällainen pino

Ajatuksena on, että koodi alkaa suorittaa WordPressissä ja etenee kohti tekemäämme työtä. Kun tulee ilmoitus, varoitus tai virhe, se on yleensä jotain koodissamme (vaikka WordPress ei ole vapautettu, niin yleensä).

Joten kun luet virhelokia, luet pohjimmiltaan niin sanottua pinojäljitystä. Wikipediassa, kuten linkitetty, on melko syvällinen määritelmä aiheesta, mutta ehkä osuvin kohta tähän viestiin on seuraava:

Ohjelmoijat käyttävät yleensä pinojäljitystä interaktiivisen ja post mortem -virheenkorjauksen aikana (https://en.wikipedia.org/wiki/Debugging). Loppukäyttäjät voivat nähdä pinon jäljen osana virheilmoitusta, jonka käyttäjä voi sitten ilmoittaa ohjelmoijalle.

Tämä sopii yhteen sen kanssa, mitä olen edellä hahmotellut, eikö niin? Mutta tarpeeksi puhua siitä, mitä pinojäljitys on (se tulee selvemmäksi, kun pääsemme syvemmälle virheenkorjaukseen), palataanpa nyt lokitiedoston lukemiseen sellaisena kuin se on.

Takaisin lokin lukemiseen

Sisältää tiedostot

Katsotaanpa ensin alimmaista riviä yllä olevassa sisällössä. Se sisältää seuraavat:

[05-Jul-2018 19:44:03 UTC] PHP Warning: include_once(): Failed opening './src/Admin/EmailExportSubmenu.php' for inclusion (include_path='.:/usr/local/Cellar/php/7.2.5/share/php/pear') in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25

Tämä kertoo minulle, että tiedostoni easy-email-export.php rivillä 25 se ei onnistunut avaamaan tiedostoa sisällytettäväksi. Tämä tarkoittaa, että koodissa on include_once -lauseke, joka viittaa osoitteeseen ./src/Admin/EmailExportSubmenu.php, jota se ei löydä.

Joten paras tapa toimia olisi etsiä rivi 25 ja selvittää, miksi se ei löydä tiedostoa. Ehkä se kaataa koko polun siihen, mihin se näyttää. Pääsemme tähän hetkeksi, kun puhumme virhelokiin kirjoittamisesta.

Virheiden järkeä

Seuraavalla rivillä (eli juuri tarkastelemamme rivin yläpuolella) on seuraava:

[05-Jul-2018 19:44:03 UTC] PHP Warning: include_once(./src/Admin/EmailExportSubmenu.php): failed to open stream: No such file or directory in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 25

Tämä erityinen rivi eroaa vain hieman, mutta se antaa lisätietoa, ja se sisältyy lausekkeeseen, joka kuuluu "Ei tällaista tiedostoa tai hakemistoa". Tämä on oivaltava, koska se kirjaimellisesti kertoo meille, että tiedostoa ei ole olemassa.

Sitä ei ainakaan ole olemassa sieltä, missä se katsoo. Joten kaksi mahdollisuutta ovat:

1. emme ole luoneet tiedostoa, johon olemme viittauksia,
2. viittaamme tiedoston sijaintiin väärässä paikassa

Siksi meidän on ensin tarkistettava, onko tiedosto olemassa paikassa, jota yritämme sisällyttää. Jos ei, meidän pitäisi luoda tiedosto.

Jos tiedosto on olemassa, tiedämme, että laajennus yrittää ladata sen väärästä polusta. Joten meidän on ehkä tarkasteltava automaattista latausohjelmaamme, sisällyttämispolkuamme tai sitä, miten tiedostoja haetaan. Koska todennäköisyys on, että jos tiedosto on olemassa, sitä yritetään ladata paikasta, jossa se ei ole.

Tavoittamaton virhe

Koodin viimeisellä rivillä näet jotain tällaista:

[05-Jul-2018 19:43:53 UTC] PHP Fatal error: Uncaught Error: Class 'EasyEmailExportAdminEmailExportSubmenu' not found in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php:37
#8 /U in /Users/tommcfarlin/Dropbox/Projects/trunk/wp-content/plugins/easy-email-export/easy-email-export.php on line 37

Tämä on hyvä esimerkki ensinnäkin, koska se ilmoittaa nimenomaisesti, että tämä on huomaamaton virhe. Tämä tarkoittaa, että toiminnallisuudesta riippumatta jokin aiheuttaa virheen, eikä sitä saada kiinni.

• tämä voi olla poikkeus,
• tämä voi olla ongelma yritettäessä kutsua funktiota, jota ei ole olemassa,
• tämä voi toimia muuttujalla, jota ei ole määritelty,
• ja niin edelleen.

Loppujen lopuksi siellä voi olla monia ongelmia. Hyvä uutinen tässä esimerkissä on, että se on käytännössä sama kuin yllä oleva: Tiedostoa ei löydy.

Paitsi, sen sijaan, että PHP antaisi varoituksen, se kieltää meidät, tämä on kohtalokas virhe, eikä ohjelma voi jatkaa suoritusta ennen kuin tämä koodirivi on ratkaistu. Ennen kuin hylkäämme tämän jonakin, joka on sama kuin edellinen osio (koska tietyllä tavalla se on), meidän on ymmärrettävä, että tämä on nimenomaisesti ilmoitettu kohtalokkaaksi virheeksi, kun taas edellisessä esimerkissä sitä käsiteltiin Varoitus.

On olemassa erilaisia ​​​​tapoja käsitteellistää tämä, mutta tapa, jolla ajattelen sitä yleensä seuraavasti:

• Ilmoitus kertoo, että jotain on pielessä koodissa, mutta se ei ole tarpeeksi huono oikeuttaakseen suorittamisen keskeyttämisen.
• Varoitus on hieman vakavampi, koska se tarkoittaa, että jokin on vaarassa epäonnistua.
• Virheilmoitus sanoo "tämä ei toimi, eikä ohjelma voi jatkaa".

Nyt tiedämme, että ongelma on niin sanotusti pysäyttämätön, ja tiedämme, mikä ongelma on. Yksinkertaisesti sanottuna tiedostoa, joka tarvitaan ohjelman suorittamiseen loppuun, ei löydy, joten ohjelma lakkaa toimimasta.

Se on varmasti kohtalokas virhe.

Mikä on Ratkaisu?

Se, mitä tarjoan ratkaisuksi ongelmaani, ei ole ohjeellinen sen suhteen, mikä toimii sinulle. Minulle se oli kysymys rivistä Composer-kokoonpanossani, jolloin Composerin automaattinen latausohjelma ei löytänyt tiedostoa oikeasta sijainnista (mutta tämä liittyy enemmän tiedostojen järjestämiseen, nimiväliin ja niin edelleen).

Sinulle se voi olla jotain muuta.

• ehkä se etsii tiedostoa väärästä hakemistosta,
• ehkä tiedoston nimi on jokin muu kuin koodissa määritetty,
• tai ehkä se on jotain muuta.

Joka tapauksessa asia on, että sinun on työskenneltävä lokitiedoston läpi alhaalta ylös, jotta voit diagnosoida ongelman ja jäljittää, mitä PHP, WordPress ja työsi tekevät, ja sitten diagnosoida se sieltä.

Kirjoitetaan virhelokiin

Seuraavassa viestissä katsomme, kuinka voimme kirjoittaa virhelokiin. Joskus tiedoston lukeminen on hienoa, ja yksinkertaisesti liikkuminen näkemämme välillä ja ongelmien ratkaiseminen on mukavaa.

Mutta entä tilanne, jossa haluamme jättää jotain pois saadaksemme käsityksen siitä, mitä WordPress tai PHP näkee? Siitä on myös hyötyä.

Joten tämän WordPress-virhelokien ymmärtämistä käsittelevän sarjan seuraavassa osassa teemme juuri niin.

Mitä sen jälkeen?

Seuraavaksi tarkastelemme, kuinka käyttää joitain aiemmin hahmoteltuja laajennuksia koodin testaamiseen ja myös koodimme profilointiin varmistaaksemme, että olemme tehneet kaikkemme varmistaaksemme, että tuotamme laatutasoa.

Tämä ei tarkoita, että olisimme täysin valmiit virheenkorjausprosessin kanssa, mutta olemme ehdottomasti askeleen lähempänä ja pystymme kirjoittamaan koodia laadukkaalla tavalla, joka ei johda tiedostoon, joka edustaa erilaisia ​​vivahteita. olimme liian huolimattomia korjataksemme (puhumattakaan ymmärtämisestä).