WordPressi vealogide lugemine ja mõistmine, 1. osa

Kui uurime jätkuvalt, mida tähendab olla sõltumatu WordPressi arendaja, vajalikke tööriistu ja erinevaid strateegiaid, mis võivad meie oskusi täiustada, olen rääkinud erinevatest konstantidest, pistikprogrammidest ja tööriistadest, mis meid aitavad.

Kui te lihtsalt komistate selle postituse otsa, siis soovitan vaadata minu WordPressi natiivsete silumistööriistade juhendit ja ka ülejäänud seeria seniseid postitusi.

Lõppkokkuvõttes pean ma oluliseks, et me kõik töötaksime selle teabe läbimisel sama aluse – või millegi tihedalt seotud – alusel.

Lõppkokkuvõttes on sellise tööriista nagu Xdebug kasutamine möödapääsmatu, kuid me peame selle nimel vaeva nägema (huvilistele kirjutasin veidi üle aasta tagasi selle kohta lühikese juhendi).

Praegu aga alustame põhitõdedest. Eelmises postituses lahkusin järgmise väitega:

Järgmises postituses hakkame uurima, mida on vaja WordPressi genereeritud vealogi uurimiseks ja kuidas näha teavet, mida näeme.

Ja seda ma tahan täna vaadata, sest kui mitte midagi muud, siis see annab teile midagi praktilist, mille põhjal töötada.

WordPressi vealogide mõistmine, 1. osa

Enne kui lähen sellesse liiga kaugele, tahan käsitleda ühte küsimust, mille saidi liige tõstatas.

Nimelt küsiti minult:

Millal me vaatame objektorienteeritud põhimõtteid?

Kuigi ma olen seda eelmises sarjas veidi käsitlenud, töötan selle nimel, et seda sarjas hiljem põhjalikumalt käsitleda.

Seda öeldes alustame siiski vealogide vaatamist.

Konstantide seadistamine

Kui te pole failis wp-config.php konstante konfigureerinud, soovitan seda teha kohe, kuna see annab teile tekkida võivate probleemide uurimisel suurima täpsusastme.

Kui te pole veel jõudnud, lugege kindlasti seda postitust (ja kui olete, veenduge, et teie konfiguratsioonifailis on määratletud järgmised konstandid ):

<?php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );
@ini_set( 'display_errors', 1 );
define( 'SCRIPT_DEBUG', true );
define( 'SAVEQUERIES', true );

Kui need on paigas, on teil kõik, mida vajate, et mitte ainult ekraanil teavet näha, vaid ka WordPressi loodud silumislogis.

Kus on Log?

Sõltuvalt teie keskkonna olemusest võib see erineda; kuid enamikul juhtudel leiate faili debug.log kataloogist wp-content, mis asub pistikprogrammide, teemade ja üleslaadimiste kataloogide kohal.

Nagu näete ülaloleva ekraanipildi eelvaatest, on minu silumisfailis palju sisu. Vaatleme seda põhjalikumalt järgmises jaotises ja ka seda, kuidas seda mõista. Seni aga kontrollige, kas see fail on üldse olemas. Kui see on olemas, siis tutvuge faili sisuga. Te võite või ei pruugi paljust toimuvast aru saada, kuid faili sisu tähendab, et miski teemas või pistikprogrammis käivitab erinevaid PHP hoiatusi, teateid ja tõrkeid, mida WordPress püüab ja logifaili salvestab.

Mida logifail isegi tähendab?

See ei tähenda tingimata, et miski on katki, kuid see viitab sellele, et miski ei tööta nii nagu peaks, seda ei tabata ega käsitleta programmilisel tasemel või lihtsalt teeb midagi, mida ei peaks tegema.

See ei pea selline välja nägema (aga võib!).

Arendajatena peaksime püüdma tagada, et meie kood ei genereeriks midagi, mis kirjutataks vealogi.

Üks asi on seda teha arenduses, kuna saame ülevaate sellest, mida me teeme ja kuidas WordPress toimib. Teine asi on aga see, et midagi, mille me tootmistasandil välja anname, loob selliseid asju.

Vealogi lugemine

Ilmselgelt tuleb vealogi lugeda rohkem kui lihtsalt avada. Paljudele jääb esmamulje, et see võib olla hunnik kõnepruuki. Ma saan ka sellest aru. Kuid kui saate aru, mida see teile näitab, on seda palju lihtsam mõista.

Nii et vaatame ühte väga lihtsat näidet. See pole ka väljamõeldud näide. Tegelikult on see pistikprogramm, mille kallal ma töötasin. Vealogi sisaldab järgmist teavet :

[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

Pange tähele, et ülaltoodud sisus on kolm rida. Parim viis vealogide lugemisel on alustada alt ja liikuda ülespoole. Selle põhjuseks on asjaolu, et täitmisel töötavad asjad virnas.

Lühike kõrvalepõige virnade kohta

Ma ei hakka selle mõiste arvutiteaduslikku definitsiooni kirjeldama, kuid kood käivitatakse ja töötab nii, et funktsioonid tekivad ja sõna otseses mõttes, arvuti mälus, kuhjuvad üksteise peale.

Seega on kõige uuem jooksmine alati ülaosas, kus alguspunkti juur asub allosas. Kuna me kirjutame koodi juba olemasolevale rakendusele, see on WordPress; siis on meie kood tõenäoliselt alati ülaosas.

WordPressi vealogide mõistmine: see pole selline virn

Idee seisneb selles, et kood hakkab WordPressis täitma ja liigub edasi meie tehtava tööni. Kui kuvatakse teade, hoiatus või tõrge, on see tavaliselt midagi meie koodis (kuigi WordPress ei ole sellest vabastatud, on see üldiselt nii).

Nii et tõrkelogi läbi lugedes loete sisuliselt seda, mida nimetatakse virnajäljeks. Viidatud Wikipedial on selle teema kohta üsna põhjalik definitsioon, kuid võib-olla on selle postituse jaoks kõige asjakohasem järgmine:

Programmeerijad kasutavad tavaliselt virna jälgimist interaktiivse ja surmajärgse [silumise] ajal (https://en.wikipedia.org/wiki/Silumine). Lõppkasutajad võivad näha tõrketeate osana kuvatud virna jälge, millest kasutaja saab seejärel programmeerijale teatada.

See vastab sellele, mida ma eespool kirjeldasin, eks? Kuid kui räägime sellest, mis on virnajälg (see muutub selgemaks, kui me silumisse süveneme), pöördume tagasi logifaili lugemise juurde, nagu see praegu on.

Tagasi Logi lugemise juurde

Sealhulgas failid

Esiteks, vaatame ülaltoodud sisu põhijoont. See sisaldab järgmist:

[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

See ütleb mulle, et minu faili easy-email-export.php real 25 ei õnnestunud faili kaasamiseks avada. See tähendab, et mul on koodis lause include_once, mis viitab failile ./src/Admin/EmailExportSubmenu.php, mida see ei leia.

Seega oleks parim viis leida rida 25 ja teha kindlaks, miks see faili asukohta ei leia. Võib-olla jätab see kogu tee selle kohta, kuhu see otsib. Selleni jõuame hetkega, kui räägime vealogi kirjutamisest.

Vigade mõtestamine

Järgmisel real (st äsja vaadatud rea kohal olev rida) sisaldab järgmist:

[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

See konkreetne rida erineb vaid veidi, kuid annab täiendava ülevaate ja see sisaldub klauslis "Sellist faili või kataloogi pole." See on põhjalik, sest see ütleb meile sõna otseses mõttes, et faili pole olemas.

Vähemalt ei eksisteeri seda sealt, kust ta otsib. Seega on kaks võimalust:

1. me ei ole loonud faili, millele viitame,
2. viitame faili asukohale vales kohas

Seega peaksime esimese asjana kontrollima, kas fail on asukohas, mida proovime kaasata. Kui ei, siis peaksime faili looma.

Kui fail on olemas, siis teame, et pistikprogramm soovib seda valelt teelt laadida. Seega peame võib-olla vaatama oma automaatlaadurit, kaasamise teed või failide allalaadimise viisi. Tõenäoliselt on see, et kui fail on olemas, siis proovitakse seda laadida kohast, kus see ei asu.

Tabamata viga

Koodi viimasel real näete midagi sellist:

[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

See on esiteks hea näide, kuna see deklareerib selgesõnaliselt, et tegemist on tabamata veaga. See tähendab, et olenemata funktsionaalsusest tekitab miski vea ja seda ei tabata.

• see võib olla erand,
• see võib olla probleem, kui proovite kutsuda funktsiooni, mida pole olemas,
• see võib toimida muutujaga, mis pole määratletud,
• ja nii edasi.

Lõppkokkuvõttes võib esineda palju probleeme. Hea uudis selles näites on see, et see on praktiliselt sama, mis ülaltoodud: faili ei leitud.

Välja arvatud, hoiatuse asemel ütleb PHP meile selgesõnaliselt, et tegemist on saatusliku veaga ja programm ei saa täitmist jätkata enne, kui see koodirida on lahendatud. Enne kui loobume sellest kui millestki, mis on sama mis eelmises jaotises (sest mõnes mõttes on see nii), peame mõistma, et see on otseselt öeldud saatusliku veana, samas kui eelmises näites käsitleti seda kui hoiatus.

Selle kontseptualiseerimiseks on erinevaid viise, kuid üldiselt arvan ma sellest järgmiselt:

• Teade ütleb mulle, et koodis on midagi valesti, kuid see pole piisavalt halb, et õigustada täitmise peatamist.
• Hoiatus on veidi tõsisem, sest see tähendab, et miski võib ebaõnnestuda.
• Tõrge ütleb otse: "See ei tööta ja programm ei saa jätkata."

Nüüd teame, et probleem on nii-öelda näiline ja me teame, milles probleem on. Lihtsamalt öeldes ei leita faili, mis on programmi täitmise lõpuleviimiseks vajalik, ja seetõttu lakkab programm töötamast.

See on kindlasti saatuslik viga.

Mis on lahendus?

See, mida ma oma probleemile lahendusena pakun, ei ole ettekirjutav selle kohta, mis teie jaoks töötab. Minu jaoks oli asi minu Composeri konfiguratsioonis sellises reas, et Composeri automaatlaadur ei suutnud faili õiges asukohas leida (aga see on rohkem seotud failikorralduse, nimevahede ja muuga).

Teie jaoks võib see olla midagi muud.

• võib-olla otsib see faili valest kataloogist,
• võib-olla on faili nimi koodis määratust erinev,
• või äkki on asi milleski muus.

Igal juhul on asi selles, et peate logifaili alt üles töötama, et probleem diagnoosida ja jälgida, mida PHP, WordPress ja teie töö teevad, ning seejärel diagnoosida see sealt.

Kirjutamine vealogi

Järgmises postituses võtame hetke, et näha, kuidas saaksime vealogi kirjutada. Mõnikord on faili lugemine hea ja lihtsalt nähtu vahel edasi-tagasi liikumine ja probleemide lahendamine on tore.

Aga kuidas on siis, kui tahame midagi välja jätta, et saada ülevaade sellest, mida WordPress või PHP näeb? See on ka kasulik.

Nii et selle sarja järgmises osas, mis käsitleb WordPressi vealogide mõistmist, teeme täpselt seda.

Mis on pärast seda?

Järgmisena vaatleme, kuidas kasutada mõnda eelnevalt kirjeldatud pistikprogrammi koodi testimiseks ja koodi profileerimiseks, veendumaks, et oleme teinud kõik endast oleneva, et tagada meie kvaliteetne tase.

See ei tähenda, et oleme silumisprotsessiga täielikult lõpetanud, kuid oleme kindlasti sammukese lähemal ja oleme valmis kirjutama sellise kvaliteediga koodi, mille tulemuseks pole fail, mis esindab erinevaid nüansiprobleeme. olime liiga hoolimatud, et parandada (rääkimata sellest, et aru saada).