Share
In het vorige artikel in deze serie zijn we eindelijk begonnen met het voorbereiden van de basis voor de plug-in die we gaan schrijven.
We hebben met name gekeken naar de bestandsorganisatie, de componenten en de feitelijke details van wat de plug-in gaat doen. We hebben ook de code weggelaten die we in deze zelfstudie zullen invullen.
Naast dat onze plug-in echt iets doet, gaan we het hebben over een aantal verschillende objectgerichte principes, technieken en ideeën terwijl we de plug-in doorwerken.
Merk op dat we in deze tutorial heel weinig documentatie zullen doen. We hebben de details hierover in het vorige artikel behandeld; echter, we zullen praten meer over het in het artikel na deze.
Net als bij de rest van de artikelen in deze serie, moet je ervoor zorgen dat je alles inhaalt wat we tot nu toe in de serie hebben besproken, omdat alles wat we doen voortbouwt op de vorige onderwerpen.
Ter referentie: we hebben het volgende behandeld:
Met dat gezegd, laten we verder gaan waar we gebleven waren.
Als het gaat om het schrijven van software - ongeacht het paradigma dat wordt gebruikt - gebeurt dit niet op een lineaire manier. Dat wil zeggen, we schrijven niet noodzakelijkerwijs aan het begin van het programma. Vaak - maar niet altijd - zou dat een van de laatste delen kunnen zijn waar we gelijk in hebben.
Met dat gezegd, zullen we beginnen met het werken aan elk bestand dat de plug-in vormt op een manier die logisch is naarmate we door de plug-in werken. Daarmee bedoel ik dat als we dit artikel doornemen, de zaken in het begin misschien verspreid lijken, maar hopelijk een beetje duidelijker worden naarmate we naar elk bestand kijken.
De eerste klas die we gaan voltooien, bevindt zich in includes / class-single-post-meta-manager-loader.php. Als u zich herinnert uit het vorige artikel, is deze klasse verantwoordelijk voor het coördineren van acties en filters tussen de kerninvoegtoepassing en de beheerklasse.
In zekere zin biedt het een wrapper rond de native hook API's van WordPress; het stelt ons echter in staat om onze klassen te ontkoppelen (en zo een scheiding van punten van zorg af te dwingen) zodat ze zich kunnen specialiseren op een specifiek doel.
Laten we eerst eens naar de klas kijken:
Accentsconagua
acties = array (); $ this-> filters = array (); openbare functie add_action ($ hook, $ component, $ callback) $ this-> actions = $ this-> add ($ this-> actions, $ hook, $ component, $ callback); openbare functie add_filter ($ hook, $ component, $ callback) $ this-> filters = $ this-> add ($ this-> filters, $ hook, $ component, $ callback); private functie add ($ hooks, $ hook, $ component, $ callback) $ hooks [] = array ('hook' => $ hook, 'component' => $ component, 'callback' => $ callback); $ haken teruggeven; public function run () foreach ($ this-> filters als $ hook) add_filter ($ hook ['hook'], array ($ hook ['component'], $ hook ['callback'])); foreach ($ this-> acties als $ hook) add_action ($ hook ['hook'], array ($ hook ['component'], $ hook ['callback'])); Op dit punt in de serie moet je een aantal belangrijke dingen over de klas opmerken op basis van de discussies die we tot nu toe in de serie hebben gehad.
beschermde attributies waarnaar elk verwijst arrays zoals gedefinieerd in de constructor. De ene is bestemd voor acties, de andere voor filters.openbaar functies. De ene is ontworpen om eenvoudig acties toe te voegen, de andere is ontworpen om eenvoudig filters toe te voegen. Merk op dat elk drie componenten accepteert: de haaknaam, het hoofdobject dat de functie heeft die moet worden aangeroepen en de functie die moet worden aangeroepen tijdens de daadwerkelijke uitvoering van de haak. Zie deze referentie voor meer informatie over acties en filters.privaat functie die wordt gebruikt om de vorige twee te vereenvoudigen openbaar functioneert zodanig dat we een enkele plaats hebben om de haak aan de juiste array toe te voegen.rennen De functie is die waarmee alle gedefinieerde haken worden aangesloten. Dit is wat al onze aangepaste functies registreert met WordPress.Naarmate we de rest van de plug-in verder bouwen, zien we deze specifieke klasse in gebruik.
Dit deel van de plug-in bevat alle bestanden die zich in de beheerder directory. Als u zich herinnert van het vorige artikel, hebben we een primaire klasse, een stylesheet en een enkel bestand gebruikt om de weergave van de inhoud weer te geven.
We zullen elk van deze bestanden bekijken om te zien of ze worden gebruikt, te beginnen met de kernbeheerderklasse.
Dit is de hoofdklasse die verantwoordelijk is voor het registreren van de stylesheets, de metabox, en inclusief het bestand dat de inhoud van de metabox zal weergeven.
Laten we de volledige code eens bekijken en dan bekijken we wat het doet.
versie = $ versie; 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-> versie, FALSE); openbare functie add_meta_box () add_meta_box ('single-post-meta-manager-admin', 'Single Post Meta Manager', array ($ this, 'render_meta_box'), 'post', 'normal', 'core') ; openbare functie render_meta_box () require_once plugin_dir_path (__FILE__). 'Partials / single-post-meta-manager.php'; Dit is een relatief eenvoudige les die ervan uitgaat dat je bekend bent met wp_enqueue_style en add_meta_box. Als dat niet het geval is, bekijkt u de gekoppelde artikelen en keert u vervolgens terug naar dit bericht.
Laten we vervolgens eens kijken naar wat de rest van de klas aan het doen is:
privaat kenmerk dat wordt gebruikt om de versie van de plug-in bij te houden. Deze waarde wordt doorgegeven aan de constructor van de klasse en wordt voornamelijk gebruikt om ervoor te zorgen dat we de meest recente versie van de plug-in opnemen bij het inlijven van onze stylesheets om er zeker van te zijn dat we alle bestanden die in het cachegeheugen worden opgeslagen, kapot maken deze plugin.openbaar functie die wordt gebruikt om de stylesheet te registreren die aan het dashboard is gekoppeld, en we hebben een openbare functie die wordt gebruikt om een metabox toe te voegen aan de post typ dashboard.Hoewel we later alles later gedetailleerd zullen zien, zult u misschien merken dat de functie die de stylesheets in de wachtrij plaatst nergens anders wordt vermeld. Dit is waar de lader klas zal uiteindelijk in het spel komen.
Sommige ontwikkelaars schrijven graag de markup voor metaboxweergaven binnen PHP en slaan deze op in echt lange reeksen.
Ik ben geen fan van die benadering omdat views (of partials of templates, of hoe je ze ook maar wilt noemen) en meestal worden gebruikt om data weer te geven en dus meer opmaak dan wat dan ook. Daarom denk ik dat ze hun eigen dossier moeten zijn.
In dit geval willen we een bestand dat alle metagegevens bevat die zijn gekoppeld aan het huidige bericht in a tafel element dat is opgenomen in de metabox.
De markup voor dit bestand ziet er als volgt uit:
$ post_meta_value) ?>
Hoewel de markup en de minimale PHP die in dit bestand zit, relatief eenvoudig moeten zijn, is dat wel het geval doet afhankelijk van uw kennis van de get_post_meta en get_the_ID functies.
Nadat alle metagegevens van de post zijn opgehaald, doorlopen we de informatie (gebruik een van de lusconstructies die we veel eerder hebben behandeld) en geven vervolgens zowel de meta-sleutel als de waarde weer.
Het laatste dat we moeten doen voor de inhoud in de metabox is om de stijlen op te geven in het stylesheet dat we hebben uitgezet in de kernbeheerderklasse.
Om dat te doen, zullen we het bewerken css / simpele-post-meta-manager.css.
# single-post-meta-manager-data width: 100%; # single-post-meta-manager-data .key font-weight: bold;
Het is duidelijk dat dit heel eenvoudig is. Het biedt niets bijzonders anders dan het instellen van de breedte van de tabel op 100% van de container, en het vetgedrukt de meta sleutelwaarden.
Maar dat is genoeg voor wat we nu willen doen.
Op dit punt moeten we het kerninvoegbestand definiëren. Dit is het bestand dat de plug-insversie definieert, de plug van de plug-in (die normaal gesproken wordt gebruikt bij internationalisering en andere functies), een directe aanleiding voor de Loader en die alle benodigde hooks registreert met WordPress.
Laten we de code eens bekijken en deze bekijken zodra we alles hebben gedefinieerd:
plugin_slug = 'single-post-meta-manager-slug'; $ this-> version = '0.2.0'; $ This-> load_dependencies (); $ This-> define_admin_hooks (); private function load_dependencies () require_once plugin_dir_path (dirname (__FILE__)). 'Admin / klasse-single-post-meta-manager-admin.php'; require_once plugin_dir_path (__FILE__). 'Class-single-post-meta-manager-loader.php'; $ this-> loader = new Single_Post_Meta_Manager_Loader (); private function 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 (); openbare functie get_version () return $ this-> version; De klasse bevat de volgende kenmerken:
De bovenstaande attributen zijn allemaal ingesteld in de constructor, maar er zijn ook oproepen naar verschillende andere functies.
load_dependencies wordt gebruikt om alle bestanden te importeren die in deze plug-in worden gebruikt, zoals de Admin Manager en de Loader.define_admin_hooks is hoe we profiteren van de Loader om de functies te coördineren die zijn gedefinieerd in onze Admin-klasse en die onze stijlen en onze metabox in WordPress opslokken. Op deze manier scheiden we de zorgen van onze plug-in en zorgen we ervoor dat elke klas als één doel wordt beschouwd.rennen is de functie die alles in beweging zet, zodat alle functionaliteit van de plug-in wordt uitgevoerd wanneer geactiveerd in WordPress.Behalve dat we nog steeds een laatste stuk missen: hoe kunnen we de core-pluginklasse instantiëren en het proces starten?
Om dit te doen, maken we gebruik van een bestand dat zich in de root van de plugin-map bevindt. Sommigen noemen dit een opstartbestand voor plug-ins, sommigen noemen het een bootloader en sommigen noemen dit het belangrijkste plugin-bestand.
Wat je ook kiest om het te noemen, dit is het bestand dat zich registreert bij WordPress en dat alles in beweging zet. Laten we de code eens bekijken en daarna bekijken wat het achteraf doet:
rennen(); run_single_post_meta_manager ();
De codecommentaar bovenaan het bestand is verantwoordelijk om WordPress te vertellen dat de plug-in bestaat en voldoende informatie over de plug-in te geven zodat deze in het dashboard kan worden weergegeven.
De eerste voorwaarde die u ziet, voorkomt dat het plug-insbestand rechtstreeks wordt geopend. Dit is niets meer dan een eenvoudige veiligheidsmaatregel.
Eindelijk bellen we naar eenmalig benodigd om het kerninvoegbestand toe te voegen waar we hierboven naar hebben gekeken, en dan definiëren we een functie en richten we het Single_Post_Meta_Manager en waarna we bellen rennen dat is wat alles in beweging zet.
Ten slotte bellen we naar de functie die we aan het einde van het bestand hebben gedefinieerd. Dit start het proces en brengt de plug-in tot leven.
Op dit punt hebben we de functionaliteit van onze plug-in voltooid; we zijn echter nog steeds niet klaar. Er is nog één ding dat we moeten doen om ervoor te zorgen dat we alle praktische tips volgen die in een plug-in worden opgenomen en die documentatie bieden.
In de volgende post nemen we een pauze van de langere vorm van het schrijven van artikelen, bekijken we de WordPress Documentation Standards, en dan zullen we de plug-in documenteren zodat we al zijn functionaliteit volledig afronden..
Download ondertussen de voorbeeldplug-in, ontdek hoe alles in elkaar past en zorg ervoor dat u eventuele opmerkingen of vragen over ons werk tot nu toe achterlaat.
