Share
Als het gaat om het schrijven van WordPress-plug-ins, zijn er over het algemeen twee manieren om dit te doen: objectgeoriënteerde programmering en functionele programmering (waarbij widgets de uitzondering vormen - we zullen dat later in het artikel bespreken).
Hoewel je over het algemeen mensen hebt die instemmen met de ene programmeerstijl boven de andere, stelt elk zijn eigen set van voor- en nadelen voor.
In deze tweedelige serie gaan Stephen Harris en ik de twee manieren uiteen die je kunt doen om WordPress-plug-ins te schrijven. Ik ga het in het bijzonder hebben over objectgeoriënteerd programmeren en hij zal functionele programmering behandelen.
Omdat het ervaringsniveau van lezers varieert, gaan we het hebben over programmeren op een hoog niveau, dus als je een beginner bent, zou je geen probleem moeten hebben om mee te werken. Als u echter een meer ervaren ontwikkelaar bent, vindt u mogelijk later meer nuttige informatie in het artikel.
Met dat gezegd, laten we beginnen met het kijken naar een object-georiënteerde benadering van het ontwikkelen van WordPress-plug-ins.
Zoals vermeld in de inleiding, kunnen plug-ins op twee manieren voor WordPress worden ontwikkeld:
Het tweede artikel in de serie gaat over Functional Programming, maar laten we een werkdefinitie van objectgeoriënteerd programmeren bieden, zodat we allemaal op hetzelfde niveau zitten in dit artikel.
Wikipedia verklaart:
Object-oriented programming (OOP) is een programmeerparadigma dat "objecten" gebruikt - meestal voorbeelden van een klasse - bestaande uit gegevensvelden en methoden, samen met hun interacties - om applicaties en computerprogramma's te ontwerpen.
Degenen die meer ervaring hebben met computerprogrammering, vooral degenen die object-georiënteerde programmeertechnieken gebruiken, zullen die definitie waarschijnlijk leuk vinden.
Maar laten we het vereenvoudigen voor de doeleinden van dit artikel:
Objectgeoriënteerd programmeren is een programmeertechniek die een verzameling verwante methoden gebruikt om een computerprogramma of een deel van een computerprogramma te definiëren.
Eenvoudig genoeg, toch? In ons geval zijn onze plug-ins beslist een deel van een computerprogramma omdat ze aansluiten op WordPress.
Hoewel we in de rest van dit artikel naar code zullen kijken, merk je op dat objectgerichte programma's worden geïdentificeerd door de groepering van hun gerelateerde methoden en dat wordt gedaan in de context van wat een klasse wordt genoemd - die we binnenkort behandelen.
Hoewel het klopt dat WordPress-plug-ins kunnen worden ontwikkeld met behulp van OOP of functionele programmering, is er een uitzondering als het gaat om het ontwikkelen van widgets.
Volgens het Codex-artikel over het ontwikkelen van widgets, moet de volgende structuur worden gebruikt voor het schrijven van een widget:
class My_Widget breidt WP_Widget uit public function __construct () // feitelijke widgetprocessen public function form ($ instance) // geeft het optieformulier weer bij admin public function update ($ new_instance, $ old_instance) // verwerkt widgetopties wordt opgeslagen openbare functie widget ($ args, $ instantie) // geeft de inhoud van de widget uit
Dit betekent dat allemaal Widgets moeten worden geschreven met behulp van OOP. Als je code niet hebt gezien zoals hierboven, zullen we dat in het volgende gedeelte behandelen en het moet alles bieden wat je moet weten om te begrijpen wat er aan de hand is.
Voordat we beginnen met het bouwen van OOP-gebaseerde plug-ins voor WordPress, laten we de basisprincipes van OOP eens nader bekijken om ervoor te zorgen dat we duidelijk zijn over terminologie en hoe het paradigma werkt.
Zoals we eerder hebben gedefinieerd, gebruikt OOP 'een verzameling verwante methoden'. Maar we kunnen daar niet stoppen. Functioneel programmeren doet immers hetzelfde.
In OOP zijn deze "gerelateerde methoden" allemaal gerelateerd in de context van wat a wordt genoemd klasse. In het voorbeeld Widget hierboven ziet u de klasse sleutelwoord als het allereerste woord in de code.
Het begint op een regel die eindigt met een openingshaak (net als bij functies), en vervolgens worden alle bijbehorende functies ingekapseld - of verpakt - voordat de afsluiting wordt beëindigd (negeer nu de strekt sleutelwoord in het Widget-voorbeeld - we zullen dat in een ogenblik aansnijden).
Als je net bent begonnen met het schrijven van lessen en je je afvraagt of een functie in een bepaalde klas thuishoort, stel jezelf dan de vraag of de functie klinkt als iets dat een bepaalde klas zou doen.
Bijvoorbeeld in het Widget-voorbeeld hierboven, de bijwerken methode is natuurlijk iets dat een widget zou doen. Maar laten we zeggen dat je een klas schrijft die verantwoordelijk zal zijn voor het lezen van een blogpost in de WordPress-database. Het zou logisch zijn als die specifieke klasse een functie zou hebben lezen of read_by_id, maar moet het een functie hebben genaamd schrijven? Hoe zit het met verwijderen?
Afhankelijk van hoe je je klas hebt ontworpen, mogelijk. Maar als het zool doel van de klas is om gegevens te lezen, waarschijnlijk niet.
En dat is OOP: het is logisch dat je je functies in een klas samenvoegt, maar de logische groepering hangt af van de verantwoordelijkheid die je aan je klas geeft.
OOP is een krachtig paradigma dat overal in de WordPress-applicatie wordt gebruikt. OOP maakt geavanceerde bewerkingen mogelijk, zoals overerving (die wordt gerepresenteerd door de strekt sleutelwoord in de Widget-klasse), ontwerppatronen die in wezen bestaande oplossingen voor veel voorkomende problemen zijn.
Dit artikel probeert niet om een diepe duik te nemen in objectgeoriënteerd programmeren. Het probeert eenvoudigweg een basis te bieden van waaruit we de twee manieren om WordPress-plug-ins te schrijven kunnen verkennen, maar ik noem ze hier als je geïnteresseerd bent om verder te duiken in objectgeoriënteerd programmeren.
Nu we objectgeoriënteerd programmeren hebben gedefinieerd en net genoeg hebben onderzocht om een basis te leggen, is het tijd om daadwerkelijk te beginnen praten over de componenten van OOP-gebaseerde ontwikkeling in de context van WordPress-plug-ins.
In de rest van dit artikel gaan we in op de basis van wat er nodig is voor het schrijven van op OOP gebaseerde plug-ins en de voordelen die dit oplevert.
Voordat je het doet iets in object-georiënteerde ontwikkeling, moet je je klasse definiëren. Ervan uitgaande dat je al een idee hebt over wat je klas gaat doen, is dit over het algemeen een kwestie van bedenken wat je jouw klas wilt noemen.
Voor het grootste deel denk ik dat het bekijken van voorbeeldcode altijd van voordeel is bij het onderwijzen van code, dus we zullen een kijkje nemen op de WordPress Plugin Boilerplate.
Merk op dat de Plugin Boilerplate een project is dat ik oorspronkelijk heb gemaakt om op OOP-gebaseerde plug-ins te helpen starten. Het is sindsdien bijgedragen door een aantal verschillende mensen. Ik gebruik het in dit artikel omdat het het onderwerp laat zien.
Dat gezegd hebbende, merk op dat de klassendefinitie voor de Plugin Boilerplate er als volgt uitziet:
class PluginName // More to come ...
Omdat de Plugin Boilerplate een startpunt is voor ontwikkeling, hebben we de klasse uiteraard hernoemd. Laten we het voor dit artikel noemen DemoPlugin.
class DemoPlugin // More to come ...
Op dit punt zijn we klaar om te beginnen met het definiëren van functies die binnen de klas leven.
In OOP is de eerste functie die je waarschijnlijk in een klas ziet, een functie die 'de constructor' wordt genoemd en PHP is niet anders.
Een eenvoudige, werkende definitie van de constructeur is deze:
De constructor is waar u de gegevens initialiseert die in de klas zullen worden gebruikt.
Hoe dit werkt, verschilt van project tot project, maar er zijn twee belangrijke dingen die we kunnen doen in de context van een WordPress-plug-in:
In onze DemoPlugin, we gaan precies dat doen. We zullen een tekstdomein instellen van demo-plugin en we registreren acties voor het registreren en in de wacht zetten van een voorbeeld van een stylesheet en een voorbeeld van een JavaScript-bestand.
Om compleet te zijn in ons voorbeeld, registreren we ook een haak om tekst toe te voegen aan het einde van de inhoud die in een bericht wordt weergegeven.
Laten we eerst de constructor definiëren:
class DemoPlugin public function __construct ()
Merk op dat in PHP een constructor wordt gedefinieerd door een publieke functie met de naam construeren dat is voorafgegaan door twee onderstrepingstekens.
Laten we vervolgens ons tekstdomein definiëren:
Accentsconagua
class DemoPlugin public function __construct () load_plugin_textdomain ('demo-plugin', false, dirname (plugin_basename (__FILE__)). '/ lang'); In de bovenstaande coderegel noteren we dat we de sleutel hebben gedefinieerd voor ons tekstdomein demo-plugin en de lijn verwacht de lokaliseringsbestanden te vinden in een submap genaamd LANG in de map van de plug-in.
Omdat localisatie buiten het toepassingsgebied van dit artikel valt, zal ik niet verder duiken, maar u kunt de broncode van de Plugin-boilerschotel bekijken om te zien hoe dit is ingesteld.
Stel vervolgens de acties voor het registreren van onze stylesheets en JavaScript in, evenals de filter die tekst toevoegt aan het einde van onze inhoud:
class DemoPlugin public function __construct () load_plugin_textdomain ('demo-plugin', false, dirname (plugin_basename (__FILE__)). '/ lang'); add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_styles')); add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_scripts')); add_filter ('the_content', array ($ this, 'append_post_notification')); Als je niet bekend bent met acties en filters, lees dan zeker een van mijn recente artikelen hier over Wptuts + omdat het verschil verklaart.
Als u bekend bent met het ontwikkelen van WordPress-thema's of functionele programmering, dan bent u waarschijnlijk gewend om iets als het volgende te zien:
add_action ('wp_enqueue_scripts', 'register_plugin_styles'); Liever dan:
add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_styles')); Merk op dat het verschil in de twee bovenstaande aanroepen zit in de tweede parameter. In het bijzonder geven we in onze plug-in een array door, terwijl de eerste regel code gewoon een string doorgeeft.
Omdat we deze plug-in ontwikkelen met behulp van OOP, moet WordPress weten waar het moet worden genoemd register_plugin_styles methode. Omdat het in onze klas leeft, moeten we WordPress vertellen om de methode te gebruiken voor een exemplaar van onze klas.
Logisch?
In essentie vertellen we WordPress: ik heb deze methode genaamd register_plugin_styles, maar je moet het op een instantie van deze klasse noemen (vandaar de deze trefwoord).
Als WordPress nieuw voor u is, maar afkomstig is van een programmeerachtergrond, dan kunt u zich voorstellen dat u WordPress vertelt om dit te doen:
$ demo = nieuwe DemoPlugin (); $ Demo-> register_plugin_styles ();
Hoe dan ook, de bottom line is dat als je je plug-ins aan het ontwikkelen bent met OOP, dan jij moet registreer uw hooks met behulp van een array met twee indexen: de eerste is $ this en de tweede is de naam van de functie.
Geavanceerde ontwikkelaars zullen bekend zijn met het vermogen van PHP om te refereren aan referenties en pass-by-value. In WordPress Development is het niet ongewoon om het volgende te zien:
add_action ('wp_enqueue_scripts', array (& $ this, 'register_plugin_styles')); Waar deze wordt doorgegeven door verwijzing; Vanaf PHP 5.4 is de mogelijkheid om variabelen door te geven tijdens het gesprek, echter verwijderd. Dat is de reden waarom deze zelfstudie ervoor kiest om door te gaan met waarde.
Bij het programmeren zijn functies de code-eenheden die in wezen verantwoordelijk zijn voor 'iets doen'. Bij objectgeoriënteerd programmeren is het handig om ze iets anders te zien.
In OOP worden klassen meestal vertegenwoordigd door zelfstandige naamwoorden. In ons geval hebben we een DemoPlugin. Evenzo zijn functies vaak werkwoorden. Dat wil zeggen, het zijn acties die ons zelfstandig naamwoord kan nemen. Op dit punt hebben we er al voor gekozen om de volgende functies te definiëren:
register_plugin_stylesregister_plugin_scriptsappend_post_notificationMerk op hoe elke functienaam staat voor een actie die kan worden ondernomen. Dit is een goede vuistregel om te gebruiken bij het schrijven van functies.
Bij functioneel programmeren is er eigenlijk alleen maar het idee van functies; In OOP zijn er echter verschillende soorten functies, waarvan er twee "openbare" functies en "privé" -functies zijn.
Openbare functies zijn functies die buiten de klas toegankelijk zijn. Dit betekent dat je deze methoden kunt aanroepen zodra je de les hebt geïnstantieerd.
Dit is precies wat we eerder in de volgende code hebben gedaan:
$ demo = nieuwe DemoPlugin (); $ Demo-> register_plugin_styles ();
In principe zijn deze functies toegankelijk voor het publiek (waarbij het publiek een programmeur of een ander object kan zijn).
De functies die we schrijven voor het registreren van onze stylesheets, ons JavaScript en dat we schrijven om tekst aan een bericht toe te voegen hebben om als openbaar gemarkeerd te worden omdat daar zullen een derde partij zijn die hen belt - WordPress.
Laten we de twee functies definiëren voor de wp_enqueue_scripts actie:
public function register_plugin_styles () wp_register_style ('demo-plugin', plugins_url ('demo-plugin / css / plugin')); wp_enqueue_style ('demo-plugin'); public function register_plugin_scripts () wp_register_script ('demo-plugin', plugins_url ('demo-plugin / js / display.js')); wp_enqueue_script ('demo-plugin'); Merk nogmaals op dat deze twee functies verwachten dat de stylesheets en JavaScript aanwezig zijn css en js submappen. Om dit in actie te zien, vergeet niet om de plug-in ketelplaat te bekijken.
Laten we tot slot de functie definiëren voor de inhoud filter:
openbare functie append_post_notification ($ content) $ notification = __ ('Dit bericht is toegevoegd met een demoplugin.', 'demo-plugin-locale'); return $ inhoud. kennisgeving $; Merk op dat we de __-functie gebruiken om ervoor te zorgen dat ons script gelokaliseerd is met de TEKSTDOMEIN die we in de constructor hebben gedefinieerd.
Als openbare methoden voor iedereen toegankelijk zijn, betekent dit dat privé-functies voor niemand toegankelijk zijn, toch? Grotendeels, dat klopt: de enige persoon - of ding - die private methoden kunnen aanroepen, zijn de klassen waarin ze zijn gedefinieerd.
Dat betekent dat WordPress, externe objecten of programmeurs privé-functies programmatisch kunnen aanroepen. Privé-functies kunnen alleen worden aangeroepen vanuit de klas waarin ze worden gebruikt.
Over het algemeen zijn privé-functies erg handig bij het schrijven van helper-methoden - dat wil zeggen, ze zijn handig voor het intern manipuleren van gegevens om een andere functie te helpen bij het uitvoeren van zijn taak.
Om een werkend voorbeeld te geven, laten we een private functie definiëren die een gelokaliseerde string retourneert die onze append_post_notification functie kan gebruiken:
private function get_localized_notification () return __ ('Dit bericht is toegevoegd met een demoplugin.', 'demo-plugin-locale'); Laten we vervolgens de append_post_notification functie om deze nieuwe helper te noemen:
openbare functie append_post_notification ($ content) return $ content. $ This-> get_localized_notification ();
Merk op dat we de eerste functie hebben vereenvoudigd door een tweede functie toe te voegen. Je zou ook kunnen beweren dat we de leesbaarheid van de initiële functie hebben verhoogd door een oproep toe te voegen aan een functie met een naam die verduidelijkt wat er gebeurt.
Misschien is het belangrijkste om op te merken dat om privé-functies te bellen, u de functieaanroep moet voorafgaan met de $ this trefwoord en de ->. Dit zegt PHP: "Noem de get_localized_notification functie die leeft deze klasse."
In ieder geval hebben we elke methode een enkele verantwoordelijkheid gegeven - een andere goede praktijk in objectgeoriënteerd programmeren - en hebben we het gebruik van zowel openbare als privé-functies aangetoond..
Bij objectgeoriënteerd programmeren zijn er ook andere soorten functies die buiten het bestek van dit artikel vallen.
Om compleet te zijn, wilde ik ze hier samenvatten:
DemoPlugin :: use_this_static_method (). Op dit punt hebben we alle hoge tonen voor objectgeoriënteerde WordPress-ontwikkeling bereikt. Om de voordelen samen te vatten:
Wanneer u objectgeoriënteerd programmeren gebruikt, hoeft u geen voorvoegsel te gebruiken voor een functie met de naam van het thema of de naam van de plug-in waaraan u werkt, en hoeft u zich ook geen zorgen te maken over het benoemen van een functie die kan interfereren met een WordPress-functie, de functie van een ander thema of de functie van een andere plug-in.
In plaats daarvan leven alle functies binnen de context van een andere klasse. Het enige waar je zeker van moet zijn, is dat je klasse niet iets genoemd wordt dat interfereert met een andere bestaande klasse.
Door objectgeoriënteerd programmeren te gebruiken, kunt u programmatisch een beroep doen op uw plug-in van buiten de standaard WordPress API.
Laten we zeggen dat u een thema aan het ontwikkelen bent en dat u iets wilt weergeven in de zijbalk die uw plug-in biedt. In de sidebar-sjabloon kunt u uw plug-in instantiëren en vervolgens methoden erop aanroepen om informatie in de zijbalk te laten schrijven.
Dit is met name handig wanneer u aan een sjabloon werkt en een aantal standaardgegevens wilt opgeven als de gebruiker niet handmatig iets invoert.
Zoals we aan het begin van het artikel zeiden: dit is maar een manier waarop je je WordPress-plug-ins kunt ontwikkelen. In het artikel van Stephen wordt beschreven hoe je dit kunt doen met behulp van functioneel programmeren.
Na het lezen van dit artikel zou je een beter begrip moeten hebben van object-georiënteerd programmeren, de voordelen ervan, en zou je in staat moeten zijn om te volgen met code gedocumenteerd in de Widget API, in mijn gerelateerde Widget Boilerplate, en zelfs door plaatsen in de WordPress codebase.
