Objektorienterad programmering i WordPress Skapa plugin I

Vid denna tidpunkt i serien är vi till sist kunna börja bygga vårt plugin med hjälp av objektorienterade tekniker som vi har lärt oss hittills i serien.

Om du just nu går med oss rekommenderar jag starkt att fånga upp serien hittills; annars riskerar du att missa några av de viktigaste punkterna som vi kommer att demonstrera när vi bygger ut pluginet över de följande artiklarna.

En introduktion
Klasser
typer
Kontrollstrukturer: Villkorliga uttalanden
Kontrollstrukturer: Loops
Funktioner och attribut
Omfattning

Okej, så med det sagt, är det äntligen dags att börja skriva kod. Innan vi börjar är det viktigt att förstå att bygga ett plugin - eller någon typ av programvara för den delen - kräver ett antal steg, och även om vi ska skriva lite kod i den här artikeln kommer vi inte att vara lägger till mycket funktionalitet tills vi har byggnadsställningen eller grunden för plugin.

För att kunna göra det måste vi granska flera saker:

Definiera funktionerna i plugin som vi ska skriva,
Dela något som vi kanske inte bygger till den här första versionen,
Diskutera arkitekturen och filorganisationen för plugin.

Så låt oss täcka de här punkterna väldigt snabbt, och då kommer vi in i detaljerna i plugin.

Posta Meta Viewer

Under de kommande artiklarna kommer vi att bygga ett plugin som introducerar en post-metakassa i den enkla postredigeringsvyn som visar alla metadata som är kopplade till det aktuella inlägget.

1. Funktionerna

Pluggen kommer att vara skrivskyddad eftersom du bara kan se metadata som är associerade med plugin. Vi kommer inte att kunna introducera några nya metadata - åtminstone inte för den första versionen.

De andra funktionerna är att den ska visa den i ett rent, organiserat format så att vi enkelt kan identifiera nyckeln och värdena för post-ID. Vi introducerar också ett ankare som tillåter oss att kopiera en kodlinje som tillåter oss att ringa till informationen i form av get_post_meta ($ post_id, $ meta_key, $ meta_value);.

2. En stark 1,0

Innan vi går längre finns det många snygga funktioner som vi kan implementera i det här plugin.

Vi kunde introducera förmågan att:

lägg till nya metadata för anpassad post
uppdatera existerande post-metadata
radera befintlig post-metadata
sortera kolumnerna med metatangenterna
sortera kolumnerna med metavärden
… och så vidare

Men i linje med filosofin att skapa en "stark 1,0" kommer vi att bygga en mager, fokuserad grund som vi kan fortsätta att bygga ut plugin som vi passar efter denna serie.

Kanske kommer vi att täcka några av ovanstående funktioner före slutet av serien, kanske du vill presentera din egen uppsättning funktioner. Vilket som går bra. Grunden är att vi ska bygga en stark kärna av som vi kan fortsätta att iterera på för att utöka funktionaliteten.

3. Arkitektur- och filorganisationen

Så med allt det sagt, låt oss först prata genom de höga punkterna i pluginet, så tar vi en titt på hur vi ska organisera filerna och komponenterna i pluginprogrammet.

Pluggen kräver en bas plugin-fil som kommer att fungera som en typ av startläsare (eller bootstrap-fil) för att registrera sig för WordPress och för att ladda upp komponenterna i pluginprogrammet.
Pluggen behöver en klass som samordnar krokarna och de återuppringningar som används i pluginrutan. Detta hjälper till att avkalla funktionaliteten från krokarna och de klasser som är ansvariga för att faktiskt visa arbetet som gör att vi kan se till att var och en av våra klasser är specialiserade och helst utför ett enda jobb.
Pluggen kommer att behöva en klass som kommer att ansvara för att visa information i den enkla postpanelen som faktiskt kommer att göra metaboxen.
Vi behöver en core plugin-klass som registrerar alla beroenden och ger information om pluginversionen, är medveten om lastaren och administrationsfunktionaliteten för att registrera information mellan de två komponenterna.
Och äntligen behöver vi några stylesheets för att se till att informationen ser bra ut i instrumentpanelen.

Ljud förvirrande? Förhoppningsvis ser och tittar på filstrukturen och den grundläggande provkoden hjälper det här att fortsätta att göra mer mening.

Med det sagt, låt oss ta en titt på hög nivå på de komponenter som kommer att interagera med varandra, så tar vi en titt på hur filerna ska organiseras. Därefter kommer vi att sticka ut koden för pluginet som vi fyller i i nästa artikel.

Plugin Komponenter

Specifikt kommer plugin att bestå av följande komponenter - eller filer - som kommer att utgöra källan till plugin. Efter att ha tittat på fillistan tittar vi på ett diagram över hur alla styckena ska interagera.

single-post-meta-manager.php är den primära filen som registrerar pluginet med WordPress och sätter allt i gång.
klass-single-post-meta-manager-admin.php är filen som är ansvarig för att registrera och skriva in stilark samt visa användargränssnittet som innehåller postdata.
single-post-meta-manager-admin.css är det stilark som ska ställa in användargränssnittet.
klass-single-post-meta-manager-loader.php är filen som kommer att samordna åtgärder och filter mellan kärnproppen och administrationsklassen.
klass-single-post-meta-manager.php är kärnproppfilen som innehåller information om pluginversion, plugin slug information, referenser till lastaren och filen där vi instruerar lastaren vilka objekt och funktioner som är ansvariga för att visa det administrativa användargränssnittet.
README.md ger de vanliga instruktionerna för hur du kommer igång med plugin.
CHANGES.md tillhandahåller en lista över ändringar som sker i varje version av plugin som vi släpper ut.

Beroende på din erfarenhetsnivå med objektorienterad programmering kan det här eller kanske inte tyckas som många filer för en relativt enkel uppsättning funktioner. Det finns dock fortfarande mer på det: Vi kommer inte att släppa alla dessa filer i roden i plugin-katalogen.

I stället ska vi ta det ett steg längre och organisera saker i rätt kataloger också. När vi granskar det så tittar vi på organisationen av komponenterna i form av ett diagram och sedan granskar vi koden som ger byggnadsställningen för plugin.

Filorganisation

Filorganisationen är relativt enkel och är troligen bäst demonstrerad genom att använda en bild:

För att vara tydlig, här är brytningen av vad du ser på skärmbilden ovan:

admin / klass-single-post-meta-manager-admin.php
admin / css / single-post-meta-manager.admin.css
includes / klass-single-post-meta-manager-loader.php
includes / klass-single-post-meta-manager.php
språk/
single-post-meta-manager.php
CHANGES.md
README.md
license.txt

Det här är viktigt att känna igen och det finns ett par ställen i koden där vi ska registrera beroenden och det är viktigt att veta var Beroendet är så att vi kan ge rätt väg till dem.

Bygg pluggen

Vid denna tidpunkt är vi redo att börja knäppa ut de klasser som vi ska använda. Det finns flera viktiga saker att notera om koden du ska se:

Vi kommer bara att stubba ut klasserna och metoderna - vi introducerar inte någon verklig funktionalitet i den här artikeln.
I slutet av implementeringen, plugin skall visas i WordPress instrumentpanel och kan aktiveras (även om ingenting faktiskt kommer att hända).
Trots det faktum att jag tycker att dokumentationen är nyckeln till kvalitetsutveckling, kommer vi inte att presentera kommentarerna i den här artikeln eftersom det finns en avvägning: Denna artikel kan bli alltför lång med en extra detalj, eller vi kan fortsätta att ta varje aspekt av denna serie steg för steg. Jag väljer att göra det senare så att vi inte är överväldigade med mängden information.

Med det sagt, om du har frågor om koden, var god att lämna kommentarer om detta, dock kan jag säga vänta tills nästa artikel för att se svaret.

Nu vidare till koden.

Core Plugin File

Kärnproppfilen är ansvarig för att registrera pluginet med WordPress och kommer slutligen att ansvara för att importera kärnproppklassen (som vi granskar på bara en liten bit) och faktiskt sätter in plugin i rörelse.

Observera att det är villkorligt att vi har längst ner i filen. Detta säkerställer att pluginfilen inte kan nås direkt i webbläsaren.
Administrativa filer
Alla dessa filer bor i administration katalog enligt ovanstående.
Den enda inlägget Meta Manager Admin Class
Den här klassen kommer att ange stilarket och göra meta-rutan som ska användas för att visa den angivna posten meta.
version = $ version;  offentlig funktion enqueue_styles ()  allmän funktion add_meta_box () 
I den här klassen märker du att den har en enda skyddad egenskap för $ version av plugin. Detta attribut är inställt i klassens konstruktör.
Vi ser hur detta passar ihop senare i koden.
Den enkla posten Meta Manager Stylesheet
Just nu finns det ingen kod att visa för den här filen. Men fortsätt och lägg till den till admin / css underkatalog som det vi än så länge kommer att använda för att ställa in instrumentpanelen.
inkluderar
Dessa är kärna pluginfiler som ansvarar för att samordna information mellan de olika krokarna och det administrativa området för plugin.
Enkelt inlägg Meta Manager Loader
Denna klass kommer att användas av den primära plugin-klassen för att samordna alla krokar som finns i plugin och den administrativa klassen som vi definierade ovan.
Observera att i klassen ovan har vi markerat attributen som skyddad. Detta görs så att den här klassen har tillgång till dess attribut, men inga andra klasser gör det.
Dessutom har vi gått och gjort detta bara om vi underklassar den här klassen i en framtida iteration av plugin.
Enkel inlägg Meta Manager
Slutligen har vi den primära plugin-klassen som är ansvarig för att ladda beroenden, ställa in lokalen och koordinera krokarna.
plugin_slug = 'single-post-meta-manager-slug'; $ this-> version = '0.1.0';  privat funktion load_dependencies ()  privat funktion define_admin_hooks ()  public function run ()  public function get_version () returnera $ this-> version; 
Observera i koden ovan, vi har ytterligare skyddad attribut, ett par privat funktioner och a offentlig funktion som används som getter som vi ska använda när vi fortsätter att bygga ut plugin.
I nästa artikel lägger vi mycket tid i den här klassen eftersom det här är utgångspunkten för var mycket funktionalitet händer.
Kommer härnäst
Vi har täckt mycket material i den här artikeln, men det finns uppenbarligen mycket mer att göra. Förutom att tillhandahålla dokumentation för våra funktioner måste vi faktiskt genomföra funktionalitet som gör att byggnadsställningen blir till liv.
I nästa artikel i serien kommer vi att göra just det, varefter vi kommer att uppmärksamma oss på att dokumentera koden.
Som tidigare nämnts, vänligen lämna några frågor och / eller kommentarer om koden ovan. För de som är intresserade kan du alltid bläddra i det aktuella läget för projektet på GitHub.
Fram till nästa artikel!



		
			
	   
	




Koda