Share
En av de mange tingene du vil finne når du undersøker en god plugin-utviklerens kildekode, er egendefinerte kroker og filtre som utvikleren har plassert gjennom plugin. Tilstedeværelsen av disse handlekrokene og filtene gjør plugin "utvidbar", noe som betyr at andre plugins og temaer kan manipulere eller legge til på pluggenes oppførsel.
Skrive utførbare plugins er noe jeg vil sterkt oppfordre deg til å gjøre. Det er en mye av gode grunner hvorfor du bør gjøre det, men svært få (hvis noen) grunner til at du bør unngå denne praksisen.
Vi skal se på flere elementer av utvidbare plugins:
Et viktig notat: denne opplæringen vil bare bruke prosessbasert programmeringsteknikker. Alt jeg snakker om her gjelder fortsatt når du bruker Objektorientert Programmering (OOP), men det er enklere å først lære disse teknikkene i en prosessstilling.
En utvidbar plugin er en som kan modifiseres og utvides utover det opprinnelige formålet med et annet plugin eller tema. Når et plugin er utvidbart, kan andre plugins (eller temaer) endre oppførselen eller utgangen av plugin. For eksempel tillater e-handelplugger tilleggsbetalingsgateways som tillater kjøp å behandles via flere betalingssystemer. Disse betalingsportene er separate plugins som bare kobler til kjerneplugin og utvider funksjonaliteten.
Alle plugins kan være utvidbare, men bare en liten minoritet av publiserte plugins er. For å være utvidbar eller modulær (en annen term for det samme), må en plugin-utvikler gjøre en bevisst beslutning om å gjøre det på den måten ved å implementere de nødvendige elementene som gjør det mulig for andre plugins og temaer å knytte seg til kjernepluginens oppførsel.
Det er mange gode grunner til å skrive utførbare plugins, men en av hovedgrunnene er at det ganske enkelt ikke er en god grunn ikke å skrive pluginene dine på denne måten, spesielt ikke når pluginene dine blir gitt ut til WordPress-fellesskapet, enten som gratis eller betalte plugins.
Når du skriver utførbare plugins, kan du gjøre det mulig for andre utviklere å utvide pluginet ditt og gjøre det enda bedre, men uten å endre kjerne kildekoden. Du gjør det også betydelig enklere for utviklere og brukere å tilpasse pluginet som passer deres behov bedre. La meg gi deg et eksempel: I min Easy Digital Downloads plugin er det et rabattkodesystem. Rabattkoder er begrenset til en enkelt bruk per bruker, så hvis en bruker forsøker å bruke samme rabatt på to forskjellige kjøp, vil de få en feil. En av mine virkelige brukere fant at hun ikke ville begrense rabatter til en enkelt bruk per bruker, så jeg ga henne en enkel funksjon som hun droppet inn i en ny tilpasset plugin og begrensningen ble fjernet uten å berøre noen kjernepluginekode.
Extensible kode gjør også andre utviklere svært glade når de finner det fordi jobben sin med å tilpasse koden din, ble bare mye, mye lettere.
Det er flere viktige verktøy du trenger for å skrive utførbare plugins. Hvis du har skrevet noen plugin eller temaer før du leser dette, er du sannsynligvis minst kjent med disse funksjonene, selv om det bare er fordi du har sett dem brukt.
Før jeg viser deg de funksjonene du vil bruke, la oss snakke om to hovedbegreper først: kroker og filtre.
En handlingskrog er et sted i pluginet ditt som kan "hooked" inn av funksjoner (både i plugin og andre plugins) for å få sin kode kjørt ut på det tidspunktet. Når en handlingskrok løper, vil alle funksjoner som er tilkoblet, eller "hekta", også løpe.
Et filterkrok er også et sted i pluginet for at andre funksjoner skal knyttes inn, men de fungerer litt annerledes enn handlinger. Filtre tillater at data blir manipulert eller modifisert før det blir brukt.
Hovedforskjellen mellom handlinger og filtre er at handlinger vanligvis brukes til å utføre funksjoner, og filtre brukes vanligvis til å manipulere data.
Med mindre du allerede er godt kjent med handlinger og filtre, vil jeg sterkt oppfordre deg til å lese Codex-oppføringen på dem.
For handlinger er det fire hovedfunksjoner:
Accentsconagua
do_action () - Dette definerer en hørbar plassering for handlingerADD_ACTION () - Dette fester en funksjon til en krok laget med do_action () has_action () - Dette kontrollerer for å se om en handling er registrert hos do_action () remove_action () - Dette fjerner en handling som ble satt til ADD_ACTION () Av disse fire vil du bruke do_action () og ADD_ACTION () det meste.
For filtre er det også fire hovedfunksjoner:
apply_filters () - Dette skaper en hookable plassering for tilpassede filtre å knytte seg tiladd_filter () - Dette legger til et egendefinert filter til en krok laget med apply_filters () has_filter () - dette kontrollerer for å se om et filter er registrert hos apply_filters () remove_filter () - Dette fjerner et filter som tidligere er koblet til apply_filters () Som med handlinger, apply_filters () og add_filter () er de to du vil bruke mest.
Hvis du er forvirret på dette punktet, ikke bekymre deg, vi skal se på hvordan du faktisk bruker disse i neste avsnitt.
For å gjøre pluginet ditt virkelig utvidbart, må du bruke nøkkelfunksjonene nevnt ovenfor over hele plugin-modulen. I begynnelsen kan det hende du finner det vanskelig, tungvint, irriterende eller mange andre relevante adjektiver, for alltid å legge disse tilleggsfunksjonene i hele koden din, spesielt når du ikke ser en umiddelbar fordel eller bruk for dem.
Det du finner, er imidlertid at når du er vant til å skrive pluginene dine med alle disse funksjonene i tankene, blir det andre natur for å inkludere dem.
Det er noen hovedscenarier hvor du vil bruke filtre i pluginene dine:
Av scenariene ovenfor er det mest vanlig å bruke filtre når data returneres eller like før det blir brukt. Hvis du for eksempel har et plugin som utfører et innleggspørsmål, er det best å passere rekke spørringsargumenter gjennom et filter før de sendes til get_posts () eller WP_Query slik at andre kan manipulere spørringen før den er laget.
Når det kommer til handlinger, er det også flere hovedsteder der du plasserer dem:
La oss vurdere noen få eksempler nå.
Kortkoder som utgiver HTML er ekstremt vanlige (faktisk de er sannsynligvis det vanligste av alle kortkoder), og en av måtene som vi kan gjøre korttastene til pluginene våre er mer vennlige til andre utviklere, er å gi en måte for dem å endre innholdet i shortcode, men uten å kreve at det blir avregistrert og registrert på nytt.
Alle kortkoder returnerer i stedet for å ekko innholdet, noe som betyr at dataene som sendes ut på skjermen, kommer til å være i form av en streng før den returneres. Fordi hele HTML-utgangen er i form av en streng, kan du sende strengen gjennom et filter før du returnerer den. Dette gjør det mulig for andre utviklere å endre HTML-koden til din kortkode.
En utvikler vil kanskje legge til ytterligere merking før og etter standard HTML: med filteret på plass, kan de gjøre det.
Din kortnummer kan se slik ut:
funksjon wptp_sample_shortcode (atts, $ content = null) $ html = ''; $ html. = ''; returner $ html;Innholdet i sample shortcode
'; $ html. = '
Vi kan forbedre dette ved å legge til et filter på retur, slik som:
funksjon wptp_sample_shortcode (atts, $ content = null) $ html = ''; $ html. = ''; return apply_filters ('wptp_shortcode_html', $ html);Innholdet i sample shortcode
'; $ html. = '
HTML-koden i vår kortnummer kan nå endres som denne:
funksjon wptp_modify_html ($ html) return ''. $ html. ''; add_filter ('wptp_shortcode_html', 'wptp_modify_html');
Dette vil resultere i at den opprinnelige HTML som er opprettet i kortnummeret er pakket inn med en annen div stikkord.
Å utføre tilpassede spørringer i plugins er en vanlig praksis. La oss anta et øyeblikk at du har skrevet et plugin som registrerer en egendefinert innleggstype kalt "bøker", og i plugin er en funksjon for å vise skapte bøker. Din funksjon for å spørre bøkene kan se slik ut:
funksjon wptp_show_books () $ query_args = array ('post_type' => 'bøker', 'posts_per_page' => 5); $ bøker = nye WP_Query ($ query_args); hvis ($ books-> have_posts ()): mens ($ books-> have_posts ()): $ books-> the_post () // vis info om hver bok her en gang; slutt om; wp_reset_postdata (); Men hva om en bruker ønsket å endre hvilke bøker som ble returnert, kanskje bare å velge bøker fra en bestemt kategori? Du kan gjøre dette mye lettere for dem ved å gjøre dette:
funksjon wptp_show_books () $ query_args = array ('post_type' => 'bøker', 'posts_per_page' => 5, 'author' => 3); $ books = new WP_Query (apply_filters ('wptp_books_query', $ query_args)); hvis ($ books-> have_posts ()): mens ($ books-> have_posts ()): $ books-> the_post () // vis info om hver bok her en gang; slutt om; wp_reset_postdata (); Den eneste endringen jeg laget var å legge til et filter rundt $ query_args, noe som betyr at andre utviklere (eller brukere) kan endre spørringsargumentene før de faktisk overføres til WP_Query. For eksempel kan vi sette spørringen for å bare vise bøker fra forfatter 3 slik:
funksjon wptp_alter_books_query ($ args) $ args ['author'] = 3; returner $ args; add_filter ('wptp_books_query', 'wptp_alter_books_query'); La oss forlenge på eksempel nummer 2 nå og gjøre det enda bedre. Vi har allerede lagt til et filter som lar brukerne endre søket, nå la oss legge til noen få kroker for å la oss endre HTML-koden som er opprettet.
Først vil vi endre vår opprinnelige HTML litt:
funksjon wptp_show_books () $ query_args = array ('post_type' => 'bøker', 'posts_per_page' => 5, 'author' => 3); $ books = new WP_Query (apply_filters ('wptp_books_query', $ query_args); hvis ($ books-> have_posts ()): echo ''; mens ($ books-> have_posts ()): $ books-> the_post () echo ''; ekko ''. get_the_title (). '
'; ekko ''; EndWhile; ekko ''; slutt om; wp_reset_postdata (); Vi vil nå gjøre det mulig for utviklere å legge til ekstra oppslag på forskjellige punkter, for eksempel følgende:
Du kan forestille deg et scenario der en bruker vil legge til et miniatyrbilde før eller etter boktittel. For å gjøre dette mulig, bruker vi do_action () å opprette hookable steder, slik som dette:
funksjon wptp_show_books () $ query_args = array ('post_type' => 'bøker', 'posts_per_page' => 5, 'author' => 3); $ books = new WP_Query (apply_filters ('wptp_books_query', $ query_args)); hvis ($ books-> have_posts ()): do_action ('wptp_books_before'); ekko ''; mens ($ books-> have_posts ()): $ books-> the_post () echo ''; do_action ('wptp_before_book_title', get_the_ID ()); ekko ''. get_the_title (). '
'; do_action ('wptp_after_book_title', get_the_ID ()); ekko ''; EndWhile; ekko ''; do_action ('wptp_books_after'); slutt om; wp_reset_postdata (); Merk at de to indre krokene (rundt tittelen) har en andre parameter på get_the_ID (). Denne variabelen, som vil være IDen til boken, vil være tilgjengelig som en parameter til enhver tilkoblet funksjon. For å legge til i en miniatyr på en bok, kan vi for eksempel gjøre dette:
funksjon wptp_show_book_image ($ book_id) echo get_the_post_thumbnail ($ book_id, 'thumbnail'); add_action ('wptp_before_book_title', 'wptp_show_book_image'); Jeg vil nå vise deg noen virkelige eksempler på plugins som er utvidbare, inkludert eksempler på noen av deres utvidbare funksjoner.
Soliloquy er et kraftig WordPress-responsivt bildeglassplugin som gjør det mulig å skape og opprettholde lydhør, effektiv, sikker og SEO-vennlig bildestyring en bris.
Nesten alt i dette pluginet er utvidbart. Her er bare ett eksempel:
$ labels = apply_filters ('tgmsp_post_type_labels', array ('navn' => __ ('Soliloquy', 'soliloquy'), 'singular_name' => __ ('Soliloquy', 'soliloquy'), 'add_new' => __ 'Add New', 'Soliloquy'), 'add_new_item' => __ ('Legg til ny Soliloquy Slider', 'Soliloquy'), 'edit_item' => __ ('Rediger Soliloquy Slider', 'Soliloquy'), 'new_item' => __ ('Soliloquy Slider', 'Soliloquy'), 'view_item' => __ ('Se Soliloquy Slider', 'Soliloquy'), 'search_items' => __ ('Søk Soliloquy Sliders', 'Soliloquy') , 'not_found' => __ ('Ingen Soliloquy Sliders funnet', 'Soliloquy'), 'not_found_in_trash' => __ ('Ingen Soliloquy Sliders funnet i søppel', 'Soliloquy'), 'parent_item_colon' => "," menynavn '=> __ (' Soliloquy ',' soliloquy ')); $ args = apply_filters (' tgmsp_post_type_args ', array (' etiketter '=> $ etiketter,' public '=> true,' exclude_from_search '=> true' show_in_admin_bar '=> false,' rewrite '=> false,' query_var '=> false,' menu_position '=> 100,' menu_icon '=> plugins_url (' css / images / meny-icon.png ', dirname (__FILE__)),' støtter '=> array (' title '))); Slik oppretter Thomas Griffin (pluginens utvikler) argumentene for både de egendefinerte innleggstypene og attributter. Tilstedeværelsen av hans to filtre, tgmsp_post_type_labels og tgmsp_post_type_args, gjør det veldig enkelt for andre utviklere å gi nytt navn til skyveposttypen eller endre hva posttypen støtter.
Langt en av mine personlige favorittprogrammer av all tid, er bbPress et fullverdig forumtillegg for WordPress. Hele plugin er et perfekt eksempel på hvordan du gjør pluginene utvidbare, da det bokstavelig talt har handlinger og filtre overalt. Den har et spesielt filter som brukes når man henter innholdet i et forum:
funksjon bbp_get_forum_content ($ forum_id = 0) $ forum_id = bbpget_forum_id ($ forum_id); // Sjekk om passord er påkrevd hvis (post_password_required ($ forum_id)) returnere get_the_password_form (); $ content = get_post_field ('post_content', $ forum_id); return apply_filters ('bbp_get_forum_content', $ content, $ forum_id); Før innholdet i forumet returneres, sendes det gjennom et filter som kalles bbp_get_forum_content som gjør det mulig for en utvikler å endre innholdet før det noen gang vises.
Easy Digital Downloads, eller EDD, er en av mine plugins som ble bygget for å gjøre det utrolig enkelt å selge digitale produkter gjennom WordPress. Som med de fleste e-handelstillegg, har EDD en kasseprosess som kjøperen går gjennom, slik at de kan legge inn sine personlige og betalingsdetaljer. Etter at all den informasjonen er samlet, går det hele til en betalingsgateway (et system for behandling av betalingen), men før det går til gatewayen, brukes et filter som tillater at dataene blir manipulert før det blir brukt av betalingen system:
$ buy_data = apply_filters ('edd_purchase_data_before_gateway', $ buy_data, $ valid_data); Tilstedeværelsen av dette filteret gjør det mulig å justere innkjøpsbeløp (kanskje for spesielle rabatter), legge til skatt, kanskje legge til eller fjern produkter fra kjøpet, og mye, mye mer.
Extensible plugins fordeler alle: den opprinnelige utvikleren, andre utviklere og brukerne selv.
Det er så mange grunner til at du bør skrive pluginene dine med uttrekkbar kode i tankene, så hvorfor gjør du det ikke?
Verktøyene som presenteres her er alt du trenger for å komme i gang. Har du spørsmål? Spør i vei!
