Object-georiënteerd programmeren in WordPress de plug-in I bouwen

Op dit punt in de serie zijn we dat Tenslotte in staat om te beginnen met het bouwen van onze plug-in met behulp van de object-georiënteerde technieken die we tot nu toe in de serie hebben geleerd.

Als je je nu net aanmeldt, raad ik je aan om de serie tot nu toe in te halen; anders loop je het risico enkele van de belangrijkste punten te missen die we gaan demonstreren, terwijl we de plug-in uitwerken in de komende paar artikelen.

Een introductie
Klassen
Types
Controlestructuren: voorwaardelijke overzichten
Besturingsstructuren: lussen
Functies en kenmerken
strekking

Oké, dus met dat gezegd, is het eindelijk tijd om te beginnen met het schrijven van code. Voordat we beginnen, is het belangrijk om te begrijpen dat het bouwen van een plug-in - of welke software dan ook - een aantal stappen vereist, en hoewel we in dit specifieke artikel een beetje code gaan schrijven, zullen we niet het toevoegen van veel functionaliteit totdat we de steiger of de basis van de plug-in hebben.

Om dat te doen, moeten we verschillende dingen bekijken:

De functies definiëren van de plug-in die we gaan schrijven,
Deel alles wat we misschien niet bouwen aan deze eerste versie,
Bespreek de architectuur en de bestandsorganisatie van de plug-in.

Laten we die punten dus snel behandelen, en dan zullen we ingaan op de details van de plug-in.

Post Meta Viewer

In de volgende paar artikelen gaan we een plug-in bouwen die een post-metabox introduceert in de weergave voor één berichteditor die alle metagegevens weergeeft die zijn gekoppeld aan het huidige bericht.

1. De functies

De plug-in is alleen-lezen, alleen dat kan uitzicht de metagegevens die zijn gekoppeld aan de plug-in. We zullen geen nieuwe metagegevens kunnen introduceren - althans niet voor de eerste versie.

De andere functies zijn dat het deze in een overzichtelijke indeling weergeeft, zodat we de sleutel en de waarden voor de post-ID gemakkelijk kunnen identificeren. We introduceren ook een anker waarmee we een coderegel kunnen kopiëren die ons in staat stelt om de informatie in de vorm van get_post_meta ($ post_id, $ meta_key, $ meta_value);.

2. Een sterke 1.0

Voordat we verder gaan, zijn er veel leuke functies die we in deze plug-in kunnen implementeren.

We kunnen het vermogen introduceren om:

voeg nieuwe aangepaste metagegevens toe
update van de metadata van de post
verwijder bestaande post-metadata
sorteer de kolommen met meta-toetsen
sorteer de kolommen op meta-waarden
… enzovoorts

Maar in overeenstemming met de filosofie van het creëren van een "sterke 1.0", zullen we een lean, gefocuste basis bouwen waarop we door kunnen gaan met het uitbouwen van de plug-in die we geschikt achten na deze serie.

Misschien bespreken we enkele van de bovenstaande functies vóór het einde van de serie, misschien wilt u uw eigen set functies introduceren. Beide manieren zijn prima. De bottom line is dat we een sterke kern gaan bouwen waarvan we door kunnen gaan met het herhalen van de functionaliteit.

3. De architectuur en bestandsorganisatie

Laten we dus, met al het voorgaande gezegd, eerst de hoogtepunten van de plug-in bespreken, dan zullen we kijken hoe we de bestanden en componenten van de plug-in organiseren.

Voor de plug-in is een bestand met een basisplug-in nodig dat als een soort opstartlader (of bootstrap-bestand) zal dienen om zichzelf te registreren voor WordPress en om de componenten van de plug-in op te laden.
De plug-in heeft een klasse nodig die de hooks en callbacks coördineert die door de plug-in worden gebruikt. Dit zal helpen de functionaliteit los te koppelen van de hooks en de klassen die verantwoordelijk zijn voor het daadwerkelijk tonen van het werk, wat ons in staat stelt om ervoor te zorgen dat elk van onze klassen gespecialiseerd is en idealiter een enkele taak uitvoert.
De plug-in heeft een klasse nodig die verantwoordelijk is voor het weergeven van informatie in het dashboard met één bericht dat de metabox daadwerkelijk rendert.
We hebben een core-plugin-klasse nodig die alle afhankelijkheden registreert en informatie verschaft over de versie van de plug-in, die op de hoogte is van de lader en de beheerfunctionaliteit om informatie tussen de twee componenten te registreren.
En tot slot hebben we een aantal stylesheets nodig om ervoor te zorgen dat de informatie er goed uitziet in het dashboard.

Geluid verwarrend? Hopelijk helpt dit om de bestandsstructuur en de standaard voorbeeldcode te bekijken en te blijven volgen.

Laten we met dat gezegd, een hoog niveau bekijken van de componenten die met elkaar communiceren, dan zullen we kijken hoe de bestanden zullen worden georganiseerd. Hierna gaan we in op de code voor de plug-in die we in het volgende artikel zullen invullen.

Componenten invoegen

In het bijzonder zal de plug-in bestaan uit de volgende componenten - of bestanden - die de bron van de plug-in vormen. Na het bekijken van de bestandslijst, bekijken we een diagram van hoe alle stukjes zullen samenwerken.

single-post-meta-manager.php is het primaire bestand dat de plug-in registreert bij WordPress en alles in beweging zet.
class-single-post-meta-manager-admin.php is het bestand dat verantwoordelijk is voor het registreren en in de wacht zetten van stylesheets en het weergeven van de gebruikersinterface-elementen die de post-metadata bevatten.
single-post-meta-manager-admin.css is de stylesheet die de gebruikersinterface zal stylen.
class-single-post-meta-manager-loader.php is het bestand dat acties en filters coördineert tussen de kerninvoegtoepassing en de beheerklasse.
class-single-post-meta-manager.php is het kerninvoegbestand met plug-in versie-informatie, plugin slug-informatie, verwijzingen naar de loader en het bestand waarin we de lader instrueren welke objecten en functies verantwoordelijk zijn voor het weergeven van de administratieve gebruikersinterface.
README.md biedt de gebruikelijke instructies om aan de slag te gaan met de plug-in.
CHANGES.md biedt een lijst met wijzigingen die optreden in elke versie van de plug-in die we vrijgeven.

Afhankelijk van je niveau van ervaring met objectgeoriënteerd programmeren, kan dit al dan niet lijken op veel bestanden voor een relatief eenvoudige reeks functies; er is echter nog meer aan de hand: we zullen niet al deze bestanden in de root van de plugin-directory plaatsen.

In plaats daarvan gaan we een stap verder gaan en dingen organiseren in de juiste mappen. Zodra we dat hebben bekeken, bekijken we de organisatie van de componenten in de vorm van een diagram. Vervolgens bekijken we de code die de steiger voor de plug-in biedt.

Bestandsorganisatie

De bestandsorganisatie is relatief eenvoudig en wordt waarschijnlijk het best gedemonstreerd door het gebruik van een afbeelding:

Voor de duidelijkheid, hier is de opsplitsing van wat u ziet in de bovenstaande schermafbeelding:

admin / class-single-post-meta-manager-admin.php
admin / css / single-post-meta-manager.admin.css
includes / class-single-post-meta-manager-loader.php
includes / class-single-post-meta-manager.php
talen /
single-post-meta-manager.php
CHANGES.md
README.md
LICENSE.txt

Dit is belangrijk om te herkennen en er zijn een aantal plaatsen in de code waar we afhankelijkheden registreren en het is belangrijk om te weten waar de afhankelijkheden zijn zo dat we de juiste paden naar hen kunnen bieden.

De plug-in bouwen

Op dit moment zijn we klaar om te beginnen met het uitbannen van de klassen die we gaan gebruiken. Er zijn verschillende belangrijke dingen om op te merken over de code die u gaat zien:

We gaan alleen de klassen en methoden uitbannen - we zullen in dit artikel geen echte functionaliteit introduceren.
Aan het einde van de implementatie, de plug-in moeten verschijnen in het WordPress-dashboard en kunnen worden geactiveerd (hoewel er eigenlijk niets gebeurt).
Ondanks het feit dat ik denk dat documentatie essentieel is voor de ontwikkeling van kwaliteit, introduceren we de opmerkingen in dit artikel niet omdat er een afweging moet worden gemaakt: dit artikel kan buitensporig lang worden met een buitengewone hoeveelheid details, of we kunnen doorgaan om elk aspect van deze serie stap voor stap te nemen. Ik kies ervoor om het laatste te doen, zodat we niet overweldigd worden door de hoeveelheid informatie.

Met dat gezegd, als je vragen hebt over de code, voel je vrij om hier opmerkingen over te plaatsen; ik kan echter zeggen wacht tot het volgende artikel om het antwoord te zien.

Nu, door naar de code.

Het Core Plugin-bestand

Het kernbestand van de plug-in is verantwoordelijk voor het registreren van de plug-in met WordPress en zal uiteindelijk verantwoordelijk zijn voor het importeren van de core-pluginklasse (die we in een klein beetje zullen herzien) en de plug-in daadwerkelijk in beweging zetten.

Merk op dat de voorwaarde die we hebben onderaan het bestand. Dit zorgt ervoor dat het plug-in bestand niet direct in de webbrowser kan worden geopend.
Administratieve bestanden
Al deze bestanden bevinden zich in de beheerder directory zoals hierboven vermeld.
De Admin-klasse voor metagegevens van een enkele post
Deze klasse zal het stijlblad in wachtrij plaatsen en de metabox maken die zal worden gebruikt om de gegeven berichtmeta weer te geven.
versie = $ versie;  public function enqueue_styles ()  openbare functie add_meta_box () 
In deze klasse, merk op dat het een enkel beschermd attribuut heeft voor de $ versie van de plug-in. Dit kenmerk is ingesteld in de constructor van de klasse.
We zullen zien hoe dit later in de code aansluit.
Het stylesheet met één bericht Meta Manager
Op dit moment is er geen code om voor dit specifieke bestand weer te geven; maar ga door en voeg het toe aan de admin / css subdirectory als wat we uiteindelijk zullen gebruiken om het dashboard te stylen.
Inclusief
Dit zijn core-plug-inbestanden die verantwoordelijk zijn voor het coördineren van informatie tussen de verschillende hooks en het administratieve gedeelte van de plug-in.
Single Post Meta Manager Loader
Deze klasse wordt gebruikt door de primaire pluginklasse om alle hooks te coördineren die bestaan in de plug-in en de beheerklasse die we hierboven hebben gedefinieerd.
Merk op dat we in de bovenstaande klasse de kenmerken als hebben gemarkeerd beschermde. Dit wordt gedaan zodat deze klasse toegang heeft tot zijn attributen, maar geen andere klassen doen.
Daarnaast zijn we doorgegaan en dit gedaan voor het geval dat we deze klasse onderklasse in een toekomstige iteratie van de plug-in.
Single Post Meta Manager
Ten slotte hebben we de primaire pluginklasse die verantwoordelijk is voor het laden van de afhankelijkheden, het instellen van de locale en het coördineren van de hooks.
plugin_slug = 'single-post-meta-manager-slug'; $ this-> version = '0.1.0';  private functie load_dependencies ()  persoonlijke functie define_admin_hooks ()  public function run ()  public function get_version () return $ this-> version; 
Let op in de bovenstaande code, we hebben extra beschermde attributen, een paar privaat functies, en a openbaar functie gebruikt als een getter die we zullen gebruiken terwijl we doorgaan met het uitbouwen van de plug-in.
In het volgende artikel besteden we veel tijd in deze klas, omdat dit het beginpunt is van waar veel van de functionaliteit plaatsvindt.
Komende Volgende
We hebben in dit artikel veel materiaal behandeld, maar er is natuurlijk nog veel meer te doen. Naast het leveren van documentatie voor onze functies, moeten we functionaliteit implementeren die deze steiger tot leven brengt.
In het volgende artikel in de serie gaan we precies dat doen, waarna we onze aandacht richten op het documenteren van de code.
Zoals eerder vermeld, kunt u gerust vragen en / of opmerkingen over de bovenstaande code achterlaten. Voor geïnteresseerden kun je altijd bladeren door de huidige staat van het project op GitHub.
Tot het volgende artikel!



		
			
	   
	




Code