Verktyg för att skriva bättre WordPress-kod: Composer
Även om jag tycker att titeln på den här serien och artiklarna för var och en är tillräckligt tydliga, finns det andra saker jag siktar på att göra med den här serien i motsats till de andra serierna jag har skrivit hittills också.
Specifikt två av de saker jag försöker göra är att två:
- hålla varje artikel relativt kortfattad (i jämförelse med hur tidigare artiklar har varit),
- fokusera på en sak i taget och håll beskrivningen av den kort.
Eftersom det här är medlemsinnehåll har jag inget emot att det är lite längre än vanligt, men jag vill inte heller att det ska vara så långt att det är svårt att följa. Jag vill hellre att det är en kort läsning med något praktiskt som du kan implementera efter att ha läst varje inlägg.
Och en av de saker som i hög grad hjälper till att skriva bättre WordPress-kod är Composer.
Bättre WordPress-kod med Composer
Om du har läst den här bloggen hur länge som helst, då vet du att jag är ett fan av Composer (dock är jag långt ifrån den enda som jobbar i WordPress som är det).
Och även om jag har skrivit en del material om det, har jag inte skrivit något med det specifika syftet att få dig att komma igång med det när du har läst en enda kort artikel.
Till den punkten kommer vi att behöva göra några kompromisser: Jag ska nämligen tillhandahålla ett exempel på en konfigurationsfil tillsammans med ett sätt att organisera din plugins katalog. Sedan, i nästa inlägg, kommer jag att förklara några av funktionerna i Composer.
Vad är kompositör?
Först är det viktigt att förstå vad kompositör är. Och det är lätt att recitera definitionen som den står på sajten, eller hur? Det är en beroendehanterare för PHP.
Men först, vad är ett beroende?
För vissa väcker det dock några frågor:
- Vad är ett beroende?
- Varför måste jag hantera dem?
Och om du gräver lite djupare kan du upptäcka att det är en pakethanterare, och detta väcker helt enkelt samma frågor förutom att du bara byter ut "beroende" med "paket", och du är tillbaka där du började.
Så jag ska göra vad jag kan för att göra detta så tydligt som möjligt:
Ett beroende, eller ett paket, en mjukvara som din kod använder. Det kan vara något som det förlitar sig på för funktionalitet under körning, till exempel ett sätt att göra HTTP-förfrågningar, eller det kan vara ett bibliotek för att konvertera arrayer till XML.
Composer gör det enklare att inkludera just dessa paket i ditt bibliotek genom att låta dig:
- ladda ner och inkludera paketet i ditt plugin,
- laddar din plugin automatiskt under körning,
- gör det enkelt för din plugin att instansiera eller ringa in plugin efter behov.
Det betyder att vi inte behöver beskräpa katalogerna i vår kodbas med många manuellt tillagda filer och det betyder att vi inte har användning av include eller kräver överallt.
Dessa kommer att ha sin plats, vilket jag kommer att diskutera i nästa inlägg, men de behöver inte installeras automatiskt. Istället kommer Composer att hantera dem. Därför är beroendehanteraren en del av sitt syfte.
Nu när du har det installerat har du lite sammanhang.
Använder Composer
Att skriva just det här avsnittet är lite svårt eftersom vi alla har olika behov, eller hur? Men åtminstone kan vi alla dra nytta av en autoloader.
Det är något vi alla kan använda.
Så här är vad jag ska göra:
- Jag kommer att skapa en grundläggande plugin-katalog,
- Skapa de nödvändiga filerna för att köra plugin,
- Konfigurera en enkel Composer-fil,
- Kör det
Och sedan låter jag dig se resultatet. Vi kan komma in på tredjepartsbibliotek eller andra funktioner i ett framtida inlägg (eller framtida serier, egentligen).
Men om inte annat kommer detta att visa dig hur du går tillväga för att använda Composer för att definiera en autoloader så att du kan fokusera på att skriva kod och inte på att undra om klasser ingår.
Pluginkatalogen
Jag strukturerar generellt mina plugins så här:
- det finns en bootstrap-fil som läses av WordPress,
- det finns en src- katalog där alla kataloger och PHP-filer förvaras,
- det finns en tillgångskatalog på toppnivå där bilder, JavaScript-filer och Sass-filer förvaras,
- och det finns en leverantörsmapp skapad av Composer för att hysa beroenden och autoloadern.
Ibland kan det finnas någon annan udda mapp som en inc- eller en lib -mapp, men det är mycket oregelbundet vid denna tidpunkt i den typ av arbete jag gör. Och på grund av det tänker jag inte oroa mig för det här inlägget.
Istället ser min katalog ut ungefär så här.
Leverantörskatalogen saknas eftersom jag inte har skapat en Composer-fil som används för att köra ännu. Men det får vi se innan slutet av inlägget.
Exempelfiler
Låt oss installera en exempelfil i plugin-programmet. Och när jag säger prov menar jag också enkelt.
Den här filen kommer att ha ett enda syfte: Skriv ut ett meddelande på instrumentpanelen när du loggar in på WordPress.
Kom dock ihåg att syftet med detta inte är att visa hur man skriver ett välarkitekturerat plugin. Istället är det för att visa hur man genererar en autoloader för att filerna i pluginet genereras automatiskt.
Så startbandet för pluginet ser ut så här :
Och filen som är specifikt ansvarig för att visa meddelandet ser ut så här :
Och om du är nyfiken på HTML-filen är det också enkelt :
Jag sa att det var enkelt.
Composer Configuration File
Denna speciella fil kan vara så enkel eller så komplicerad som behövs. För det här inlägget håller vi det enkelt. Målet för det här inlägget är att helt enkelt ge det ett namn, beskrivning, licens, författarna och sedan hur man ställer in autoloadern.
Ta en titt här, så ska jag förklara vad du ser precis nedanför:
{
"name": "tommcfarlin/sample-plugin",
"description": "A sample plugin used for a blog post.",
"type": "wordpress-plugin",
"license": "GPL-3.0-or-later",
"authors": [
{
"name": "Tom McFarlin",
"email": "tom@tommcfarlin.com",
"homepage": "https://tommcfarlin.com"
}
],
"autoload": {
"psr-4": {
"SamplePlugin": "src/"
}
}
}För det första bör namnet, beskrivningen, typen och licensen vara lätt nog att följa. Författarområdet är också rakt fram.
Autoload är det område vi är oroliga för just nu. Det borde vara ganska tydligt.
Kort och gott har vi ett direktiv för PSR4 som du kan läsa mer om och sedan var ett namnområde finns. Så i exemplet ovan finns allt i namnutrymmet SamplePlugin i src.
Detta är vad som talar om för autoloadern var den ska leta efter vissa filer. Och i vårt fall kommer det bara att leta efter Messenger -klassen.
Körande kompositör
Nu när vi har täckt grunderna i Composer-konfigurationsfilen är det faktiskt dags att köra den. Kom ihåg att din plugin-katalog bör se ut ungefär så här:
Ange följande kommando i din terminal :
Och du borde se något sånt här:
Förutsatt att allt har gått bra bör du kunna logga in på WordPress och aktivera plugin.
Att se allt tillsammans
När plugin-programmet är aktiverat kan du navigera till instrumentpanelen på din webbplats. Där bör du se en avvisbar notis som ser ut precis som vi såg i början av inlägget:
Om du har kommit så långt är du bra att gå! Annars dubbelkolla din syntax för att se till att allt är bra. Om något är fel, är det troligt att du inte skulle ha kunnat komma så långt och förutsatt att du har de grundläggande felsökningskonstanterna inställda, så kommer du sannolikt att se var problemet finns.
Detta är inte allt
Det finns mycket mer i Composer, och jag rekommenderar starkt att du läser dokumentationen för det. En del av detta kommer jag att täcka när jag tittar på de verktyg jag planerar att täcka senare i den här serien, men för tillfället rekommenderar jag att bekanta mig med några av konventionerna.
åh! Och jag rekommenderar inte att du kontrollerar leverantörskatalogen i ditt förråd. Det kan bli en enorm katalog senare, och det kan undergräva hela syftet med Composer.
I nästa inlägg ska jag prata om varför. Vissa människor gör det, och det är okej, och jag har gjort det förut, men det är viktigt att vara klok på när man gör det.
Missa inte att göra det. Och jag ska förklara varför i nästa inlägg.