Konstruktören är ansvarig för att ställa in flera egenskaper på widgeten, oftast dess namn och beskrivningen av den.
Widgetfunktionen är ansvarig för att rendera innehållet i widgeten.
Formulärfunktionen ansvarar för att visa formuläret i administrationsområdet för WordPress när du arbetar med widgeten.
Uppdateringsfunktionen ansvarar för att uppdatera de alternativ som sparas i databasen (eller initieras och sedan spara de alternativ som kanske ännu inte finns i databasen).

Det fina är att just detta tillvägagångssätt uppnås genom att ärva en funktionalitet för klassen WP_Widget.

Problemet är dock att det är mycket arbete för en enskild klass att göra.

Istället borde vi separera var och en av funktionerna i sitt eget funktionsområde.

Som med allt inom programmering kommer det att finnas sätt där vissa saker är tydliga om hur de kan göras och sedan kommer det att finnas några saker som kan göras på flera sätt.

Det jag ska presentera är hur jag förhåller mig till det nu. Detta kan förändras i framtiden, eller kanske inte, och andra kan ha en annan syn på det.

Oavsett vilket kommer implementeringen att bli mycket mer objektorienterad och kommer att ge varje klass sin egen uppsättning ansvarsområden.

Den första frågan är dock hur vi delar upp en klass med fyra funktioner och som ärver från en överordnad klass?

Uppdaterar The Bootstrap

För det första finns det några saker vi behöver justera i pluginets bootstrap. Vi behöver nämligen göra följande:

instansiera registret och göra det tillgängligt genom projektet,
uppdatera plugin-klassen så att den accepterar ett register och laddar prenumeranterna,
granska bootstrapen

Här är en titt på alla tre ovanstående.

1 Instantiera registret

Eftersom vi redan har tagit upp detta tidigare i serien borde det vara klart hur man gör detta.

Se först följande kod :

Lägg sedan märke till att vi instansierar registret (vi kommer att prata om dess namnområde för en stund) och sedan kopplar vi in det i ett anpassat filter som låter oss komma åt det genom hela pluginet när vi vill.

2 Uppdatera pluginklassen

Därefter måste vi uppdatera kärnpluginklassen (som finns i src- katalogen) så att den refererar till registret och laddar alla registrerade prenumeranter :

Observera dock att vi inte riktigt har skapat några prenumeranter än. Vi började med det här tidigare i serien och nu är det dags att återkomma till det men vi gör det senare.

Vi behöver dock lägga till en funktion – även om den är tillfällig – så att vi kan lägga till klasser som inte är explicita händelseprenumeranter:

Detta kommer att omarbetas senare eftersom vi kommer att förvandla kärnklasser till prenumeranter senare.

3 Granska Bootstrap

Innan jag går vidare tycker jag att det är viktigt att se över bootstrap. Även om din rubrik och dokumentation kan variera, är det viktigt att notera att vi gör följande:

namnavstånd från bootstrap,
förhindrar åtkomst till filen,
ringer autoloadern,
ställa in registret,
och starta plugin.

Det låter som mycket men koden är ganska kort :

Vid det här laget är det dock dags att titta på hur det är att dela upp barnklassen från standard -API:et Widgets till något som passar med den kodmodell som vi arbetar med.

Dela upp en barnklass

Den här delen kommer sannolikt att sträcka sig över några inlägg eftersom det finns lite arbete att göra, men vi börjar med att skapa vår egen widgetklass som kommer att ärva från basklassen Widget.

Gör först en API- katalog i src -katalogen och lägg till en fil som heter Widget.php. Det är här grunderna i widgeten kommer att ligga. Vi kommer in på administrativa och offentliga stilmallar och JavaScript-filer i nästa inlägg.

Vid denna tidpunkt bör grunderna för filen se ut så här :

Observera att det krävs ett enda argument. Jag har använt widget-namn men du kan använda vad det är du vill så länge det representerar din widget.

Detta för att visa att klassen instansieras och laddas korrekt när plugin-programmet aktiveras. Om du inte ser detta är något som inte stämmer (vilket vi kommer att granska ett ögonblick).

Därefter är det viktigt att se till att den här klassen läggs till i registret. Så lägg till följande rader i koden i bootstrap:

Och nu, när du aktiverar plugin, bör du se följande:

Om inte, se till att granska koden i utvecklingsgrenen för att se till att du har allt som beskrivs i det här inlägget.

Implementering av prenumeranter

I de kommande inläggen kommer vi att titta på hur vi kan implementera prenumeranter för den offentliga sidan av webbplatsen (det vill säga där widgetinnehållet visas). Och vi kommer att göra samma sak för sajtens administrationsområde.

Slutligen kommer vi att rikta vår uppmärksamhet mot koden som är ansvarig för att säkra och serialisera data (läs: uppdatera vår widget), och sedan se hur den slutliga versionen av en uppdaterad boilerplate ser ut.

I det här inlägget är dock den primära strategin som vi använder att dela upp en barnklass så att den fortfarande kan användas med andra klasser med gränssnitt och basklasser som redan är definierade i kodbasen.

Inspelningskälla: tommcfarlin.com