Bygg din första WordPress-plugin (del 1)
En av de främsta orsakerna till WordPress fortsatta popularitet är den lätthet som den kan förlängas och anpassas med plugins.
Att bygga ett plugin kan verka som en omöjlig uppgift, men det är enklare än du kanske tror. Idag börjar vi vår "Bygga din första WordPress plugin" -serie som täcker de viktigaste principerna och how-tosna i processen.
I slutet av serien kommer du att vara helt beredd att göra egna egna experiment, förlita sig på bästa praxis och konventioner som antagits av det omfattande WordPress-samhället.
Vad är ett WordPress-plugin?
Det är ett PHP-skript som ändrar eller utökar den inbyggda funktionaliteten i WordPress.
Genom att ge en mycket enkel men flexibel Plugin API , WordPress förser alla utvecklare med följande fördelar för plugin användning:
- Inget behov av att ändra kärnfiler för att få ytterligare eller alternativ funktionalitet. Det betyder att pluginfunktionen kan bevaras genom kärnuppdateringar
- WordPress har en inbyggd mekanism för instängning av plugin när ett dödligt fel skulle kunna bryta en webbplats
- Modulariteten av kod för ett visst projekt ökar; uppdateringar och underhåll blir enklare
- Plugins funktionalitet är åtskild från teman
- Samma plugin kan användas med olika teman och har viss designoberoende funktionalitet
- Utökad kodbas
- Som ett PHP-skript kan ett plugin implementera moderna programmeringstekniker, till exempel OOP, men samtidigt har den förmågan att använda inbyggda WordPress-funktioner, klasser och API.
Oavsett din PHP-kodningsupplevelse - din skrivte verkligen hennes första plugin efter att ha slutfört en "PHP for Dummies" -bok - du är ett litet steg bort från att du skapade din första plugin för WordPress. Låt oss ta det steget ihop.
Den primära uppgiften som vi ska utforska idag är att bygga en solid plugin-grund. Denna grund måste uppfylla WordPress-krav och göra pluggen igenkännbar av kärnan. Samtidigt bör det följa gemensamma metoder och konventioner, accepterade av samhället, för att undvika eventuella konflikter med andra plugins som kan installeras på en webbplats.
Plugin namn och filer
Först och främst måste du se till att ditt plugin namn är unikt. Även om du inte kommer att göra ditt arbete offentligt, måste du åtminstone vara säker på att det inte finns någon möjlighet att din egen webbplats använder två plugins med samma namn. Den enkla plugins-arkivet (och Google) -sökning är din vän när du undviker fel val.
För att öka sannolikheten för att ett namn är unikt skapar många utvecklare varumärkesprefixet, vilket är en förkortning för utvecklarens namn (eller smeknamn). Detta prefix med kort referens till pluginnamnet ska därefter användas överallt - i namn på filer, funktioner, klasser, variabler etc. Det hjälper till att undvika att namnger konflikter med andra plugins, teman och själva kärnan.
Låt oss börja med ett exempel. Vi adopterar namnet "Hello World Plugin" och för att öka chansen att vara unik använder vi "My super prefix" omvandlas till förkortning "MSP". Vilket ger oss det verkligt unika namnet "MSP Hello World Plugin"; Genom att söka igenom pluginförvaret bekräftas att ingen annan använder det.
Vårt nästa steg är att skapa plugins filer. Det rekommenderas starkt att du lagrar dem i en separat mapp i en dedikerad plugin-mapp. Den här mappen ska namnges enligt plugin själv, i vårt fall kan det vara "msp-helloworld". Mappen ska innehålla huvud pluginfilen med samma namn: 'msp-helloworld.php'.
De WordPress Codex rekommenderar också att du inkluderar en readme.txt-fil. Den här filen innehåller information om ditt plugin i ett standardiserat format . Om du ska skicka in din plugin till WordPress-förvaret är förekomsten av readme.txt obligatorisk. Men tänk inte på det som en börda, det finns många fördelar med att göra detta.
Om ditt plugin ska ha flera filer eller ladda vissa tillgångar (bilder, css och js-filer), ska de ordnas i undermappar. Korrekt filorganisation är ett tecken på professionellt arbete. Du kan lita på följande mönster:
Plugin header
Varje plugin ska ha den obligatoriska rubrik . Det hjälper WordPress att känna igen manuset som ett giltigt plugin och utföra korrekt information på plugins managementschema.
Den här rubriken är ett PHP-kommentarsblock som ligger högst upp i huvudprogrammets 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*/Rubrikens information kommer att presenteras i motsvarande plugin rad på hanteringsskärmen.
Ordningen på linjerna är inte viktig, men filen måste vara i UTF-8-kodning.
Observera att det är viktigt att vara överensstämmande med versionsnumreringsmönstret du har valt (t.ex.xxx), för att uppgraderingsmekanismen för WordPress ska kunna identifiera den korrekt.
Vägar till filer
Hittills har vi skapat olika filer för vårt plugin (i riktiga undermappar), vi behöver nu bestämma korrekta sökvägar (eller webbadresser) till dem i plugin-koden. Med tanke på det faktum att mappen WP-innehåll kan flyttas från dess standardplats, blir det klart att vägar till pluginfiler inte ska vara hårdkodade utan snarare bör detekteras.
WordPress har två funktioner, plugin_dir_path och plugin_dir_url för att lösa problemet, men vi kan gå vidare med hjälp av följande knep:
define('MSP_HELLOWORLD_DIR', plugin_dir_path(__FILE__));define('MSP_HELLOWORLD_URL', plugin_dir_url(__FILE__)); Med det här lilla fragmentet (ingår i huvud plugin-filen) identifierar vi sökvägen och URL-adressen till vår plugins mapp i WordPress-installationen och tilldelar dem till lämpliga konstanter. Därefter kan vi använda dessa konstanter i kombination med kända relativa vägar till undermappar, till exempel MSP_HELLOWORLD_DIR.'assets/img/image.jpg' .
Med hjälp av dessa konstanter kan vi också enkelt inkludera pluginfiler från undermappar i huvudfilen:
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 kan vårt plugin vara i aktivt eller inaktivt tillstånd.
Aktivt tillstånd betyder att det aktiverades av användaren och dess kod kommer att utföras av WordPress varje gång en sida begärs.
Plugin kan också avaktiveras av användaren vilket betyder att filer hålls på sina platser, men koden utförs inte.
(Plugin kan också vara helt avinstallerad av en användare, vilket betyder att filerna raderas från plugin-mappen.)
WordPress kan fånga ändringar i dessa stater och genomföra en kod som är planerad för sådana ändringar. Om någon kod är planerad för aktivering eller avaktivering, kommer den att utföras endast vid det här tillfället, inte på varje sida.
Om till exempel pluginet ska manipulera med omskrivningsregler bör det rensas om aktivering / avaktivering. Om plugin skapar några poster i en databas, till exempel genom att lagra alternativ, är den sunda rutinen att ta bort dem när plugin avinstalleras.
Hur kan det bli gjort?
För aktiverings- och avaktiveringsåtgärder kan vi registrera en så kallad "aktiveringskrok" och "inaktiveringskrok". De är bara ett stycke kod som säger att WordPress ska utföra en viss funktion vid aktivering och en annan speciell funktion vid avaktivering. Här är ett exempel på en sådan kod:
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}För avinstallationsåtgärder har vi två alternativ.
Ett alternativ är att skapa en uninstall.php-fil i plugin-mappen (tillsammans med huvud plugin-filen och readme.txt) och inkludera all nödvändig kod där. Om en uninstall.php existerar, kommer WordPress att exekvera det automatiskt när plugin raderas av användaren. Alternativt kan vi registrera en avinstallationshake på nästan samma sätt som vi gjorde med aktiverings- och avaktiveringshakarna. Den knepiga delen är att bara ringa den en gång, vid aktivering. Här är ett exempel:
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 är viktigt att veta att endast ett av alternativen som beskrivs kommer att fungera: om uninstall.php existerar, kommer det att köras och någon avinstallationskrok kommer inte att sparkas.
Bästa praxis
Sammanfattar allt ovan, här är en översikt över att skapa en solid grund för ett WordPress-plugin:
- Hitta ett unikt namn
- Ange ett prefix (relaterat till ditt varumärke)
- Skapa pluginens mapp
- Skapa undermappar för PHP-filer, tillgångar och översättningar
- Skapa huvud pluginfilen och fyll i obligatorisk headerinformation
- Skapa en readme.txt-fil
- Använd lämpliga konstanter och funktioner för att upptäcka sökvägar till pluginfiler
- Skapa ytterligare PHP-filer och inkludera dem i huvuddelen
- Skapa aktiverings- och avaktiveringsfunktioner
- Skapa ett avinstallationsskript
Slutsats
Efter alla dessa steg är du redo att faktiskt göra din plugin för att göra något genom att skapa sin kod. Vi lär oss några användbara koncept som gör WordPress-plugins spännande och flexibla i nästa artikel i denna serie. Men några viktiga aspekter kan framhävas just nu:
- Utveckla aldrig utan att felsöka. Det finns gott om information om WordPress-felsökningsläget och olika plugins för att få extra meddelanden. De är dina pålitliga assistenter på väg till felfri och aktuell kod.
- Prefix allt. Använd ett unikt prefix (vanligtvis pluginens namnderivat) för alla dina funktioner, variabler, klasser etc. för att säkerställa att pluginet är kompatibelt med andra utvecklarers arbete.
- Följ WordPress kodningsstandarder . Dessa standarder är en uppsättning regler som implementeras av kärnteamet för alla WordPress-koden för att göra det enkelt att läsa och underhålla. Följande standarder bidrar till att upprätthålla konsistensen av kärnkoden i ditt plugin.
- Använd kärnfunktioner, API och klasser för vanliga uppgifter. WordPress ger utvecklare ett brett utbud av verktyg för vanligt förekommande operationer (som databasinteraktion eller användarautentisering), så att du kan koncentrera dig på den verkliga unika funktionaliteten i din plugin.
- Dokumentera din kod. Egentligen finns det inte mycket att säga om denna princip - oavsett vilka konventioner som används, både dig som utvecklare och vi som samhälle drar nytta av väl dokumenterad kod.
Jag hoppas att den här inledande informationen inspirerar dig att börja utvecklas med WordPress. Se upp för nästa del av serien inom en snar framtid.
Vilka tips skulle du lägga till i den här introduktionen? Vad skulle du vilja se omfattas i nästa artikel i serien? Låt oss veta i kommentarerna!