De WordPress Plugin Boilerplate 101: aan de slag

Sinds de introductie van WordPress-plug-ins ongeveer 10 jaar geleden is er niet veel veranderd in de manier waarop we ze schrijven. Er is een hoofdplugin-bestand met een koptekst, gevolgd door het Wilde Westen. Behalve het gebruik van hooks is er geen gestandaardiseerde manier om plug-ins te maken.

Dit hoeft niet per se een probleem te zijn. Er zijn veel eenvoudige plug-ins die geen bestuurskader nodig hebben, en er zijn een aantal mensen die perfect coherente procedurele code kunnen schrijven. Dat gezegd hebbende, de kwaliteit van de code in plug-ins is over het algemeen niet de beste, een raamwerk of methodologie zou een lange weg helpen om dit te verhogen.

In dit artikel zal ik een mogelijke oplossing bekijken: WordPress Plugin Boilerplate . Het is bedoeld als een startpunt voor de ontwikkeling van plug-ins, een objectgeoriënteerde manier om een ​​gestandaardiseerde plug-in te maken. Omdat het is gecodeerd met OOP-principes, is het voornamelijk bedoeld voor intermediaire codeerders, maar je kunt het gemakkelijk gebruiken, zelfs als een beginner, als je weet wat waar naartoe gaat. Aan het einde van dit artikel zou u moeten weten wat wat is en hoe u ermee aan de slag kunt gaan, ongeacht uw codeerervaring.

Algemene bestandsstructuur

De boilerplate is bedoeld om te worden gebruikt als een Github-repository, dus de hoofddirectory bevat bestanden die vaak worden aangetroffen in Github-repos. Het README.mdbestand is een algemeen leesmij-bestand en wordt als beschrijving op uw hoofdrepositorypagina weergegeven. Het CHANGELOG.mdbestand is voor het opnemen van wijzigingen tussen de versies en het .gitignorebestand is voor het instellen van bestanden die git zou moeten negeren bij het werken met bestanden.

De hoofdmap hier plugin-nameis waar de plug-in is opgeslagen. De structuur ervan volgt de WordPress-repository en u kunt deze map “inchecken” in de SVN-plugin-repo. Standaard bevat het de assetsmap waarin afbeeldingen en schermafbeeldingen voor uw plug-in worden trunkopgeslagen, en de map die de code voor de plug-in bevat.

De trunk-map bevat de plug-in, je zou deze map in een WordPress-installatie kunnen plakken en je plug-in kunnen activeren. We zullen de inhoud van deze map later in detail bekijken. Laten we, voordat we dat doen, een winkel opzetten.

Alles instellen

Het is allemaal leuk en aardig om al deze mappen en SVN / Git geweldigheid op één plek te hebben, maar hoe kun je dit eigenlijk gebruiken? U kunt niet de hele map rechtstreeks in uw map met plug-ins controleren, het werkt gewoon niet. Alleen de trunk-directory uitchecken is een gedoe, en u hebt geen toegang tot bestanden buiten die directory.

Ik zal je mijn favoriete manier laten zien om dingen op te zetten. Ik heb een map op mijn computer met de volgende structuur:

• github
  • Topauteurs
  • Gemakkelijk uitgelichte afbeeldingen
  • Twitter-gebruiker-tijdlijnen
• html
  • wp-admin
  • wp-content
  • wp-omvat
  • andere wordpress-bestanden
• wordpress
  • topauteurs
  • eenvoudig uitgelichte afbeeldingen
  • twitter-user-tijdlijnen

De htmlmap is waar WordPress is geïnstalleerd. De githubmap bevat al mijn WordPress-plug-ins van Github. De wordpressmap bevat dezelfde plug-ins die via SVN uit de WordPress-repository zijn gehaald.

Een symlink maken

De eerste stap die ik zet, is het maken van een vanilleversie van WordPress Plugin Boilerplate op Github. Ik controleer dat vervolgens in mijn github-map. Vervolgens maak ik een symlink tussen de trunk-map binnen en de wp-content/pluginsdirectory van mijn WordPress-installatie.

Symlinks is een verwijzing naar een bestand of map die, zoals u zou verwachten, naar het doel wordt herleid. Het eindresultaat hiervan is dat als je een plug-in van overal op je systeem symlinkt naar je WordPress-directory, het prima zal werken. Dit geeft u de volgende voordelen:

• U kunt plug-ins elders opslaan.
• U kunt een map symboliseren vanuit een grotere repository.
• U kunt dezelfde plug-in symbolisch koppelen aan meerdere installaties.

Het maken van een symlink is eenvoudig vanaf de terminal of de opdrachtprompt in Windows. Ik stel voor om er een te openen en naar de map met plug-ins van je WordPress-installatie te navigeren. Typ vervolgens de volgende opdracht:

# Voor OSX of Linux
ln -s / absoluut / pad / naar / github / My-Plugin-Name / my-plugin-name / trunk my-plugin-name

# Voor ramen
mklink / j C: \ absoluut \ pad \ naar \ github \ My-Plugin-Name my-plugin-name

Dit creëert een link van het eerste pad naar het tweede. Het eerste pad is het absolute pad naar de trunk-directory in je Github-repository. De tweede is alleen de naam van de map waarnaar u deze wilt linken als u zich al in de map met plug-ins van uw WordPress-installatie bevindt.

Als je klaar bent, zou je je nieuwe plug-in moeten zien verschijnen, net als in de afbeelding hierboven. We zullen dingen moeten aanpassen, maar we hebben nu onze plug-in die draait vanuit de Github-repository, waardoor de ontwikkeling een stuk eenvoudiger wordt.

Hernoemen

Er zijn veel mappen en bestanden in de trunk-directory, laten we ze gaan hernoemen! Allereerst raad ik je aan om je repository een naam te geven met streepjes en hoofdletters, zoiets als dit: My-Awesome-Plugin. De hoofdmap binnenin zou ‘my-awesome-plugin’ moeten heten. Ik raad aan om deze conventie in de hele plug-in te gebruiken.

Het hernoemen van de bestanden is eenvoudig in OSX. Open alle mappen en selecteer alle bestanden met de string plugin-nameerin. Klik met de rechtermuisknop om alle 14 bestanden te hernoemen en de partij de naam van de partij te wijzigen.

Het zal een beetje moeilijker zijn in Windows, bekijk dit HowToGeek- artikel voor meer informatie, of ga gewoon een voor een.

Termen als “plugin-naam” en andere variaties zijn ook verspreid over de inhoud van het bestand. U kunt Sublime , Atom.io of andere capabele teksteditors gebruiken om massaal te vervangen binnen meerdere bestanden. Hier is een lijst met wat u moet vervangen (zorg ervoor dat u hoofdlettergevoelige zoek-vervangingen uitvoert).

• plugin_name zou my_awesome_plugin moeten worden
• Plugin_Name zou My_Awesome_Plugin moeten worden
• plugin-name zou mijn-awesome-plugin moeten worden

Als u klaar bent, zorg er dan voor dat u de koptekstopmerking ( my-awesome-plugin.php) van het hoofdbestand invult om het aan uw behoeften aan te passen.

Inhoudsopgave

Er zit veel in WordPress Plugin Boilerplate. Het idee is om strikte richtlijnen te stellen voor waar je dingen kunt neerzetten. Er is één specifieke plek om bijvoorbeeld je hooks toe te voegen, een standaard plek om front-end functies toe te voegen enzovoort. Laten we eens kijken naar de belangrijkste onderdelen van het raamwerk.

Merk op dat ik zal verwijzen naar de bestanden zoals ze zijn hernoemd, bijvoorbeeld: includes/class-my-awesome-plugin.php. Als je je plug-in een andere naam hebt gegeven, moet je onthouden dat het my-awesome-plugindeel van de bestandsnaam voor jou anders zal zijn.

Activering, deactivering en verwijdering

Elke code die u wilt uitvoeren wanneer de plug-in is geactiveerd, moet worden ingevoerd includes/my-awesome-plugin-name-activator.php. In dit bestand is er een klasse met de naam My_Awesome_Plugin_Activatorwaarin een activate()methode is die u zou moeten gebruiken.

Maak je geen zorgen als je niet aan de snelheid op objecten gewoon nog niet weten waar om dingen te zetten zal genoeg zijn om aan de slag te zijn.

De code die u nodig heeft om uit te voeren bij deactivering moet in includes/my-awesome-plugin-name-deactivator.php. De activate()methode binnen My_Awesome_Plugin_Deactivatoris wat u moet gebruiken.

Vind je dit een beetje te ingewikkeld? Ik kan het je niet kwalijk nemen! Wanneer u objectgeoriënteerde concepten gaat gebruiken, ziet u het voordeel hiervan ten opzichte van procedurele code. Als er niets anders is, biedt het een zeer voor de hand liggende plek om uw code te plaatsen, wat op zichzelf een enorme hulp is.

Voor het verwijderen is de aanbevolen methode om te gebruiken uninstall.phpwat WordPress Plugin Boilerplate doet. Uw code moet helemaal onderaan dat bestand worden geplaatst.

Haken toevoegen

Hooks worden verbazingwekkend afgehandeld door WordPress Plugin Boilerplate, maar het lijkt in eerste instantie misschien wat onpraktisch. Al je haken moeten erin worden geplaatst includes/class-my-awesome-plugin.php. Meer specifiek, binnen de My_Awesome_Pluginklas, binnen twee methoden:

• define_public_hooks() bij het toevoegen van een haak die aan de voorkant wordt gebruikt
• define_admin_hooks() bij het toevoegen van een haak die aan de achterkant wordt gebruikt

In plaats van add_action()of add_filter()zoals gewoonlijk te gebruiken, moet u de dingen net iets anders doen. Hier is hoe u bijvoorbeeld de inhoud van het bericht wijzigt.

$ this-> loader-> add_action ('the_content', $ plugin_public, 'adjust_post_content');

De eerste parameter is de naam van de hook, de tweede is een verwijzing naar het public of admin-object. Voor openbare hooks zou dit moeten zijn $plugin_public, voor admin hooks zou dit moeten zijn $plugin_admin. De derde parameter is de hooked-functie.

Hoewel het ingewikkelder lijkt, standaardiseert het de toevoeging van haken volledig, waardoor ze in twee verschillende groepen worden opgesplitst.

Openbare en beheerdersinhoud

WordPress Plugin Boilerplate splitst hooks in admin / publieke groepen, maar dat is niet alles. Het splitst al uw code op dezelfde manier door u te vragen om openbare code in de publicmap en admin-gerichte code in de adminmap te schrijven.

Beide mappen bevatten css, jsen partialsmappen. U moet gebruikte CSS / JS-middelen in deze mappen plaatsen en sjablonen en andere herbruikbare stukjes HTML in de map Partials schrijven. Het is prima om nieuwe bestanden in de map delen te maken, daar is het eigenlijk voor!

U moet uw gekoppelde functies ook in deze mappen schrijven, binnen de klasse in de respectieve mappen. Toen we de modify_post_contentfunctie aan the_contentbovenstaande koppelden, vertelden we WordPress Plugin Boilerplate waar we er ook naar moesten zoeken. Omdat we dit aan de openbare kant hebben toegevoegd, verwacht WordPress Plugin Boilerplate dat het wordt gedefinieerd binnen de My_Awesome_Plugin_Publicklasse die zich in de openbare map bevindt. Maak eenvoudig deze functie binnen de klas en schrijf al het andere zoals gewoonlijk.

Middelen en afhankelijkheden

Als u externe bronnen wilt gebruiken, zoals activering van TGM-plug-ins , moet u die toevoegen aan de map include. TGM is een enkel bestand met de naam class-tgm-plugin-activation.phpdat in het class-my-awesome-plugin.phpbestand moet worden opgenomen , binnen de load_dependencies()methode:

need_once plugin_dir_path (dirname (__FILE__)). 'omvat / class-tgm-plugin-activatie.php';

Overzicht

Bent u in de war door alle bestandsnamen en functies? Maak je geen zorgen, je zult het vrij snel onder de knie krijgen. In feite wijzigt u gewoonlijk slechts drie bestanden:

• includes/class-my-awesome-plugin.php is waar je al je hooks en afhankelijkheden toevoegt.
• public/class-my-awesome-plugin-public.php is waar u alle openbare functies toevoegt.
• admin/class-my-awesome-plugin-admin.php is waar alle admin-gerichte functies naartoe gaan.

In eerste instantie lijkt het gebruik van WordPress Plugin Boilerplate misschien een gedoe, maar het zal uiteindelijk zijn vruchten afwerpen. Je komt een jaar later terug en weet waar alles is, de ontwikkeling van je plug-in wordt gestandaardiseerd over alle producten heen en andere ontwikkelaars kunnen ook achterhalen wat er aan de hand is.

Vergeet ten slotte niet dat een plug-in die een eenvoudige widget levert, zo’n raamwerk misschien niet nodig heeft. Hoewel het gebruik van WordPress Plugin Boilerplate je plug-in niet vertraagt, verstopt het wel de weergave als je alleen een paar eenvoudige regels code nodig hebt!