Läsa och förstå WordPress-felloggar, del 1
När vi fortsätter att titta på vad det innebär att vara en oberoende WordPress-utvecklare, de verktyg som behövs och de olika strategierna som kan förbättra vår kompetens, har jag pratat igenom de olika konstanterna, plugins och verktyg för att hjälpa oss.
Om du bara snubblar över det här inlägget rekommenderar jag att du kollar in min guide till inbyggda WordPress-felsökningsverktyg samt resten av inläggen i serien hittills.
När allt kommer omkring tycker jag att det är viktigt att vi alla arbetar utifrån samma grund – eller något närbesläktat – när vi går igenom denna information.
I slutändan är det oumbärligt att använda ett verktyg som Xdebug, men vi måste arbeta upp till det (för den som är nyfiken skrev jag en kort guide om detta för lite över ett år sedan).
För nu, men låt oss börja med grunderna. I förra inlägget lämnade jag följande uttalande:
I nästa inlägg börjar vi titta på vad som är nödvändigt för att undersöka felloggen som genereras av WordPress och hur man förstår informationen vi ser.
Och det är vad jag vill titta på idag, för om inte annat kommer det att ge dig något praktiskt att arbeta med.
Förstå WordPress-felloggar, del 1
Innan jag går för långt in på det här vill jag ta upp en fråga som har tagits upp från en medlem på webbplatsen.
Jag fick nämligen frågan:
När ska vi titta på objektorienterade principer?
Även om jag har täckt lite om detta i en tidigare serie, är det något som jag jobbar på att täcka mer ingående senare i den här serien.
Men med det sagt, låt oss börja titta på felloggar.
Konfigurera dina konstanter
Om du inte har konfigurerat konstanterna i din wp-config.php- fil, rekommenderar jag att du gör det nu eftersom detta kommer att ge dig den största granualiteten när du undersöker eventuella problem som kan uppstå.
Om du inte har kommit ikapp, se till att läsa det här inlägget (och om du har, se till att följande konstanter är definierade i din konfigurationsfil):
<?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 );När de väl är på plats har du allt du behöver för att inte bara se information på skärmen utan också i felsökningsloggen som WordPress kommer att generera.
Var är loggen?
Beroende på din miljös natur kan detta variera; men i de flesta fall kommer du att hitta debug.log i wp-content- katalogen ovanför katalogerna för plugins, teman och uppladdningar.
Som du kan se från förhandsgranskningen av skärmdumpen ovan har min felsökningsfil mycket innehåll. Vi kommer att ta en titt på det mer ingående i nästa avsnitt samt hur man förstår det. Under tiden, dock, kontrollera för att se om den här filen ens existerar. Om den gör det är du välkommen att gå vidare och granska innehållet i filen. Du kanske förstår mycket av vad som händer, men kanske inte, men innehållet i filen betyder att något i ett tema eller plugin utlöser olika PHP-varningar, meddelanden och fel som WordPress fångar och dumpar till loggfilen.
Vad betyder loggfilen ens?
Detta betyder inte nödvändigtvis att något är trasigt, men det indikerar att något inte fungerar som det ska, inte fångas upp och hanteras korrekt på den programmatiska nivån, eller helt enkelt gör något som det inte borde göra.
Det behöver inte se ut så här (men det kan det!).
Som utvecklare bör vi sträva efter att se till att vår kod inte genererar något som skulle skrivas till felloggen.
Det är en sak att göra det under utveckling eftersom vi kan få insikt om vad det är vi gör och hur WordPress presterar. Det är dock en annan sak för något som vi släpper på produktionsnivå för att generera sådana saker.
Läser felloggen
Uppenbarligen är det mer att läsa felloggen snarare än att bara öppna den. För många är det första intrycket att det kan vara ett gäng jargong. Det förstår jag också. Men när du förstår vad den visar dig är det mycket lättare att förstå.
Så låt oss ta en titt på ett riktigt enkelt exempel. Det här är inte heller ett konstruerat exempel. Det här är faktiskt en som kommer från ett plugin som jag arbetade med. Felloggen innehåller följande information :
[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 25Lägg märke till att det i ovanstående sammanfattning finns tre rader. Det bästa tillvägagångssättet när du läser felloggar är att börja längst ner och arbeta dig uppåt. Detta beror på att saker när de körs i utförande, fungerar på en stack.
En kort utvikning på högar
Jag ska inte gå in på den datavetenskapliga definitionen av termen, men koden exekveras och fungerar på ett sådant sätt att funktioner uppstår och bokstavligen, i en dators minne, staplas ovanpå varandra.
Alltså kommer det senaste att springa alltid vara högst upp där roten till där det börjar är längst ner. Eftersom vi skriver kod på en redan existerande applikation, det är WordPress; då är vår kod sannolikt alltid överst.
Förstå WordPress-felloggar: Det är inte den här typen av stack
Tanken är att koden ska börja köras i WordPress och arbeta sig upp till det arbete vi gör. När det finns ett meddelande, en varning eller ett fel, kommer det vanligtvis att vara något i vår kod (även om WordPress inte är undantaget, så är det i allmänhet fallet).
Så när du läser igenom felloggen läser du i huvudsak igenom det som kallas en stackspårning. Wikipedia, som länkat, har en ganska djupgående definition av ämnet, men den kanske mest relevanta biten för detta inlägg är följande:
Programmerare använder vanligtvis stackspårning under interaktiv och post-mortem debugging. Slutanvändare kan se en stackspårning visas som en del av ett felmeddelande, som användaren sedan kan rapportera till en programmerare.
Detta stämmer överens med det jag har beskrivit ovan, eller hur? Men nog med att prata om vad en stackspårning är (det kommer att bli tydligare när vi kommer djupare in på felsökning), låt oss återgå till att läsa loggfilen som den ser ut för närvarande.
Tillbaka till Läsa loggen
Inklusive filer
Låt oss först titta på den nedersta raden i sammanfattningen ovan. Den innehåller följande:
[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 25Detta säger mig att på rad 25 i min fil, easy-email-export.php, misslyckades den med att öppna en fil för inkludering. Det betyder att jag har en include_once- sats i koden som refererar till ./src/Admin/EmailExportSubmenu.php som den inte kan hitta.
Så det bästa tillvägagångssättet skulle vara att hitta rad 25 och avgöra varför den inte hittar filen. Kanske dumpar det hela vägen till vart den letar. Vi kommer till detta ett ögonblick när vi pratar om att skriva till felloggen.
Att förstå felen
På nästa rad (det vill säga raden ovanför den vi just har tittat på) innehåller följande:
[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 25Den här specifika raden skiljer sig bara lite men den ger ytterligare insikt och det finns i klausulen som lyder "Ingen sådan fil eller katalog." Detta är insiktsfullt eftersom det bokstavligen talar om för oss att filen inte existerar.
Åtminstone finns den inte där den letar. Så de två möjligheterna är:
- vi har inte skapat filen vi refererar till,
- vi hänvisar till platsen för filen på fel plats
Det första vi skulle behöva kontrollera är alltså om filen finns på den plats vi försöker inkludera. Om det inte gör det bör vi skapa filen.
Om filen existerar vet vi att pluginet försöker ladda den från fel sökväg. Så vi kan behöva titta på vår autoloader, vår väg för inkludering, eller hur filerna hämtas. Eftersom, oddsen är, om filen finns, så försöker den laddas från en plats där den inte finns.
Ett oupptäckt fel
I den sista raden i koden ser du något sånt här:
[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 37Detta är ett bra exempel, för det första, eftersom det uttryckligen förklarar att detta är ett oupptäckt fel. Detta betyder att oavsett funktionalitet, något ger ett fel och det fångas inte upp.
- detta kan vara ett undantag,
- detta kan vara ett problem när du försöker anropa en funktion som inte finns,
- detta kan fungera på en variabel som inte är definierad,
- och så vidare.
I slutändan finns det en uppsjö av problem som kan vara närvarande. De goda nyheterna i det här exemplet är att det praktiskt taget är samma som ovan: En fil hittades inte.
Förutom, snarare än att kasta en varning, säger PHP uttryckligen att detta är ett fatalt fel och programmet kan inte fortsätta körningen förrän denna kodrad är löst. Innan vi avfärdar detta som något som är detsamma som föregående avsnitt (eftersom det på ett sätt är det), måste vi inse att detta uttryckligen anges som ett fatalt misstag, medan det i föregående exempel behandlades som ett varning.
Det finns olika sätt att konceptualisera detta men hur jag generellt tänker om det är detta:
- Ett meddelande säger mig att något är fel i koden, men det är inte tillräckligt illa för att motivera att körningen stoppas.
- En varning är något allvarligare eftersom den betyder att något riskerar att inte fungera.
- Ett felmeddelande direkt säger "det här fungerar inte och programmet kan inte fortsätta."
Nu vet vi att problemet håller på att ta slut, så att säga, och vi vet vad problemet är. Enkelt uttryckt, en fil som krävs för att programmet ska slutföra sin körning hittas inte och programmet slutar därför fungera.
Det är verkligen ett fatalt misstag.
Vad är lösningen?
Det jag tillhandahåller som lösning på mitt problem kommer inte att vara föreskrivande för vad som kommer att fungera för dig. För mig var det en fråga om en rad i min Composer-konfiguration så att Composer autoloader inte kunde hitta filen på rätt plats (men detta har mer att göra med filorganisation, namnavstånd och så vidare).
För dig kan det vara något annat.
- kanske letar den efter en fil i fel katalog,
- kanske filen heter något annat än vad som anges i koden,
- eller det kanske är något annat.
Oavsett vad som är fallet är poängen att det handlar om att arbeta dig igenom loggfilen från botten till toppen för att diagnostisera problemet och spåra vad PHP, WordPress och ditt arbete gör och sedan diagnostisera det därifrån.
Skriver till felloggen
I nästa inlägg ska vi ta en stund för att se hur vi kan skriva till felloggen. Ibland går det bra att läsa filen och att bara gå fram och tillbaka mellan det vi ser och lösa problemen är bra.
Men hur är det med fallet när vi vill dumpa något för att få insikt om vad WordPress eller PHP ser? Det är också användbart.
Så i nästa del av den här serien om att förstå WordPress-felloggar kommer vi att göra exakt det.
Vad är efter det?
Därefter kommer vi att titta på hur man använder några av de plugins som tidigare beskrivits för att testa kod och även profilera vår kod för att se till att vi har gjort allt vi kan för att säkerställa att vi producerar en kvalitetsnivå.
Detta betyder inte att vi är helt klara med felsökningsprocessen, men vi är definitivt ett steg närmare, och vi är positionerade för att skriva kod med en grad av kvalitet som inte resulterar i en fil som representerar olika nyanserade problem vi var för slarviga för att fixa (låt vara att förstå).