WordPress-widgets: ett objektorienterat tillvägagångssätt
För år sedan skapade jag WordPress Widget Boilerplate som syftar till att vara följande:
En organiserad, underhållsbar planlösning för att bygga widgets med WordPress bästa praxis.
Sedan dess har inte mycket förändrats angående Widgets API (som vi kommer att titta på senare i det här inlägget), men vad jag anser vara "bästa praxis" har förändrats. Vidare, i vilken grad jag tycker att detta API är en solid exempel på inledande objektorienterad programmering i WordPress är hög.
Det är inte för att det använder en massa objektorienterade principer, det är inte för att det använder moderna standarder (åtminstone vad gäller modern PHP), utan för att den använder några saker som hjälper oss att känna igen några, säg, signaler gällande objektorienterad programmering i WordPress.
Och det här är något som inte bör underskattas: Om du letar efter exempel på objektorienterad programmering i WordPress, leta efter API:er som använder det.
Vidare, om du letar efter sätt att mäta din egen nivå av att utvärdera en bit kod (för att inte tala om en kodbas) för användning av klasser och några av de mer avancerade funktionerna i OOP, varför inte ha någon sorts av ett lackmustest för att se hur du mår?
Och Widgets API gör just det.
WordPress-widgets: en introduktion
Så i en mindre serie än min förra, siktar jag på att titta på Widgets API och att göra några saker:
- visa dig grundskelettet för en widget och varför den är objektorienterad,
- diskutera vilka saker du bör kunna lägga märke till och varför,
- uppdatera Widget Boilerplate direkt på den här webbplatsen först och tryck sedan ut den till GitHub,
- bygga en widget med hjälp av API:t med boilerplate som grund för vårt arbete.
Och i det här inlägget ska vi börja med den första punkten ovan.
Men först…
Innan jag går in i det här inlägget rekommenderar jag att du läser följande inlägg:
- Två pelare för objektorienterad programmering: Del 1 av 2
- Två pelare för objektorienterad programmering: Del 2 av 2
- Abstrakta klasser, del 1 – Abstraherande beteende
- Abstrakta klasser, del 2 – Abstrakta klasser och gränssnitt
När det är klart (eller om du känner att du redan har koll på ämnena) är vi redo att börja.
[restrict paid="true”]
Grunderna i Widgets API
Om du läser igenom handbokssidan på Widgets kommer du att se mycket innehåll. Det här är bra, men det är inte alltid det bästa draget när du försöker destillera innehåll till en publik som dig själv när du letar efter praktiska, objektorienterade råd.
Så jag ska plocka ut relevanta delar från API-dokumentationen och sedan tillämpa den på koden vi också tillhandahåller.
Vad är en widget?
Jag tror att de flesta av oss som arbetar med WordPress vet vad en widget är men det är viktigt att definiera termen så att vi alla arbetar utifrån samma idé. Handboken lyder:
En widget är ett PHP-objekt som matar ut lite HTML. Samma typ av widget kan användas flera gånger på samma sida (t.ex. textwidgeten). Widgets kan spara data i databasen (i alternativtabellen).
Med detta på plats, låt oss ta en titt på koden för en anpassad widget, åtminstone en del av den, och se vad vi kan få fram när det gäller dess objektorienterade karaktär.
Widget-klassen
Innan vi ens tittar på koden vet vi att det kommer att finnas någon nivå av objektorienterad programmering helt enkelt för att dokumentationen säger åt oss att göra tre saker:
- Skapa din widgets klass genom att utöka standardklassen WP_Widget och några av dess funktioner.
- Registrera din widget så att den blir tillgänglig på skärmen Widgets .
- Se till att ditt tema har minst ett widgetområde där du kan lägga till widgetarna.
I det här inlägget kommer jag att fokusera på den första punkten (även om vi så småningom kommer till hur vi introducerar våra widgets i ett tema innan serien är över).
Så låt oss lägga upp koden som den presenteras i dokumentationen och prata om vad vi kan lära oss av den:
<?php
class AcmeWidget extends WP_Widget
{
public function __construct()
{
}
public function widget($args, $instance)
{
}
public function form($instance)
{
}
public function update($newInstance, $oldInstance)
{
}
}Först märker vi att även om vi definierade en klass (som vi kan namnge vad vi vill, på mitt sätt), måste den utöka WP_Widget. Det betyder att det i WordPress-kärnan finns en WP_Widget- klass. Du kan se en välorganiserad uppdelning av källkoden på den här sidan.
För det andra indikerar nyckelordet extends att vi använder PHP-arv som är en grundpelare i objektorienterad programmering.
För det tredje finns det fyra funktioner som vi måste implementera, varav två kräver argument. Funktionerna som vi måste implementera är följande:
- __construct() som är den grundläggande klasskonstruktorn. Det är här vi måste se till att den överordnade klasskonstruktorn anropas, om det finns en, och sedan initierar vi de egenskaper vi anser vara nödvändiga för vår widget. Vi ska ta en titt på detta senare i serien.
- widget() är ansvarig för att mata ut innehållet i widgeten som användaren tillhandahåller med gränssnittet i det administrativa området. Den accepterar två parametrar – $args och $instance. Parametern $args är informationen som ska renderas på till sidan, och $instansen är en referens till instansen av widgeten (eftersom flera widgets kan renderas på en sida).
- form() visar det administrativa gränssnittet som användaren interagerar med för att styra vad som matas ut på sidans front-end. Det kräver också argumentet $instance så att informationen som tillhandahålls är för den faktiska widgeten som användaren arbetar med (mot alla instanser av widgeten).
- update() används för att spara värdena i den aktuella instansen av widgeten. Den godtar två argument. Den första är den nya instansen av widgeten med uppdateringsvärden som användaren har tillhandahållit (tänk på att uppdatera värdet på en aktiv textwidget) och det andra argumentet är det för den gamla instansen av widgeten eller kanske den tidigare instansen eller kanske " instansen som höll de tidigare värdena."
Dessa fyra funktioner krävs för att implementera som en del av Widget API, som en del av att ärva funktioner från det utökade gränssnittet, och för att producera en widgets grundläggande funktionalitet.
Detta betyder inte att fler inte kan läggas till, men på ett bra objektorienterat sätt skulle det troligen vara bäst att förvisa det beteendet till andra klasser. Men vi ska ta en titt på att göra det senare i serien när vi skapar vår egen widget.
Vilka är de viktigaste takeaways?
För att vara säker på att jag är tydlig med vad som skulle förstås av det här inlägget är det följande:
- Widgets API är objektorienterat. Den är inte bara objektorienterad eftersom den använder en klass (även om det verkligen är en bra utgångspunkt), utan också för att den ärver funktionalitet inbyggd i en redan existerande basklass.
- Närhelst vi ärver beteende från en basklass eller en överordnad klass får vi förutvecklad funktionalitet gratis. Det är en riktigt bra sak med objektorienterad programmering eftersom det tillåter oss att fokusera specifikt på den programmeringslogik som vi vill implementera.
Föreställ dig för ett ögonblick att du vill utveckla en widget men varje gång du gör det måste du skriva in all funktionalitet för att haka in i WordPress för att göra samma, repetitiva funktionalitet.
Det är här arv och objektorienterad programmering kommer in i bilden. Den repetitiva koden abstraheras till en basklass så att den bara skrivs en gång och sedan överlåts koden vi vill fokusera på att implementera.
Allt ovanstående är vad man bör förstå när man läser detta första pass vid källkoden för ett grundläggande, objektorienterat API i WordPress.
Vad kommer härnäst?
I nästa inlägg i den här serien kommer vi att titta på den objektorienterade karaktären hos Widgets API och vilka saker du bör kunna upptäcka direkt genom att läsa koden.
Detta beror på att det är viktigt att känna igen vissa objektorienterade principer i praktiken och det här är ett bra sätt att bedöma om du kan göra det eller inte. Om du är, bra! Sedan kommer det att fortsätta att hjälpa till att utveckla den muskeln. Om inte, oroa dig inte – det hjälper dig fortfarande att utveckla den muskeln.
Och det kommer att tjäna dig väl när vi fortsätter att gå mer och mer in i objektorienterad WordPress-utveckling med praktiska medel.
Den nödvändiga teorin har täckts. Så låt oss börja med att faktiskt omsätta det i praktiken.