I den tidigare handledningen började vi prata om namnområden och autoloading med PHP i samband med WordPress-utveckling. Och även om vi aldrig faktiskt introducerade någon av dessa två ämnen, definierade vi dem och började lägga grunden för hur vi presenterar dem i en kommande handledning.
Innan vi gör det, finns det viss funktionalitet som vi behöver slutföra för att runda ut vårt plugin. Målet är att slutföra plugin och dess funktionalitet så att vi har ett grundläggande, objektorienterat plugin som dokumenteras och fungerar bra med ett försök; Det använder inte namnområden eller autoladdning.
Detta kommer i sin tur att ge oss chansen att se hur ett plugin ser ut före och efter införandet av dessa ämnen.
Innan jag fortsätter rekommenderar jag att du läser den tidigare handledningen. På det här sättet har du förståelse för vilka namnområden och autoladdning du har den aktiva versionen av insticksprogrammet tills nu (vi kommer att bygga på det) och då är du redo att Fortsätt från den tiden framåt.
När du har läst det, är du välkommen att komma tillbaka till denna handledning och återuppta ditt arbete.
Precis som med alla mina handledningar antar jag att du har en fungerande utvecklingsmiljö på din maskin. Detta inkluderar följande:
Om du är så långt in i serien (eller har läst något av mitt tidigare jobb), antar jag att du redan har något som ovanstående redan på plats.
Och när du gör det är vi redo att komma igång.
Minns från tidigare handledning:
Vi bygger ett plugin som gör det enkelt att ladda stilarketter och JavaScript-stilar i vårt plugin, och det visar en metabox som frågar användaren med en fråga för att hjälpa dem att brainstorma något om att blogga.
Ja, det är enkelt och det är inte troligt något som någon kommer att använda utanför att studera de begrepp vi täcker i den här bloggen. Men det sätt på vilket vi lär oss de begrepp som vi använder är vad som är viktigt.
Denna plugin ger oss möjligheten att göra exakt det.
I slutet av den sista handledningen lämnade vi med ett plugin som visar en slumpmässig fråga till författaren längst upp på sidofältet på skärmbilden för WordPress-inlägg.
Varje gång du uppdaterar sidan laddas en ny fråga. Som det står är det inte dåligt, men det finns några förbättringar vi kan göra när det gäller stilen på innehållet i metaboxen.
Det innebär att vi kan presentera stilark som hjälper oss att skapa en lite mer visuellt tilltalande presentation. Dessutom kommer det att ge oss en chans att utforska några mer objektorienterade tekniker som vi kan använda när vi arbetar med tillgångar som stylesheets.
Så låt oss börja.
I denna handledning används inte någon typ av förbehandlare. Jag ska bara använda vanilla CSS. Men det sätt på vilket vi inser tillgångar blir lite mer objektorienterat än vad många WordPress-utvecklare brukar se.
Detta bidrar alla till målet att använda namnområden och autoloading i denna serie. Men först, låt oss börja med att introducera dessa stylesheets, skapa nödvändiga klassgränssnitt, klasser och kommunikation med WordPress API.
I administration
katalog, skapa en underkatalog kallad tillgångar
. Inom tillgångar
katalog, skapa en underkatalog kallad css
och lägg sedan till filen admin.css
.
Den slutliga katalogstrukturen ska se ut så här:
Vi är inte redo att ge någon typ av stil ännu. I stället måste vi rikta vår uppmärksamhet åt serverns kod som ansvarar för att skriva in det här formatet.
När det gäller att registrera och enqueuing både stylesheets och JavaScript, är de flesta WordPress pluginutvecklare bekanta med de krokar som behövs för att göra just det. Specifikt hänvisar jag till admin_enqueue_scripts
och wp_enqueue_style
.
Och även om vi ska använda dessa krokar kommer vi att sätta upp det på ett enkelt, objektorienterat sätt. Nej, den här serien är inte avsedd för djupdykning i objektorienterade principer, men när det är fallet är jag glad att försöka visa dem för dig.
I objektorienterad programmering definieras ett gränssnitt som sådant:
Ett gränssnitt är en programmeringsstruktur / syntax som låter datorn genomdriva vissa egenskaper i en klass.
Ett annat sätt att tänka på det är detta:
Om du har en klass som implementerar ett gränssnitt, klassen måste definiera funktionalitet som gränssnittet dikterar.
Så om gränssnittet har två metod signaturer med en viss synlighet och namn, måste klassen som implementerar gränssnittet ha två metoder med samma synlighet och namn samt en faktisk metodimplementering.
Och det är vad vi ska göra. Först måste vi definiera vårt gränssnitt. Så i util
katalog, skapa gränssnitt-assets.php
och lägg sedan till följande kod:
Observera, gränssnittet definierar inte faktiskt funktionalitet. I stället specificerar den Vad klasserna som implementerar detta gränssnitt bör definiera.
Som du kanske tror, kommer de klasser som implementerar detta gränssnitt att ha två metoder ovan, tillsammans med en faktisk implementering för varje funktion. Och vi får se hur det fungerar tillfälligt.
Se sedan till att inkludera den här filen i huvud pluginfilen:
Därefter måste vi skapa en fil som implementerar detta gränssnitt. Eftersom vi arbetar med CSS-filer skapar vi en CSS-loader.
CSS-lastaren
Det här är klassen som ansvarar för att implementera gränssnittet och gör det faktiska arbetet med att registrera funktionen med den nödvändiga WordPress-kroken (och faktiskt ger implementeringen till funktionen).
Om du tittar på koden nedan ska den se mycket ut som något du har sett eller kanske arbetat med i ett tidigare projekt:
Koden ovan skall vara relativt lätt att följa med koden kommentarer, men jag ska redogöra för vad som händer:
i det
och enqueue
är båda funktionerna nödvändiga när klassen implementerar Assets_Interface
.i det
kallas, det registrerar enqueue
funktion med kroken som är ansvarig för att registrera ett stilark.enqueue
metod registrerar admin.css
fil och användningsområden filemtime
som ett sätt att veta om filen har ändrats eller inte (vilket gör det möjligt för oss att byta alla cachade versioner av filen när den serveras).I denna implementering är den faktiska admin.css
filen läggs till på varje sida. Lägga till en villkorlig för att kontrollera vilken sida som för närvarande är aktiv och sedan bestämma om stilarket ska läggas till eller inte kan läggas till som en handledning efter handledning. För en ledtråd, kolla in get_current_screen ()
.
Därefter måste vi inkludera den här filen i huvud pluginfilen:
Därefter måste vi inställa CSS-lastaren och ringa den
i det
metod i huvudsaktutsplus_namespace_demo
fungera:i det();Förutsatt att du har gjort allt rätt borde du kunna uppdatera Lägg till ny post sida, se källan och se
admin.css
listade som ett tillgängligt stilark.Vi har en sak att göra innan vi är redo att paketera upp den här delen av handledningen. Vi behöver faktiskt skriva lite CSS.
Stil metaboxen
Eftersom majoriteten av handledningen har fokuserat på några objektorienterade tekniker och vi fortfarande har några nya ämnen att utforska i denna serie, gör vi den här delen relativt lätt.
Snarare än att bara använda vissa standardstilar som tillhandahålls av WordPress, låt oss förbättra metaboxen bara en liten bit.
Hitta först
göra
funktion iMeta_Box_Display
klass. Låt oss ändra det så att det utmatar innehållet i filen i ett styckeelement med ID-attributet för "tutsplus-author prompt".För att göra detta ska vi introducera en ny metod som använder en WordPress API-metod för sanering av HTML.
array ('id' => array (),),); returnera wp_kses ($ html, $ allowed_html);Vi ringer sedan den här funktionen inifrån
göra
Metod för att visa innehållet i metaboxen.question_reader-> get_question_from_file ($ file); $ html = "$ fråga
"; echo $ this-> sanitized_html ($ html);Nu kan vi öppna admin.css och göra några små ändringar för att uppdatera utseendet på meta boxen i Lägg till ny post skärm. Låt oss lägga till följande CSS:
# tutsplus-author-prompt font-style: kursiv; text-align: center; färg: # 333;Och nu ska din metakassa se något som följande:
Som nämnts i början är det inget stort, men det är något som förstärker utseendet på frågan bara en liten bit.
Vad kommer härnäst?
Vid denna tidpunkt har vi introducerat ett antal olika klasser, gränssnitt och andra objektorienterade funktioner. Vi har ett plugin som använder data från en textfil, som kommunicerar med WordPress API, och som sanitiserar information innan den görs till hemsidan.
Vi har en bra grund för att börja prata om namnområden. Så i nästa handledning kommer vi att göra exakt det. Om du ännu inte har kommit in på resten av serien rekommenderar jag det eftersom vi bara kommer att fortsätta bygga vidare på vad vi har lärt oss.
Om du under tiden söker andra WordPress-relaterade material kan du hitta alla mina tidigare handledning på min profilsida och du kan följa mig på min blogg eller på Twitter.
Innan dess, glöm inte att hämta arbetsversionen av plugin (version 0.2.0) som bifogas detta inlägg. Länken är tillgänglig i sidofältet med en knapp med titeln Hämta bilagan. Och, som vanligt, tveka inte att ställa några frågor i kommentarerna!
Medel