Share
I den föregående artikeln i den här serien började vi äntligen förbereda grunden för det plugin som vi ska skriva.
I synnerhet tog vi en titt på filorganisationen, komponenterna och de faktiska detaljerna om vad plugin kommer att göra. Vi stubbar också koden som vi ska fylla i i denna handledning.
Förutom att pluginprogrammet faktiskt gör någonting kommer vi att prata om ett antal olika objektorienterade principer, tekniker och idéer när vi arbetar via pluginprogrammet.
Observera att i den här handledningen kommer vi att göra mycket lite dokumentation. Vi har täckt detaljerna om detta i föregående artikel; vi pratar dock Mer om det i artikeln som följer den här.
Som med resten av artiklarna i serien, var noga med att fånga upp allt som vi har täckt så långt i serien som allt vi gör bygger på tidigare ämnen.
Som referens har vi täckt:
Med det sagt, låt oss plocka upp var vi slutade.
När det gäller skrivprogramvara - oavsett det paradigm som används - är det inte gjort så på linjärt sätt. Det betyder att vi inte nödvändigtvis skriver på programmets startpunkt. Ofta - men inte alltid - det kan vara en av de senare delarna som vi har rätt.
Med det sagt kommer vi att börja arbeta på varje fil som utgör pluginet på ett sätt som är meningsfullt när vi arbetar via plugin. Däremot menar jag att när vi arbetar igenom den här artikeln kan det tyckas att det förstås spridda men bör förhoppningsvis bli lite tydligare när vi tittar på varje fil.
Den första klassen som vi ska slutföra ligger i includes / klass-single-post-meta-manager-loader.php. Om du kommer ihåg från föregående artikel är den här klassen ansvarig för att samordna åtgärder och filter mellan kärnpluggen och administrationsklassen.
På ett sätt tillhandahåller det ett omslag runt WordPress 'native hook APIs; Det gör det möjligt för oss att avkoppla (och därmed tillämpa en åtskillnad av bekymmer) våra klasser så att var och en kan specialisera sig på ett visst syfte.
Låt oss först titta på klassen:
Accentsconagua
åtgärder = array (); $ this-> filters = array (); offentlig funktion add_action ($ hook, $ component, $ callback) $ this-> actions = $ this-> lägg till ($ this-> actions, $ hook, $ component, $ callback); public function add_filter ($ hook, $ component, $ callback) $ this-> filters = $ this-> lägg till ($ this-> filters, $ hook, $ component, $ callback); privata funktioner lägg till ($ krokar, $ krok, $ komponent, $ callback) $ krokar [] = array ('hook' => $ hook, 'component' => $ komponent, 'callback' => $ callback); returnera $ krokar; public function run () foreach ($ this-> filter som $ hook) add_filter ($ hook ['hook'], array ($ hook ['komponent'], $ hook ['callback'])); foreach ($ this-> åtgärder som $ hook) add_action ($ hook ['hook'], array ($ hook ['component'], $ hook ['callback'])); Vid denna tidpunkt i serien bör du märka flera viktiga saker om klassen baserat på de diskussioner som vi hittills haft i serien.
skyddad attribut som vart och ett refererar till arrayer som definieras i konstruktören. En är utsedd för åtgärder, den andra för filter.offentlig funktioner. En är utformad för att enkelt lägga till åtgärder, den andra är utformad för att enkelt lägga till filter. Observera att var och en accepterar tre komponenter: kroknamnet, huvudobjektet som har den funktion som ska ringas och den funktion som ska ringas under krokens verkliga utförande. Mer information om åtgärder och filter finns i denna referens.privat funktion som används för att förenkla de två föregående offentlig Funktionerna så att vi har en enda plats för att lägga till kroken på rätt sätt.springa funktionen som används för att ansluta alla de definierade krokarna. Det här är vad som registrerar alla våra anpassade funktioner med WordPress.När vi fortsätter att bygga resten av plugin ser vi den här klassen som används.
Den här delen av plugin innehåller alla filer som finns i administration katalogen. Om du kommer ihåg från föregående artikel har vi en primärklass, ett stilark och en enda fil som används för visning av innehållet.
Vi tittar på var och en av dessa filer så att de används från och med kärnadministratorklassen.
Detta är kärnklassen som är ansvarig för att registrera stilarken, meta-rutan och inklusive filen som kommer att göra innehållet i metaboxen.
Låt oss ta en titt på hela koden och sedan granskar vi vad det gör.
version = $ version; public function enqueue_styles () wp_enqueue_style ('single-post-meta-manager-admin', plugin_dir_url (__FILE__). 'css / single-post-meta-manager-admin.css', array (), $ this-> version, felaktig); offentlig funktion add_meta_box () add_meta_box ('single-post-meta-manager-admin', 'Single Post Meta Manager', array ($ this, 'render_meta_box'), 'post', 'normal', 'core') ; offentlig funktion render_meta_box () require_once plugin_dir_path (__FILE__). 'Deltonerna / single-post-meta-manager.php'; Det här är en relativt enkel klass som förutsätter att du är bekant med wp_enqueue_style och add_meta_box. Om inte, granska de länkade artiklarna och återvänd sedan till det här inlägget.
Låt oss då ta en titt på vad resten av klassen gör:
privat attribut som används för att spåra versionen av plugin. Det här värdet överförs till klassens konstruktör och används främst för att se till att vi inkluderar den senaste versionen av pluginet när vi lägger in våra stylesheets för att se till att vi stöter på filer som kan cachas när de körs denna plugin.offentlig funktion som används för att registrera stilarket som är kopplat till instrumentbrädan, och vi har en offentlig funktion som används för att lägga till en metakassa till posta skriv instrumentpanelen.Även om vi ser att allt spelas ut mer i detalj senare, kan du börja märka att funktionen som kodar stilarken inte refereras någon annanstans. Det är här Lastare klassen kommer så småningom att komma i spel.
Vissa utvecklare tycker om att skriva uppmärkningen för meta-boxvisningar inom PHP och lagra dem i riktigt långa strängar.
Jag är inte en fan av det här tillvägagångssättet, eftersom synpunkter (eller delar eller mallar, eller vad du än vill kalla dem) och vanligtvis används för att visa data och därmed bestå av mer markup än vad som helst annat. För det ändamålet anser jag att de borde vara sin egen fil.
I det här fallet vill vi ha en fil som gör alla metadata kopplade till det aktuella inlägget i en tabell element som ingår i metaboxen.
Markeringen för den här filen ser ut så här:
$ post_meta_value) ?>
Även om uppräkningen och det minsta PHP som finns i den här filen borde vara relativt självförklarande, det gör beror på din kunskap om get_post_meta och get_the_ID funktioner.
När alla postens metadata hämtas, släpper vi sedan igenom informationen (med en av de slingkonstruktioner som vi täckte mycket tidigare) och sedan visar både metatangenten och värdet.
Det sista som vi behöver göra för innehållet i metakassen är att tillhandahålla stilerna i stilarket som vi har kalkylerat i kärnadministratorklassen.
För att göra det ska vi redigera css / enkel postmeta manager.css.
# single-post-meta-manager-data bredd: 100%; # single-post-meta-manager-data. key font-weight: bold;
Självklart är detta mycket enkelt. Det ger inte något annat än att sätta bredden på bordet till 100% av behållaren, och det dristar meta-nyckelvärdena.
Men det räcker för vad vi vill göra nu.
Vid denna tidpunkt måste vi definiera kärnprofilfilen. Det här är filen som definierar pluginversionen, pluginens slug (som normalt används i internationalisering och andra funktioner), instansierar Loader och registrerar alla nödvändiga krokar med WordPress.
Låt oss ta en titt på koden och sedan granska den när vi har definierat allt:
plugin_slug = 'single-post-meta-manager-slug'; $ this-> version = '0.2.0'; $ This-> load_dependencies (); $ This-> define_admin_hooks (); privata funktioner load_dependencies () require_once plugin_dir_path (dirname (__FILE__)). 'Admin / klass-single-post-meta-manager-admin.php'; require_once plugin_dir_path (__FILE__). 'Klass-single-post-meta-manager-loader.php'; $ this-> loader = new Single_Post_Meta_Manager_Loader (); privat funktion define_admin_hooks () $ admin = new Single_Post_Meta_Manager_Admin ($ this-> get_version ()); $ this-> loader-> add_action ('admin_enqueue_scripts', $ admin, 'enqueue_styles'); $ this-> loader-> add_action ('add_meta_boxes', $ admin, 'add_meta_box'); public function run () $ this-> loader-> run (); offentlig funktion get_version () returnera $ this-> version; Klassen innehåller följande attribut:
Ovanstående attribut sätts alla i konstruktören, men det finns också samtal till flera andra funktioner.
load_dependencies används för att importera alla filer som används i hela det här pluginet, t.ex. Adminhanteraren och Loader.define_admin_hooks är hur vi utnyttjar Loader för att samordna de funktioner som definierats i vår administratörsklass, som förkroppsligar våra stilar och vår meta-box med WordPress. Så här skiljer vi oss från vår plugin och ser till att varje klass är ett enda syfte.springa är funktionen som sätter allt i rörelse så att alla plugins funktionalitet körs när den aktiveras inom WordPress.Bortsett från att vi fortfarande saknar ett sista stycke: hur instanserar vi faktiskt kärnproppklassen och startar processen?
För att göra detta utnyttjar vi en fil som ligger i roten i plugin-katalogen. Vissa kallar det här för en plugin bootstrap-fil, vissa kallar det för en startläsare, och vissa kallar det för huvud pluginfilen.
Oavsett vad du väljer att kalla det, är det filen som registrerar sig med WordPress och som sätter allt i rörelse. Låt oss ta en titt på koden och sedan granskar vi vad den gör efteråt:
springa(); run_single_post_meta_manager ();
Kodkommentaren högst upp i filen är ansvarig för att berätta för WordPress att plugin finns och ger tillräckligt med information om plugin så att den kan visa den i instrumentbrädan.
Den första villkor som du ser hindrar pluginfilen från att nås direkt. Det här är inget annat än en helt enkelt säkerhetsåtgärd.
Slutligen ringer vi till require_once att inkludera kärnprofilfilen som vi tittade på ovan, och då definierar vi en funktion och instanserar Single_Post_Meta_Manager och efter vilka vi kallar springa vilket är vad som sätter allt i rörelse.
Slutligen ringer vi till den funktion som vi definierade i slutet av filen. Detta startar processen och ger pluggen till liv.
Vid denna tidpunkt har vi slutfört funktionaliteten för vårt plugin; Vi är dock fortfarande inte färdiga. Det finns fortfarande en sak vi behöver göra för att se till att vi följer alla de bästa metoderna som går in i ett plugin och det ger dokumentation.
I nästa inlägg tar vi en paus från den längre formuläret av skrivartiklar, granskar WordPress-dokumentationsstandarderna och sedan dokumenterar vi plugin så att vi fullständigt runda ut hela dess funktionalitet.
Under tiden ladda ner exemplet plugin, utforska hur allt passar ihop, och var noga med att lämna några kommentarer eller frågor som du har om vårt arbete hittills.
