Share
Vid denna tidpunkt i serien är vi redo att flytta framåt med att avrunda vårt plugin genom att dokumentera våra filer, klasser, funktioner, variabler och mer.
Även om detta är det sista steget som vi faktiskt måste slutföra pluginet, är det inte det sista inlägget i serien eftersom vi fortsätter att titta på några avancerade ämnen i objektorienterad programmering.
Men innan vi gör det, låt oss ta med plugin till version 1.0 genom att utöva allt vi lärde oss i föregående artikel.
Naturligtvis, som med Allt tidigare artiklar rekommenderar jag att fånga upp allt som vi har täckt så här långt så att du är helt snabbare inte bara med det arbete som vi har gjort i den senaste artikeln, men med hur vi faktiskt kom till de sista punkterna vi diskuterar i den här artikeln.
Med alla de som omfattas och granskas, låt oss börja med att dokumentera alla våra filer.
Det finns ett antal olika sätt att vi kan göra om att dokumentera det här plugin:
Självfallet kommer alternativet att ge mer dokumentation per sektion, men borde resultera i en mycket mindre tråkig artikel och en mycket lättare förståelse av kontrollflödet för hela pluginprogrammet.
För det ändamålet kommer vi att arbeta genom plugin, fil-för-fil, introducera dokumentation för varje kod som vi har och då diskuterar vi några intressanta platser efter koden.
Slutligen ska vi se till att vi hänvisar till den slutliga versionen av pluginet i slutet av artikeln. Med det sagt, låt oss börja.
Minns att huvudfilen för att starta plugin är filen single-post-meta-manager.php som ligger i roten i plugin-katalogen.
Så här ser den fullständigt dokumenterade versionen av filen ut. Läs varje kommentar noggrant och uppmärksamma inte bara det format som följer, men innehållet som det ger.
springa(); // Ring ovanstående funktion för att börja implementera plugin. run_single_post_meta_manager ();
I ovanstående kod märker vi att vi har definierat en filhuvud enligt de konventioner som vi skisserade det i föregående artikel. Vi behöll också de nödvändiga plugin header taggarna för att WordPress ska kunna läsa dem korrekt.
Observera att vi i det här fallet har inkluderat dem under en anpassning @ Word-plugin märka. Detta behövs inte, men hjälper till att separera filhuvudkommentaren från de nödvändiga plugin-kommentarerna.
Slutligen notera att vi har stött versionen av det här pluginet till 1,0, och vi har också gett denna plugin till @paket värdet av SPMM vilket är brist på Enkel inlägg Meta Manager. Vi använder det här genom pluginprogrammet.
Accentsconagua
innefattar DirectoryLåt oss nu uppmärksamma alla filer som finns i katalogen inklusive.
Eftersom dessa filer krävs före någonting i administratorkatalogen är det meningsfullt att titta på var och en av dessa filer individuellt och sedan avsluta vår diskussion med de återstående filerna i administratorkatalogen.
plugin_slug = 'single-post-meta-manager-slug'; $ this-> version = '1.0.0'; $ This-> load_dependencies (); $ This-> define_admin_hooks (); / ** * Importerar Meta-administrationsklasserna med enstaka poster och Meta Loader för enstaka post. * * Administrations klassen Meta Manager definierar all unik funktion för * introduktion av anpassad funktionalitet i WordPress instrumentpanel. * * Den enkla posten Meta Manager Loader är klassen som ska samordna krokarna och callbacks * från WordPress och plugin. Denna funktion instanserar och anger referensen till egenskapen * $ Loader class. * * @access privat * / privat funktion 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 (); / ** * Definierar krokarna och återuppringningsfunktionerna som används för att ställa in plugin stylesheets * och pluginens metakassa. * * Den här funktionen är beroende av enstaka Meta Manager Admin-klassen och egenskapen Single Post Meta Manager * Loader-klass. * * @access privat * / 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'); / ** * Ställer in den här klassen. * * Exekverar plugin-programmet genom att ringa köra-metoden för lastarklassen som ska * registrera alla krokar och återuppringningsfunktioner som används i plugin-programmet * med WordPress. * / public function run () $ this-> loader-> run (); / ** * Returnerar nuvarande version av plugin till den som ringer. * * @returnsträng $ this-> version Den nuvarande versionen av plugin. * / public function get_version () returnera $ this-> version; Det finns klart mycket av nya kommentarer som har introducerats i den här filen. Det borde dock vara mycket självförklarande vad varje klassfastighet, konstruktören och de interna funktionerna gör.
Det viktigaste att notera - bortsett från hur informationen samordnas genom pluginprogrammet - är hur vi har följt de standarder som definierats i föregående artikel.
Observera dock att vi ha tog friheten om inte Använda vissa taggar och / eller funktioner i dokumentationen när de inte är relevanta. Det här är något som vi fortsätter att göra under resten av artikeln.
åtgärder = array (); $ this-> filters = array (); / ** * Registrerar åtgärderna med WordPress och respektive objekt och * deras metoder. * * @param string $ hook Namnet på WordPress-kroken till vilken vi registrerar en återuppringning. * @paramobjekt $ komponent Objektet som innehåller metoden som ska kallas när kroken avfyras. * @param string $ callback Funktionen som finns på den angivna komponenten. * / public function add_action ($ hook, $ component, $ callback) $ this-> actions = $ this-> lägg till ($ this-> actions, $ hook, $ component, $ callback); / ** * Registrerar filtren med WordPress och respektive objekt och * deras metoder. * * @param string $ hook Namnet på WordPress-kroken till vilken vi registrerar en återuppringning. * @paramobjekt $ komponent Objektet som innehåller metoden som ska kallas när kroken avfyras. * @param string $ callback Funktionen som finns på den angivna komponenten. * / public function add_filter ($ hook, $ component, $ callback) $ this-> filters = $ this-> lägg till ($ this-> filters, $ hook, $ component, $ callback); / ** * Registrerar filtren med WordPress och respektive objekt och * deras metoder. * * @access privat * * @param array $ krokar Samlingen av befintliga krokar för att lägga till i samlingen av krokar. * @param string $ hook Namnet på WordPress-kroken till vilken vi registrerar en återuppringning. * @paramobjekt $ komponent Objektet som innehåller metoden som ska kallas när kroken avfyras. * @param string $ callback Funktionen som finns på den angivna komponenten. * * @return array Samlingen av krokar som är registrerade med WordPress via denna klass. * / privat funktion lägg till ($ krokar, $ krok, $ komponent, $ callback) $ krokar [] = array ('hook' => $ hook, 'component' => $ komponent, 'callback' => $ callback) ; returnera $ krokar; / ** * Registrerar alla definierade filter och åtgärder med WordPress. * / 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'])); Observera att den här klassen är mer eller mindre en kärnkomponent i pluginet genom att det samordnar alla åtgärder och filtren som används i pluginprogrammet. Denna plugin centraliserar all registrering och samordning av krokarna som används under plugin.
Slutligen när springa kallas, alla krokarna är registrerade med WordPress så när pluggen brinner, kommer det att ringa varje registrerad handling och filter.
administration DirectoryVid denna tidpunkt är vi redo att uppmärksamma filerna i administratörskatalogen i pluginprogrammet.
Även om filen består av ett par PHP-filer, består det också av en CSS-fil. I den här artikeln kommer vi inte att dokumentera CSS-filerna. men WordPress Codex gör definiera dokumentation för detta.
För närvarande, men låt oss fortsätta att dokumentera de klasser och filer som finns i administration katalog.
Administrationsmetoden för enstaka Meta Manager har ett enda ansvar: Definiera funktionaliteten för att göra meta-rutan och dess stilar för instrumentbrädan.
version = $ version; / ** * Innehåller stilarket som ansvarar för utformning av innehållet i denna * meta box. * / public function enqueue_styles () wp_enqueue_style ('single-post-meta-manager-admin', plugin_dir_url (__FILE__). 'css / single-post-meta-manager-admin.css' > version, felaktig); / ** * Registrerar meta-rutan som ska användas för att visa alla post-metadata * som är associerade med det aktuella inlägget. * / public function add_meta_box () add_meta_box ('single-post-meta-manager-admin', 'Single Post Meta Manager', array ($ this, 'render_meta_box'), 'post', 'normal' ); / ** * Kräver filen som används för att visa användargränssnittet i postmetaboxen. * / public function render_meta_box () require_once plugin_dir_path (__FILE__). 'Deltonerna / single-post-meta-manager.php'; Observera att klassen ovan har mycket få funktionella detaljer. I första hand behåller klassen en hänvisning till versionen av plugin, stilarket som används för att ställa metaboxen och den funktion som krävs för att faktiskt göra meta-rutan.
Kom ihåg att allt detta är inställt i core plugin-filen och lastaren. Detta hjälper till att koppla bort logiken som finns i plugin så att varje klass kan fokusera på vad som är dess främsta syfte.
Självklart bygger det sista stycket av plugin på den faktiska partiella filen som innehåller den markering som är nödvändig för att visa metaboxen.
$ post_meta_value) ?>
Detta borde vara relativt självförklarande; Men för att vara fullständig, notera att den här filen tar det aktuella post-ID (genom användningen av get_the_ID () funktionen), läser metadata efter posten och sedan iterates genom att bygga ett bord som visar tangenterna och värdena.
Vid denna tidpunkt har vi genomfört implementeringen av vårt plugin. Från att sätta in de objektorienterade programmeringsprogrammerna på plats, för att dokumentera koden.
Du kan ta den slutliga versionen av plugin på GitHub; Vi kommer dock att fortsätta vår objektorienterade diskussion om några fler inlägg så att vi kan utforska några mer avancerade ämnen som arv, abstraktion och andra ämnen.
Under tiden, om du har frågor eller kommentarer om plugin-programmet, tveka inte att lämna dem i kommentarerna!
