Opbygning af dit første WordPress-plugin (del 1)
En af de primære årsager til WordPress 'fortsatte popularitet er den lethed, som den kan udvides og tilpasses med plugins.
Opbygning af et plugin kan virke som en umulig opgave, men det er enklere, end du måske tror. I dag begynder vi vores "Building your first WordPress plugin" serie, der dækker de vigtigste principper og how-tos af processen.
Ved udgangen af serien er du fuldt ud parat til at lave yderligere eksperimenter af dig selv, der baserer dig på bedste praksis og konventioner, der er vedtaget af det omfattende WordPress-fællesskab.
Hvad er et WordPress-plugin?
Det er et PHP-script, der ændrer eller udvider den indfødte funktionalitet i WordPress.
Ved at give en meget enkel men fleksibel Plugin API , WordPress forsyner hver udvikler med følgende fordele for plugin brug:
- Du behøver ikke at ændre kernefiler for at få yderligere eller alternativ funktionalitet. Det betyder, at plugin-funktionaliteten kan bevares gennem kerneopdateringer
- WordPress har en indbygget mekanisme for plugin deaktivering, når en fatalt fejl potentielt kan bryde et websted
- Modulariteten af kode for et bestemt projekt øges; opdateringer og vedligeholdelse bliver lettere
- Plugin funktionalitet er adskilt fra temaer
- Det samme plugin kan bruges med forskellige temaer og har nogle design-uafhængige funktionaliteter
- Udvidet kodebase
- Som et PHP-script kan et plugin implementere moderne programmeringsteknikker, f.eks. OOP, men samtidig har den evnen til at bruge native WordPress-funktioner, klasser og API'er.
Uanset din PHP kodning oplevelse - din virkelig skrev sin første plugin lige efter afslutningen af en "PHP for Dummies" bog - du er et lille skridt væk fra oprettelsen af dit første plugin til WordPress. Lad os tage det skridt sammen.
Den primære opgave, som vi skal udforske i dag, er at opbygge et solidt plugin-fundament. Dette fundament skal opfylde WordPress krav og gøre plugin genkendeligt af kernen. Samtidig bør det følge almindelige fremgangsmåder og konventioner, der accepteres af fællesskabet, for at undgå mulige konflikter med andre plugins, der kan installeres på et websted.
Plugin navn og filer
Først og fremmest skal du sikre dig, at dit plugins navn er unikt. Selvom du ikke vil gøre dit arbejde til en offentlig udgave, skal du i det mindste være sikker på, at der ikke er nogen mulighed for dit eget websted ved hjælp af to plugins med samme navn. Den simple plugins repository (og Google) søgning er din ven, når du undgår det forkerte valg.
For at øge sandsynligheden for, at et navn er unikt, skaber mange udviklere mærkepræfikset, hvilket er en forkortelse for udviklerens navn (eller kaldenavn). Dette præfiks med kort henvisning til pluginens navn skal efterfølgende bruges overalt - i navne på filer, funktioner, klasser, variabler etc. Det hjælper med at undgå navngivning af konflikter med andre plugins, temaer og selve kernen.
Lad os starte med et eksempel. Vi vedtager navnet "Hello World Plugin" og for at øge chancerne for at være unik bruger vi "My super prefix" konverteret til forkortelse "MSP". Hvilket giver os det helt unikke navn "MSP Hello World Plugin"; søgning gennem plugins repository bekræfter, at ingen andre bruger det.
Vores næste skridt er at oprette plugins filer. Det anbefales stærkt, at du gemmer dem i en separat mappe inde i en dedikeret plugin-mappe. Denne mappe skal navngives i overensstemmelse med selve plugin, i vores tilfælde kan det være 'msp-helloworld'. Mappen skal indeholde hoved pluginfilen med samme navn: 'msp-helloworld.php'.
Det WordPress Codex anbefaler også at du inkluderer en readme.txt fil. Denne fil indeholder oplysninger om dit plugin et standardiseret format . Hvis du skal indsende dit plugin til WordPress-depotet, er eksistensen af readme.txt obligatorisk. Men tænk ikke på det som en byrde, der er mange fordele ved at gøre dette.
Hvis dit plugin skal have flere filer eller indlæse nogle aktiver (billeder, css og js-filer), skal de organiseres i undermapper. Korrekt fil organisation er et tegn på professionelt arbejde. Du kan stole på følgende mønster:
Plugin header
Ethvert plugin skal have det obligatoriske header . Det hjælper WordPress genkender scriptet som et gyldigt plugin og udsender ordentlig information på plugins ledelsesskærm.
Denne overskrift er en PHP-kommentarblok placeret øverst i hovedprogrammets fil:
/*Plugin Name: MSP Hello WorldDescription: Create hello world messageVersion: 1.0Author: Author's nameAuthor URI: http://authorsite.com/Plugin URI: http://authorsite.com/msp-helloworld*/Hovedtekstens information vil blive præsenteret i den tilsvarende plugin-række på ledelsesskærmen.
Ordens rækkefølge er ikke vigtig, men filen skal være i UTF-8-kodning.
Bemærk, at det er vigtigt at være i overensstemmelse med det versionsnummermønster, du har valgt (f.eks. Xxxx), til WordPress-opgraderingsmekanismen til at registrere det korrekt.
Stier til filer
Indtil videre har vi oprettet forskellige filer til vores plugin (i rigtige undermapper), vi skal nu bestemme de korrekte stier (eller webadresser) til dem inde i plugin-koden. Under hensyntagen til det faktum, at wp-indholdsmappen kunne flyttes fra dens standardplacering, bliver det klart, at stier til plugin-filer ikke skal være hardkodede, men derimod skal detekteres.
WordPress har to funktioner, plugin_dir_path og plugin_dir_url for at løse problemet, men vi kan gå videre ved at bruge følgende trick:
define('MSP_HELLOWORLD_DIR', plugin_dir_path(__FILE__));define('MSP_HELLOWORLD_URL', plugin_dir_url(__FILE__)); Med denne lille uddrag (inkluderet i hoved plugin-filen) registrerer vi stien og webadressen til vores plugin-mappe inde i WordPress-installationen og tildeler dem passende konstanter. Derefter kan vi bruge disse konstanter i kombination med kendte relative stier til undermapper, for eksempel MSP_HELLOWORLD_DIR.'assets/img/image.jpg' .
Ved hjælp af disse konstanter kan vi også nemt inkludere pluginfiler fra undermapper i hovedfilen:
function msp_helloworld_load(){if(is_admin()) //load admin files only in adminrequire_once(MSP_HELLOWORLD_DIR.'includes/admin.php');require_once(MSP_HELLOWORLD_DIR.'includes/core.php');}msp_helloworld_load();Plugin states
Efter installationen kunne vores plugin være i en aktiv eller inaktiv tilstand.
Aktiv tilstand betyder, at den blev aktiveret af brugeren, og dens kode vil blive udført af WordPress hver gang en side bliver anmodet om.
Plugin kan også deaktiveres af brugeren, hvilket betyder, at filer opbevares på deres steder, men koden udføres ikke.
(Plugin kan også blive fuldstændig afinstalleret af en bruger, hvilket betyder, at filerne slettes fra plugin-mappen.)
WordPress kan fange ændringer i disse stater og udføre nogle kode planlagt for sådanne ændringer. Hvis en kode er planlagt til aktivering eller deaktivering, vil den kun blive udført på dette tidspunkt og ikke på hver side.
For eksempel, hvis pluginet skal manipulere med omskrivningsregler, bør det rydde dem ved aktivering / deaktivering. Hvis plugin'en skaber nogle poster i en database, f.eks. Ved at gemme indstillinger, er den sunde praksis at slette dem, når plugin er afinstalleret.
Hvordan kan det gøres?
Til aktivering og deaktivering kan vi registrere en såkaldt 'aktiveringskrog' og 'deaktiveringskrog'. De er bare et stykke kode, der fortæller WordPress at udføre en bestemt funktion ved aktivering og en anden bestemt funktion ved deaktivering. Her er et eksempel på en sådan kode:
register_activation_hook(__FILE__, 'msp_helloworld_activation');register_deactivation_hook(__FILE__, 'msp_helloworld_deactivation');function msp_helloworld_activation() {//actions to perform once on plugin activation go here}function msp_helloworld_deactivation() {// actions to perform once on plugin deactivation go here}For afinstallationshandlinger har vi to alternativer.
En mulighed er at oprette en uninstall.php-fil i plugin'ens mappe (sammen med main plugin-filen og readme.txt) og inkludere alle nødvendige kode der. Hvis der findes en uninstall.php, udfører WordPress det automatisk, når pluginet slettes af brugeren. Alternativt kan vi registrere en afinstallationskrog på næsten samme måde som vi gjorde med aktiverings- og deaktiveringskroge. Den vanskelige del er at kalde det kun én gang ved aktivering. Her er et eksempel:
register_activation_hook(__FILE__, 'msp_helloworld_activation');function msp_helloworld_activation() {//actions to perform once on plugin activation go here//register uninstallerregister_uninstall_hook(__FILE__, 'msp_helloworld_uninstall');}function msp_helloworld_uninstall(){//actions to perform once on plugin uninstall go here}Det er vigtigt at vide, at kun et af de beskrevne alternativer vil fungere: Hvis uninstall.php eksisterer, vil det blive udført, og enhver afinstallationshook vil ikke blive fyret.
Bedste praksis
Sammenfattende alt ovenfor, her er et overblik over at skabe et solidt fundament for et WordPress-plugin:
- Find et unikt navn
- Opsæt et præfiks (relateret til dit mærke)
- Opret plugins mappe
- Opret undermapper til PHP-filer, aktiver og oversættelser
- Opret hoved pluginfilen og udfyld obligatoriske headeroplysninger
- Opret en readme.txt fil
- Brug korrekte konstanter og funktioner til at registrere stier til plugin-filer
- Opret yderligere PHP-filer og inkludere dem inde i den vigtigste
- Opret aktiverings- og deaktiveringsfunktioner
- Opret et afinstaller script
Konklusion
Efter alle disse trin er du klar til faktisk at lave dit plugin for at gøre noget ved at oprette sin kode. Vi får kendskab til nogle nyttige koncepter, der gør WordPress-plugins spændende og fleksible i den næste artikel i denne serie. Men nogle vigtige aspekter kan fremhæves lige nu:
- Udvikle aldrig uden fejlfinding. Der er masser af oplysninger om WordPress debugging mode og forskellige plugins for at få ekstra anmeldelser. De er dine pålidelige assistenter på vej til fejlfri og opdateret kode.
- Prefix alt. Brug et unikt præfiks (normalt pluginets navnderivat) for alle dine funktioner, variabler, klasser mv. For at sikre, at dit plugin er interoperabelt med andre udviklers arbejde.
- Følge efter WordPress kodningsstandarder . Disse standarder er et sæt regler implementeret af kerneteamet for alle WordPress-kodeer, der gør det nemt at læse og vedligeholde. Følgende standarder hjælper med at opretholde konsistensen af kernekoden inden for dit plugin.
- Brug kernefunktioner, API'er og klasser til almindelige opgaver. WordPress giver udviklere en bred vifte af værktøjer til almindeligt nødvendige operationer (f.eks. Database interaktion eller brugergodkendelse), så du kan koncentrere dig om den helt unikke funktionalitet i dit plugin.
- Dokumentér din kode. Faktisk er der ikke meget at sige om dette princip - uanset de anvendte konventioner, både dig som udvikler og vi som samfund drage fordel af veldokumenteret kode.
Jeg håber, at denne indledende information inspirerer dig til at begynde at udvikle med WordPress. Hold øje med den næste del af serien i den nærmeste fremtid.
Hvilke tip vil du tilføje til denne introduktion? Hvad vil du se dækket i næste artikel i serien? Lad os vide i kommentarerne!