Bygg din første WordPress-plugin (del 2)
I den forrige delen av serien vår Vi opprettet basen for et WordPress-plugin som er gjenkjennelig av kjernen. I dag skal vi lære å faktisk endre standardfunksjonaliteten til kjernen.
Konseptet med kroker, handlinger og filtre er ansvarlig for det; å være det virkelige hjertet av hele WordPress pluginsystemet.
Alt starter fra "krokene" som kjernen selv gir.
Hva er en "krok"? Det er et spesielt merket sted i koden (av et hvilket som helst skript), der noen bevisst registreres - "hooked in" - funksjoner kan utføres i den rekkefølgen som er definert ved registrering.
WordPress har to typer kroker som er forskjellige i deres formål:
- Handlingskrok: markerer stedet for å utføre en handling, for eksempel prosessinngang og lagre resultater i en database
- Filterkrok: markerer stedet for å bruke en modifisering til en verdi (normalt oppgitt som variabel), slik at følgende kode vil bruke den justerte verdien
La oss dykke inn i detaljene ...
Arbeider med handlinger
Den vanlige logikken til WordPress-handlinger er veldig enkel:
- Merk stedet hvor den egendefinerte koden skal gå, med en "action hook" og dens parametere
- Lag handlingsfunksjonen som kjører den nye koden ved hjelp av (hvis nødvendig) parametere som følger med kroken
- Registrer handlingen (# 2) som skal utføres når kroken (# 1) er avfyrt med noe prioritet
- Når WordPress laster den forespurte siden og finner kroken, vil den se etter alle funksjonene "hekta på" den og utføre dem en etter en i samsvar med deres prioritet
For å utføre oppgave # 1 har vi funksjonen 'do_action':
do_action($tag, $arg_1, $arg_2, ... , $arg_n);Den aksepterer følgende parametere: $ tag - kroken "navn" som bidrar til å identifisere den bestemte kroken og skille den blant andre; $ arg_1, $ arg_2, ..., $ arg_n - verdier for handlinger som skal aksepteres som parametere. Det kan være så mange argumenter som trengs - fra null opp til en rimelig mengde.
WordPress selv har mange forhåndsdefinerte kroker som skal brukes:
do_action( 'init' );Dette er veldig greit, uten ekstra parametere. Denne kroken avfyres når det meste av WordPress er opprettet, og det er tid for å registrere egendefinerte objekter, for eksempel egendefinert posttype, for eksempel.
do_action('save_post', $post_id, $post);I dette eksemplet blir kroken sparket når innlegget er lagret, og gir to ekstra parametere for å operere med - post_id og postobjekt som inneholder alle dataene fra det lagrede innlegget.
Men å skape kroker er ikke bare et privilegium i kjerneteamet; hver utvikler kan lage en tilpasset krok for plugin (eller tema). Takket være dette har vi mye kraft, for eksempel gir tema-temaer barnes temaer å endre ikke bare stiler, men også oppmåling av foreldre uten å overskrive hele filene.
do_action( 'my_truly_custom_hook' );Når vi har funnet (eller opprettet) en riktig krok og opprettet en egendefinert funksjon for det, bør vi registrere det siste for utførelsen med 'add_action'.
add_action($tag, $function_to_add, $priority, $accepted_args_number);Som det kan forventes, aksepterer add_action-metoden to obligatoriske parametere: $ tag: navnet på den aktuelle kroken og $ function_to_add: navnet på funksjonen som skal utføres. De to andre parametrene er valgfrie: $ prioritet: et heltall for å angi rekkefølgen der de registrerte funksjonene utføres (som standard 10), $ accepted_args_number: antall argumenter som den registrerte funksjonen vil akseptere (som standard 1) .
La oss se på et eksempel for å illustrere hele prosessen. Anta at vi vil legge til en liten varsel nederst på nettstedet vårt. Vi kunne bruke 'wp_footer'-kroken for dette fordi det er en del av obligatorisk footer-kode som hvert tema bør inkludere.
function msp_helloworld_footer_notice(){echo "Hello, I'm your custom notice";}add_action('wp_footer', 'msp_helloworld_footer_notice');I dette eksempelet oppretter vi en prefiks-funksjon som bare utløser varselets oppslag (betydningen av prefiksene vi har diskutert i den forrige artikkelen , så vennligst referer til det for detaljer) og deretter hekta det inn i 'wp_footer'. Når vi inkluderer denne koden i vår plugin-fil (også omtalt i forrige artikkel), ser vi resultatet på nettstedet.
Arbeider med filtre
Filtre opererer med samme logikk som handlinger. Den eneste forskjellen er at de ikke bare utfører noe stykke kode på et bestemt sted. De utfører denne koden for å modifisere noen verdi gitt til dem ved kroken. Dette betyr at hver filterkrok har tilhørende verdi (i de fleste tilfeller bæres av en variabel).
Funksjonen som utfører filtrering bør ta denne verdien, endre den på en eller annen måte og deretter returnere den for videre bruk. Slik at syntaxen til funksjoner som er ansvarlige for kroker og filtre, er litt annerledes.
apply_filters($tag, $value_to_filter, $arg_1, $arg_2, ... , $arg_n);Funksjonen 'apply_filter' lager en filterkrok med $ tagnavn og obligatorisk parameter $ value_to_filter (det kan være tomt, men skal være til stede for beste praksis). Andre argumenter er valgfrie og fungerer på samme måte som for handlinger.
filter_function($value_to_filter, $arg_1, $arg_2, ... , $arg_n){//filtering code goes herereturn $value_to_filter; //value has to be returned back}Dette er et skjelett med filterfunksjon som viser at det skal a) akseptere minst ett argument, verdien for modifikasjon; og b) returnere verdien på slutten.
add_filter($tag, $function_to_add, $priority, $accepted_args);Funksjonen 'add_filter' registrerer en funksjon med et navn gitt som $ function_to_add argumentet for $ tag filterkroken. De valgfrie argumentene - $ prioritet og $ accepted_args - fungerer på samme måte som for handlingskroker.
La oss vise hele prosessen i handling: En vanlig plugin-oppgave er å legge til noe innhold ved slutten av et innlegg. Hvis vi ser nærmere på 'the_content'-mal-taggen ( queryposts.com/function/the_content ), som vanligvis brukes til å sende ut et innleggs innhold i et tema, vil vi finne at den inneholder følgende filterkrok:
$content = apply_filters('the_content', $content);Ved hjelp av denne kroken kan vi enkelt legge til noe til slutten av innlegget på følgende måte:
function msp_helloworld_post_footer($content) {$content .= "";return $content;} add_filter ('the_content', 'msp_helloworld_post_footer', 100); Vær oppmerksom på at vi bruker ganske stort nummer for prioritet her for å sikre at alle standardfiltre har blitt brukt før vår "msp_helloworld_post_footer". Etter at du har lagt inn koden i pluginfilen, bør vi se resultatet på nettstedet:
Hvordan finne kroker
Det skal være åpenbart at nå for å implementere handling og filterfunksjonalitet må vi vite hvilke kroker som er tilgjengelige.
WordPress Codex gir en Handlingsreferanse med de fleste handlingskrokene slått på typisk sidelast og a Filterreferanse med en liste over brukte filtre. Disse referansene er nyttige for å forstå rekkefølgen av handlinger og logikk for filtre, slik at du kan velge hvor og når funksjonalitet kan og skal injiseres.
Deretter er du klar for turen inn i kildekoden. Du kan bare utføre et søk gjennom WordPress-filene for søkeordene 'do_action' og 'apply_filters' for å finne kroken du trenger.
forståelse WordPress spørringslogikk kan også hjelpe deg med å finne ut hvor noen kroker kan søkes.
Til slutt kan du referere til WordPress Hooks Database som inneholder full informasjon om krokene i kjernefilene.
Avanserte operasjoner med kroker
I tillegg til å bli lagt til plugin, kan handlinger og filtre også fjernes med en lignende syntaks.
Handlinger kan fjernes på følgende måte:
remove_action($tag, $function_to_remove, $priority, $accepted_args);remove_all_actions($tag, $priority);Som du sikkert har glemt 'remove_action', fjerner du en bestemt handling registrert for en bestemt krok (du må angi riktig prioritet og antall argumenter som de ble brukt ved registrering), og 'remove_all_actions' bidrar til å fjerne alle handlinger registrert med en bestemt Kryss med en gitt prioritet (hvis prioritetsargumentet utelates, fjerner funksjonen alle handlinger).
Du har sikkert hørt om en populær sikkerhetsanbefaling for å skjule WordPress-versjonen fra hovedenheten på nettstedet. Dette er en jobb for 'remove_action'.
Først av alt, la oss finne koden som hakker funksjonen 'wp_generator' for å skrive ut versjonen ved å bla /wp-includes/default-filters.php . Koden som gjør dette ser slik ut:
add_action('wp_head', 'wp_generator');For å eliminere effekten av denne koden, bør vi et sted i pluginet vårt, inneholde den motsatte funksjonen:
remove_action('wp_head', 'wp_generator');Filtre kan fjernes på lignende måte:
remove_filter($tag, $function_to_remove, $priority, $accepted_args);remove_all_filters($tag, $priority);De Plugin API gir også utviklere en måte å oppdage om den aktuelle kroken har registrerte funksjoner som skal utføres:
has_action($tag, $function_to_check);has_filter($tag, $function_to_check);Begge funksjonene kontrollerer om en bestemt handling eller et filter er registrert for en krok og returnerer: Sann på suksess, feil på feil. I den krokede funksjonen har vi mulighet til å sjekke hvilken krok som har utløst utførelsen på følgende måte:
if('hook_to_check_name' === current_filter()){//do stuff related to 'hook_to_check_name' hook}Til tross for navnet fungerer "Current_filter" ikke bare med filtre, men også med handlinger. For hele settet av Plugin API-funksjoner, referer til Codex .
Real-world case
La oss grave opp pluginskjelettet som vi forberedte oss på den forrige delen av serien , og pust litt liv inn i det.
Vi skal fylle ut filen 'core.php' (den sentrale delen av pluginet vårt er ment å ha det meste av funksjonaliteten) med koden som løser en virkelig oppgave ved hjelp av handlinger og filtre.
Hva skal vi gjøre? Anta at ditt WordPress-nettsted aksepterer gjesteposter fra forskjellige forfattere, men gir dem ikke tillatelse til å lage egne kontoer for innlegging. Det betyr at brukeren, som har publisert artikkelen, og den virkelige forfatteren av den (gjesten) er forskjellige mennesker. Du må sørge for at den faktiske forfatteren mottar kreditt. Dette kan gjøres med tilpasset taksonomi.
La oss lage en egendefinert taksonomi å håndtere gjestforfatterens navn (som et begrep) og kortforfatterens bio (som en beskrivelse). Vi ville være i stand til å tilordne forfatterens navn som alle andre taksonomiets vilkår (som merker) til innlegg. Etter det blir det mulig å skrive ut en forfatters boks rett etter innleggets tekst. Her er koden:
/** Hook plugin's action and filters **/function msp_helloworld_init(){add_action('init', 'msp_helloworld_taxonomies');add_filter('the_content', 'msp_helloworld_author_block_filter');add_filter('post_class', 'msp_helloworld_post_class');}add_action('plugins_loaded', 'msp_helloworld_init');/** Register custom taxonomy **/function msp_helloworld_taxonomies(){$args = array('labels' => array('name' => 'Guest authors','singular_name' => 'Guest author'),'show_in_nav_menus' => false);register_taxonomy('gauthor', array('post'), $args);} / ** Opprett forfatterens bokmerke ** / funksjon msp_helloworld_author_block () {global $ post; $ author_terms = wp_get_object_terms ($ post-> ID, 'gauthor'); hvis (tom ($ author_terms)) returnerer; $ name = stripslashes $ author_terms [0] -> navn); $ url = esc_url (get_term_link ($ author_terms [0]); $ desc = wp_filter_post_kses ($ author_terms [0] -> beskrivelse); $ out = " "; $ ut. =" Dette er et gjestepost av ![]()
{$name}
"; $ ut. =" "; return $ out;} / ** Legg til forfatterens boks til slutten av innlegget ** / funksjon msp_helloworld_author_block_filter ($ innhold) {if (is_single ()) $ content. = msp_helloworld_author_block (); return $ content;} / * * Legg til tilpasset CSS-klasse i postens container ** / funksjon msp_helloworld_post_class ($ post_class) {global $ post; $ author_terms = wp_get_object_terms ($ post-> ID, 'gauthor'); {$post_class[] = 'gauthor';} returner $ post_class;} Som du kan se, har vi opprettet en handling for å registrere en egendefinert taksonomi og brukt den til 'init'-kroken - dette er en anbefalt praksis. Etter det har vi opprettet mal-taggen som er ansvarlig for forfatterboksens oppretting ved hjelp av native WordPress-funksjoner som 'wp_get_object_terms'. Deretter festet vi denne boksen til slutten av innleggets innhold ved hjelp av filterkroken "the_content". Og til slutt har vi lagt til den egendefinerte CSS-klassen for gjesteinnleggets beholder for stylingfleksibilitet i temaet. Etter å ha brukt noen stiler kan vi se resultatet:
Konklusjon
Handlinger og filtre er den viktigste delen av enhver WordPress-utvikling. Nå som du forstår deres logikk og oppførsel, er du forberedt på dine egne eksperimenter.
Hvilke bruksområder har du funnet for WordPress-handlinger og -filtre? Hva vil du se dekket i neste del av denne serien? Gi oss beskjed i kommentarene.