Share
När det gäller att skriva WordPress-plugins finns det i allmänhet två sätt att göra det: Objektorienterad programmering och funktionell programmering (med Widgets som undantaget - vi kommer att täcka det senare i artikeln).
Även om du i allmänhet har folk som gissar för en typ av programmering över den andra, presenterar varje sin egen uppsättning fördelar och nackdelar.
I den här tvådelade serien kommer Stephen Harris och jag att bryta ner de två sätten att du kan gå om att skriva WordPress-plugins. Specifikt kommer jag att prata om objektorienterad programmering, och han kommer att täcka funktionell programmering.
Eftersom läsarnas erfarenhetsnivå varierar kommer vi att prata om programmering på hög nivå, så om du är nybörjare, borde du inte ha något problem att följa med. Om du är en mer erfaren utvecklare, kan du hitta mer användbar information senare i artikeln.
Med det sagt, låt oss börja titta på ett objektorienterat sätt att utveckla WordPress-plugins.
Som nämnts i introduktionen kan plugins utvecklas för WordPress på två sätt:
Den andra artikeln i serien kommer att omfatta funktionell programmering, men låt oss ge en fungerande definition av objektorienterad programmering så att vi alla är på samma nivå i hela denna artikel.
Wikipedia säger:
Objektorienterad programmering (OOP) är ett programmeringsparadigm med "objekt" - vanligtvis fall av en klass - bestående av datafält och metoder tillsammans med deras interaktioner - att utforma applikationer och datorprogram.
De som är mer erfarna med datorprogrammering, speciellt De som använder objektorienterad programmeringsteknik kommer sannolikt att ha den definitionen.
Men låt oss simpify det för syftet med denna artikel:
Objektorienterad programmering är en programmeringsteknik som använder en samling relaterade metoder för att definiera ett datorprogram eller en del av ett datorprogram.
Enkelt nog, eller hur? I vårt fall är våra plugins definitivt del av ett datorprogram eftersom de hakar i WordPress.
Även om vi tittar på koden under resten av denna artikel, notera att objektorienterade program identifieras genom att gruppera deras relaterade metoder och den där görs inom ramen för vad som kallas en klass - som vi kommer att täcka tillfälligt.
Även om det är sant att WordPress-plugins kan utvecklas med hjälp av OOP eller funktionell programmering, finns det ett undantag när det gäller att utveckla Widgets.
Enligt Codexartikeln om att utveckla widgets ska följande struktur användas för att skriva en widget:
klassen My_Widget utökar WP_Widget public function __construct () // widget faktiska processer public function form ($ instance) // matar ut optionsformuläret på admin public function update ($ new_instance, $ old_instance) att sparas public function widget ($ args, $ instans) // matar in widgetens innehåll
Detta innebär att Allt Widgets ska skrivas med OOP. Om du inte har sett kod som ovan kommer vi att täcka det i nästa avsnitt och det ska ge allt du behöver veta för att förstå vad som händer.
Innan vi börjar titta på att bygga OOP-baserade plugins för WordPress, låt oss titta närmare på grunderna i OOP för att se till att vi är tydliga på terminologin och hur paradigmet fungerar.
Som vi definierade tidigare använder OOP "en samling relaterade metoder". Men vi kan inte stanna där. Funktionell programmering gör trots allt samma sak.
I OOP är dessa "relaterade metoder" alla relaterade i samband med vad som kallas a klass. I exemplet Widget ovan ser du klass sökord som det första ordet i koden.
Den börjar på en linje som slutar med en öppningsfäste (ungefär som funktioner) och sedan inkapslar - eller omsluter - alla dess relaterade funktioner innan de avslutas med stängningsfästet (för nu ignorerar sträcker nyckelord i Widgetens exempel - vi kommer att beröra det på ett ögonblick).
Om du precis börjat med att skriva klasser och du undrar om en funktion hör hemma i en viss klass, fråga dig själv om funktionen låter som något som en särskild klass skulle göra.
Till exempel, i Widgetexemplet ovan, uppdatering Metod är uppenbarligen något som en widget skulle göra. Men låt oss säga att du skriver en klass som kommer att vara ansvarig för att läsa ett blogginlägg till WordPress-databasen. Det skulle vara meningsfullt för den särskilda klassen att ha en funktion som heter läsa eller read_by_id, men ska det ha en funktion som heter skriva? Vad sägs om radera?
Beroende på hur du har utformat din klass, eventuellt. Men om enda Syftet med klassen är att läsa data, då förmodligen inte.
Och det är OOP: det logiskt grupperar dina funktioner tillsammans i en klass, men den logiska grupperingen beror på det ansvar som du ger din klass.
OOP är ett kraftfullt paradigm som är anställd i WordPress-applikationen. OOP möjliggör avancerade operationer som arv (som representeras av sträcker nyckelord i Widget-klassen), designmönster som är i huvudsak befintliga lösningar på vanliga problem.
Denna artikel försöker inte vara en djupdykning i objektorienterad programmering. Det är helt enkelt att försöka skapa en grund där vi kan utforska de två sätten att skriva WordPress-plugins, men jag nämner dem här om du skulle vara intresserad av att dyka vidare till objektorienterad programmering.
Nu när vi har definierat objektorienterad programmering och utforskat precis nog för att lägga grunden är det dags att faktiskt börja prata om komponenterna i OOP-baserad utveckling i samband med WordPress-plugins.
Under resten av denna artikel kommer vi att täcka grunderna för vad som krävs för att skriva OOP-baserade plugins och de fördelar som det medför.
Innan du gör det något I objektorienterad utveckling måste du definiera din klass. Förutsatt att du redan har en uppfattning om vad din klass ska göra, är det i allmänhet en fråga om att komma fram till vad du vill namnge din klass.
För det mesta tror jag att visningsexempelkoden alltid är fördelaktig när det gäller undervisningskod, så vi tar en titt på WordPress Plugin Boilerplate.
Observera att Plugin Boilerplate är ett projekt som jag ursprungligen skapade för att hjälpa jumpstart OOP-baserade plugins. Det har sedan dess bidragit till ett antal olika personer. Jag använder den i den här artikeln eftersom den visar det aktuella ämnet.
Med detta sagt märker du att klassdefinitionen för Plugin Boilerplate ser ut så här:
klass PluginName // Mer att komma ...
Eftersom Plugin Boilerplate är en startplats för utveckling, skulle vi uppenbarligen byta namn på klassen. För den här artikeln, låt oss ringa den DemoPlugin.
klass DemoPlugin // Mer att komma ...
Vid denna tidpunkt är vi redo att börja definiera funktioner som lever i klassen.
I OOP är den första funktionen som du kommer att se i en klass en funktion som heter "konstruktören" och PHP är inte annorlunda.
En enkel, fungerande definition av konstruktören är följande:
Konstruktorn är där du initierar data som ska användas i hela klassen.
Hur detta fungerar varierar från projekt till projekt, men det finns två primära saker som vi kan göra inom ramen för ett WordPress-plugin:
I vår DemoPlugin, Vi ska göra just det. Vi ställer in en textdomän av demo-plugin och vi registrerar åtgärder för att registrera och skriva in ett exempel på stilark och ett exempel på JavaScript-filen.
För att vara komplett i vårt exempel registrerar vi också en krok för att lägga till lite text till slutet av innehållet som visas i ett inlägg.
Låt oss först definiera konstruktören:
klass DemoPlugin public function __construct ()
Observera att i en PHP definieras en konstruktör av en offentlig funktion som heter konstruera som föregås av två underskrifter.
Låt oss nu definiera vår textdomän:
Accentsconagua
klass DemoPlugin public function __construct () load_plugin_textdomain ('demo-plugin', false, dirname (plugin_basename (__FILE__)). '/ lang'); Observera att vi har definierat nyckeln för att vår textdomän ska vara i ovanstående kodrad demo-plugin och linjen förväntar sig att hitta lokaliseringsfilerna i en underkatalog som heter lang i pluginens katalog.
Eftersom lokalisering inte är tillgänglig för denna artikel, kommer jag inte att dyka längre, men du kan granska källkoden för Plugin Boilerplate för att se hur det här är inställt.
Låt oss sedan definiera åtgärderna för att registrera våra stylesheets och JavaScript samt det filter som kommer att lägga till lite text till slutet av vårt innehåll:
klass DemoPlugin public function __construct () load_plugin_textdomain ('demo-plugin', false, dirname (plugin_basename (__FILE__)). '/ lang'); add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_styles')); add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_scripts')); add_filter ('the_content', array ($ this, 'append_post_notification')); Om du inte är bekant med handlingar och filter, se till att läsa en av mina senaste artiklar här på Wptuts + som det förklarar skillnaden.
Nu, om du är bekant med WordPress-temautveckling eller funktionell programmering, så brukar du bruka se något som följande:
add_action ('wp_enqueue_scripts', 'register_plugin_styles'); Hellre än:
add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_styles')); Observera att skillnaden i de två samtalen ovan är i den andra parametern. Specifikt, i vår plugin passerar vi en array medan den första raden av kod bara passerar en sträng.
Eftersom vi utvecklar det här pluginet med OOP, måste WordPress veta vart man ska ringa register_plugin_styles metod. Eftersom det lever i vår klass måste vi berätta för WordPress att vi ska ringa metoden på en förekomst av vår klass.
Vettigt?
I huvudsak säger vi WordPress: Jag har fått den här metoden register_plugin_styles, men du måste kalla det på en förekomst av den här klassen (därav detta nyckelord).
Om du är ny på WordPress, men kommer från en programmeringsbakgrund, kan du tänka dig att du säger WordPress att göra detta:
$ demo = ny DemoPlugin (); $ Demo-> register_plugin_styles ();
Hur som helst, är den nedersta raden att om du utvecklar dina plugins med OOP, då måste registrera dina krokar med hjälp av en array med två index: den första varelsen $ detta och den andra är namnet på funktionen.
Avancerade utvecklare kommer att känna till PHP: s förmåga att passera för referens och pass-by-värde. I WordPress Development är det inte så ovanligt att se följande:
add_action ('wp_enqueue_scripts', array (& $ this, 'register_plugin_styles')); Var detta skickas genom referens Men från PHP 5.4 har möjligheten att skicka variabler genom referens vid samtalstid tagits bort. Det är därför som denna handledning väljer att övergå efter värde.
I programmeringen är funktionerna kodens enheter som huvudsakligen är ansvariga för att "göra någonting". I objektorienterad programmering är det bra att tänka på dem lite annorlunda.
I OOP är klasser vanligtvis representerade av substantiv. I vårt fall har vi en DemoPlugin. På samma sätt är funktioner ofta verb. Det vill säga de är handlingar som vårt substantiv kan ta. Vid denna tidpunkt har vi redan valt att definiera följande funktioner:
register_plugin_stylesregister_plugin_scriptsappend_post_notificationLägg märke till hur varje funktionsnamn representerar en åtgärd som kan vidtas. Det här är en bra tumregel att använda när du skriver funktioner.
I funktionell programmering finns det egentligen bara bara tanken på funktioner; I OOP finns det dock flera olika typer av funktioner, varav två är "offentliga" funktioner och "privata" funktioner.
Offentliga funktioner är funktioner som är tillgängliga utanför klassen. Det innebär att du kan ringa dessa metoder när du har ordnat klassen.
Det här är precis vad vi gjorde tidigare i följande kod:
$ demo = ny DemoPlugin (); $ Demo-> register_plugin_styles ();
I grund och botten är dessa funktioner tillgängliga för allmänheten (där allmänheten kan vara en programmerare eller ett annat objekt).
Funktionerna som vi skriver för att registrera våra stylesheets, vår JavaScript, och att vi skriver för att lägga till text till ett inlägg ha att markeras som allmän eftersom det finns kommer Var en tredje part som ringer på dem - WordPress.
Låt oss definiera de två funktionerna för wp_enqueue_scripts verkan:
public function register_plugin_styles () wp_register_style ('demo-plugin', plugins_url ('demo-plugin / css / plugin')); wp_enqueue_style ('demo-plugin'); allmän funktion register_plugin_scripts () wp_register_script ('demo-plugin', plugins_url ('demo-plugin / js / display.js')); wp_enqueue_script ('demo-plugin'); Observera att dessa två funktioner förväntar sig att stylesheets och JavaScript finns i css och js respektive underkataloger. För att se detta i åtgärd, kom ihåg att kolla in Plugin Boilerplate.
Slutligen, låt oss definiera funktionen för innehållet filtrera:
public function append_post_notification ($ content) $ notification = __ ('Det här meddelandet bifogades med en Demo Plugin.', 'Demo-plugin-locale'); returnera $ innehåll. $ Anmälan; Observera att vi använder funktionen __ för att se till att vårt skript är lokaliserat med TEXTDOMÄN som vi definierade i konstruktören.
Om offentliga metoder är tillgängliga för alla, skulle det innebära att privata funktioner är tillgängliga för ingen, eller hur? För det mesta är det rätt: Den enda personen - eller sak - som kan kalla privata metoder är den klass där de definieras.
Det betyder att WordPress, objekt från tredje part eller programmörer kan programmera privata funktioner. Privata funktioner kan endast ringas från den klass de används.
Generellt sett är privata funktioner väldigt användbara när man skriver hjälparparationer - det vill säga de är användbara för att manipulera data internt för att hjälpa en annan funktion att utföra sitt jobb.
För att ge ett fungerande exempel, låt oss definiera en privat funktion som kommer att returnera en lokaliserad sträng som vår append_post_notification funktion kan använda:
privat funktion get_localized_notification () return __ ('Det här meddelandet bifogades med en Demo Plugin.', 'Demo-plugin-locale'); Låt oss då reflektera append_post_notification funktion för att ringa den här nya hjälpen:
public function append_post_notification ($ content) return $ content. $ This-> get_localized_notification ();
Observera att vi har förenklat den första funktionen genom att lägga till en andra funktion. Du kan också hävda att vi har ökat läsbarheten hos den ursprungliga funktionen genom att lägga till ett samtal till en funktion med ett namn som hjälper till att klargöra vad som händer.
Kanske är det viktigaste att notera att för att ringa privata funktioner måste du prefixa funktionssamtalet med $ detta sökord och ->. Detta säger PHP: "Ring till get_localized_notification funktion som lever i detta klass."
I varje fall har vi givit varje metod ett enda ansvar - en annan bra praxis i objektorienterad programmering - och vi har visat att användningen av både offentliga och privata funktioner.
I objektorienterad programmering finns det också andra typer av funktioner som ligger utanför ramen för denna artikel.
För att vara komplett vill jag sammanfatta dem här:
DemoPlugin :: use_this_static_method (). Vid denna tidpunkt har vi träffat alla höga anteckningar för objektorienterad WordPress-utveckling. För att sammanfatta fördelarna:
När du använder objektorienterad programmering behöver du inte prefixa en funktion med namnet på temat eller namnet på det plugin du arbetar på, och du behöver inte oroa dig för att namnge en funktion något som kan störa en WordPress-funktion, ett annat temans funktion eller ett annat plugins funktion.
I stället lever alla funktioner inom ramen för en annan klass. Det enda du måste försäkra dig om är att din klass inte heter något som interfererar med en annan existerande klass.
Genom att använda objektorienterad programmering kan du programmellt ringa på ditt plugin från det vanliga WordPress API.
Låt oss säga att du utvecklar ett tema och du vill ha något att göra på sidofältet som ditt plugin tillhandahåller. I sidofältet kan du faktiskt instansera ditt plugin och sedan ringa metoder på det för att få det att skriva ut information i sidofältet.
Detta är särskilt användbart när du arbetar med en mall och vill ge några standarddata om användaren inte skriver in något manuellt.
Som vi sa i början av artikeln: det här är bara ett sätt att utveckla dina WordPress-plugins. Stephens artikel kommer att omfatta hur man gör det med hjälp av funktionell programmering.
Efter att ha läst den här artikeln borde du få en bättre förståelse för objektorienterad programmering, dess fördelar, och du borde kunna följa med kod dokumenterad i Widget API, i min relaterade Widget Boilerplate, och även överallt i WordPress-kodbasen.
