Share
Under hela serien har vi pratat om ett antal praxis som vi kan använda i vår WordPress temat utveckling som hjälper till att inte bara ge en konsekvent grund för att vi kan bygga våra befintliga och framtida projekt, men det hjälper oss också behålla dem efter att de släppts.
Hittills har vi täckt:
Innan du dyker in i den här artikeln rekommenderar jag att du läser de första två så att du kan få en känsla för det perspektiv som vi tar när vi tittar på tematillväxten. Förutom dessa punkter finns det också ett antal verktyg som jag tror bör installeras för att försäkra oss om att vi skriver den bästa koden som är möjlig.
Naturligtvis är detta inte bara förutom de tidigare nämnda tipsen, utan också tillämpning av WordPress-kodningsstandarderna.
I den här sista artikeln ska jag prata om flera olika inställningar och plugins som jag tycker borde definieras och / eller installeras i varje WordPress-utvecklingsmiljö för att se till att du använder de senaste API-erna, att du inte påverkar prestanda negativt och att du inte orsakar några meddelanden, varningar eller fel som ska kastas via PHP.
Innan vi hoppas på att prata om olika plugins som finns tillgängliga, finns det ett antal inställningar som jag rekommenderar starkt att du ställer in på din webbserver och i ditt WordPress-miljö.
Några av dessa inställningar kommer att bidra till funktionaliteten för plugins som vi kommer att titta på senare i den här artikeln. Andra kommer att tillhandahålla funktionalitet som hjälper oss att varna oss när vi gör misstag i PHP och / eller i vår WordPress -specifik kod.
Även om inte alla arbetar med Apache, PHP och MySQL, är det fortfarande den mest vanliga konfigurationen som används när man arbetar med WordPress. En av de saker som jag alltid rekommenderar utvecklare gör i denna miljö är att se till att de har konfigurerat PHP för att logga in allt till en loggfil på sin maskin.
Det vill säga när alternativen lämnas in för att logga in:
Se till att du kontrollerar allt. Om du använder ett verktyg som MAMP, XAMPP eller WAMP är det vanligtvis mycket enkelt att göra via användargränssnittet. Om du inte är säker på var du ska konfigurera dessa alternativ kan du dock alltid ställa in dem php.ini Använda anteckningarna som beskrivs i PHP-manualen.
Håller koll på fel som loggas som kanske inte visas på skärmen (även om vi ska göra vad vi kan för att se till att vi do se dem på skärmen senare i den här artikeln) är viktigt för att du ska skriva kod som får några potentiella problem med koden.
Beviljas, detta borde kunna göras vid användning av andra webbservrar - trots allt är detta bara en PHP-konfigurationsinställning - men jag använder för närvarande inte många av de andra alternativen som är tillgängliga så jag ville vara tydlig om miljö där jag konfigurerar mina inställningar.
WP_DEBUG är en konstant som du kan ställa in i ditt WordPress wp-config.php fil. De flesta installationer kommer som standard att ha den här inställningen som falsk. Om din är redan inställd på Sann, då betyder det att någon redan har gjort det eller att du har en kopia av WordPress med inställningar som är inte skickas som standard från WordPress.org.
Hur som helst, letar du efter konstanten i konfigurationsfilen och om den är inställd på falsk, sätt sedan på det Sann. Om den inte hittas lägger du till raden. I slutändan är det här ditt functions.php filen ska innehålla (förutom den andra koden som redan var där):
Accentsconagua
definiera ('WP_DEBUG', true);Kort sagt, denna speciella konstant kommer att se till att PHP-meddelanden skrivs ut på skärmen, såväl som WordPress-specifika debug-meddelanden. Det här är verkligen användbart när du arbetar med ett tema och du försöker kontrollera, säga ett tomt index för en array eller slutar du använda en funktion som inte längre stöds av den nuvarande versionen av WordPress.
Det finns också ett fantastiskt plugin relaterat till den här tekniken som vi kommer att täcka senare i den här artikeln.
Det finns också två ytterligare konstanter som du kan definiera som ger ännu mer information om vad det här kommer att göra. Du kan läsa motsvarande Codexartikel för mer information, men kort sagt är konstanterna och deras definitioner följande:
WP_DEBUG_DISPLAY är en annan kompis till WP_DEBUG som kontrollerar huruvida felsökningsmeddelanden visas i sidans HTML eller inte. Standard är "true" som visar fel och varningar när de genereras. Om du ställer in detta till falskt kommer alla fel att döljas. Detta ska användas tillsammans med WP_DEBUG_LOG så att fel kan ses över senare.
Utanför rutan kommer WordPress att visa alla fel, varningar och meddelanden inom ramen för en sida. Om du vill fortsätta felsöka WordPress men vill förhindra att informationen lämnas till sidan och bara skrivs till en loggfil, kan du ställa in det här konstant till falsk.
Personligen är jag inte fan av att hålla saker dolda, eftersom jag gillar att se problem så fort de väcker upp (läs: så snart jag har genererat dem), men alla har olika arbetsflöden. Därför, om du ser meddelandena på sidorna står i konflikt med din utvecklingsstil, definierar du den här konstanten på rätt sätt tillsammans med WP_DEBUG_LOG.
WP_DEBUG_LOG är en följeslagare till WP_DEBUG som gör att alla fel också sparas i en debug.log loggfil i / wp-content / directory. Det här är användbart om du vill granska alla meddelanden senare eller behöver se meddelanden som genereras på skärmen (t.ex. under en AJAX-förfrågan eller wp-cron-körning).
Det här är en användbar konstant för att definiera om du är stor på att övervaka dina felloggar (som de flesta utvecklare skall vara). Förutom loggen som genereras av PHP, är det ännu en fil som kan ge insikt om vad ett givet problem kan vara och var det händer när du arbetar med ett tema.
Denna konstant är en annan som kommer att vara till nytta med några av de plugins som vi ska titta på senare i den här artikeln; Det är dock värt att ställa in functions.php även om du inte har ytterligare plugins installerade.
Först, som WP_DEBUG konstant ovan, kan du lägga till detta till functions.php. Det ska se ut så här:
definiera ("SAVEQUERIES", true);Ser bra ut, men vad gör det egentligen? SAVEQUERIES instruerar WordPress att hålla reda på två saker:
Detta gränssnitt direkt med $ wpdb vilken är WordPress databas klassen. Som tidigare nämnts finns det ett annat plugin som fungerar direkt med den här konstanten så att du kan se alla frågor från WordPress. Om du hellre vill förlora ett plugin för att hjälpa till att göra informationen, definiera du bara denna konstant och skriv sedan ut resultatet av $ Wpdb-> frågor till ditt utmatningsformat av val.
Förutom att du ställer in konstanter finns det ett antal kraftfulla plugins som jag tycker borde installeras i varje utvecklars WordPress-installation som kan ge ännu mer hjälp när de används med inställningarna ovan.
Även om många av er kommer att ha plugins att lägga till i den här listan och andra kommer att få åsikter om var och en av dessa plugins, det här är de som jag har funnit vara mest användbara i min utvecklingsinsats.
Debug Bar introducerar ett alternativ i adminfältet i din WordPress-installation som ger information om frågor, cacheminnet och annan information.
Denna plugin används bäst med WP_DEBUG och SAVEQUERIES aktiverad. Observera att det här pluginet också krävs för ett antal pluginprogram som jag listar efter den här. Det betyder att det har ett antal förlängningar som gör det ännu mer kraftfullt.
Detta plugin introducerar ytterligare två flikar i felsökningsfältet som låter dig se alla åtgärder och filtren (det vill säga alla krokarna) som körs på den aktuella sidförfrågan.
Det här är mycket användbart om du bygger ett komplext tema eller om du har ärft en kodbas från någon annan och du försöker hitta Varför vissa saker händer som kanske inte är lätta att hitta på grund av hur temat är byggt.
Tyvärr har det här plugin inte uppdaterats om några år så jag vet inte hur länge det kommer att fortsätta att fungera med WordPress (om ingen antar det för utveckling), men det fungerar tillsammans med Debug Bar för att ge dig förmågan att exekvera PHP och MySQL direkt från WordPress.
Det här är mycket användbart när du försöker lista ut varför, säg, en funktion i ditt tema fungerar inte som det borde vara. Det betyder att du kan skriva en funktion direkt i konsolen, utföra den och se resultatet utan att behöva ständigt hoppa tillbaka till din IDE, ändra funktionen, uppdatera och kolla resultatet.
Om du arbetar med ett tema som använder många stilar och många JavaScript-filer, särskilt de som är beroende av andra stylesheets och andra JavaScript-filer, är det användbart att veta vilken ordning de laddas och hur de borde vara lastad.
Det är där den här Debug Bar addon kommer in i spel.
Det gör det möjligt för oss att visualisera den ordning i vilken skript och stilar laddas och körs så att vi kan göra nödvändiga ändringar för att säkerställa att alla beroenden laddas på sätt som de borde vara för att vårt tema ska fungera korrekt.
Om ditt tema introducerar anpassade posttyper i instrumentbrädan, då är oddsen du måste arbeta med en mängd olika egenskaper, skriva om regler och mer.
Det kan bli komplicerat riktigt snabbt beroende på hur mycket du väljer att anpassa funktionerna i den anpassade posttypen.
Detta plugin lägger till ytterligare en panel till Debug Bar så att du enkelt kan se egenskaperna för varje posttyp. Det tillåter inte ändring eller redigering i flygningen (som det kan göras i Debug Bar Console eller det kan göras genom att helt enkelt redigera din anpassade posttyp definition), men det ger ett mycket renare format än en jätte matris på skärmen av en IDE.
Det här är ett enkelt plugin som loggar användningen av gamla filer, funktion, argument och så vidare till en fil. När du skriver ett tema kommer det här pluginet att meddelas när du kör något som inte är 100% kompatibelt med den nuvarande versionen av WordPress.
För dem som vill försäkra sig om att de är framtidsbestämmande för sitt arbete och som håller sig uppdaterade med de senaste API-skivorna, rekommenderar jag starkt detta plugin.
En av de största missuppfattningarna om WordPress är att köra många plugins gör att din webbplats laddas långsamt eller att många plugins orsakar uppblåsthet. Det är inte sant. Det är dåligt skrivna plugins som gör det. De som följer WordPress bästa praxis och kodningsstandarderna bör ha minimal inverkan på laddningstiden.
Med det sagt kommer det här pluginet att identifiera exakt vilka plugins som påverkar prestanda mest. Visst kan detta vara användbart när du försöker begränsa orsaken till att en webbplats utför långsamt, men det är också användbart att utföra mot din egen kod för att säkerställa att du är inte negativt påverka webbplatsens prestanda.
För alla som har gjort omfattande arbete med anpassade posttyper, anpassade rutter eller webbadresser, eller som har vunnit sig in i omskrivnings API, vet du de utmaningar som finns.
Detta plugin hjälper till att ge en visuell representation av omskrivningsreglerna för din installation. Det är användbart för att inspektera regler som finns inom det aktuella temat men också användbara för att hjälpa till att felsöka när du försöker definiera ett anpassat system och har en svår tid som spikar det vanliga uttrycket för att göra det.
Om du vill marknadsföra ditt plugin till den bredaste publiken är det möjligt att du vill testa hur det ser ut på språk som läser från vänster till höger och till höger till vänster, liksom.
Det vill säga om du vill se till att du har internationaliserat ditt tema korrekt så kommer det här pluginet att se hur ditt arbete ser ut för internationaliserade språk.
Om du vill sälja ditt tema, säg på WordPress.com, då är detta ett måste.
Om du vill se till att ditt tema är aktuellt med de aktuella riktlinjerna för WordPress Theme Review, är temakontroll ett icke-förhandlingsbart.
Det kommer att göra en automatisk granskning av ditt tema och kommer att se till att all din kod är upp till par med de nuvarande riktlinjerna. Om inte, kommer det att visa dig en ren läsning av problemen och länkarna till den riktlinje som du inte följer. Det ger också förslag på saker som du borde ha genomfört.
Observera att de flesta (om inte alla) av dessa är fritt tillgängliga från WordPress Plugin Repository så att de kan installeras direkt från WordPress.
Som jag har sagt i tidigare artiklar har många av de saker som jag har delat i denna serie varit lite subjektiva eller kanske inte fungerar i din nuvarande miljö. Även om de metoder och verktyg som jag har delat har testats och bevisats genom min egen personliga erfarenhet av att arbeta med WordPress i flera år, inser jag också att vi inte alla använder samma verktygssats.
Som sådan innebär det att en del av konfigurationen, organisationen och inställningarna kan variera för dig. Det är okej. I slutändan är poängen att vi som tematillverkare behöver göra ett bättre jobb att skriva underhållbara teman eftersom vi spenderar så mycket tid på dem efter deras första utgåva.
Kanske kan några av de saker som föreslagits i hela serien hjälpa dig att göra just det. Kanske behöver du tweak några av de förslag som matchar verktygen som du använder. Vad som än händer hoppas jag att det inte bara varit en användbar serie med några praktiska tips för att hjälpa till i din pågående temat utveckling, men att det också gavs intresse att skapa en grund för hur du organiserar och strukturerar dina projekt framåt.
Som vanligt, var god att fortsätta diskussionen med kommentarer, frågor och någon annan allmän feedback i kommenteringsgängan nedan.
