Flere tips for beste praksis i WordPress Development

Velkommen til den andre delen av serien. I den første artikkelen forklarte vi WordPress-kodingsstandardene, hvordan du unngår navneområdeskollisjoner, kommentarer i koden og noen grunnleggende sikkerhetstips.

I dag skal vi gå litt dypere og skrive litt mer kode og lære noen teknikker for å forbedre ytelsen og sikkerheten til pluginene våre. Emnene vi skal dekke er som følger:

  1. Hvordan og når skal jeg inkludere skript / stiler
  2. Slik utfører du Ajax-anrop på riktig måte
  3. Filtre og handling for å gi brukerne frihet

Ta tak i kodeditoren og gjør deg klar til å spille med WordPress!

Hvordan og når skal jeg inkludere skriptene mine?

Det første du må huske på er at WordPress har to fantastiske funksjoner (wp_enqueue_script og wp_enqueue_style) for å la deg inkludere skript og stiler. Til slutt må du ikke legge dem manuelt i overskriften eller bruke wp_head action hook. 

Hvis du bruker WordPress-metodene, kan caching og minifiseringsplugger inkludere skriptene i deres funksjoner, du vil kunne velge å plassere dem i bunntekst eller overskrift veldig enkelt, du vil kunne legge til avhengige skript og også bruke alle triks forklart nedenfor sammen med andre funksjoner. 

Stemmer ikke:

add_action ('wp_head', 'my_custom_scripts'); funksjon my_custom_scripts () echo ''; 

Riktig:

add_action ('wp_enqueue_scripts', 'my_customs_scripts'); fungere my_customs_scripts () wp_enqueue_script ('script-handler', get_template_directory_uri (). '/js/my.js', array ('jquery'), '1.0.0', true); 

Jeg vil ikke gi deg en fullstendig veiledning om hvordan du bruker wp_enqueue_xxxx som det er mange av dem tilgjengelige (og Codex er en flott ressurs!), Og jeg prøver å bare peke på hvordan du skal legge til skript i temaene eller pluginene dine.

Hva du trenger alltid Husk å forlate det letteste fotavtrykket. Dette betyr at du ikke bør inkludere filer der de ikke skal være. 

Du kan tenke "det er bare en fil, det vil ikke påvirke nettstedet" og med den tankegangen er det som å kaste et papir i bakken i parken fordi det bare er et enkelt papir, men det er ikke slik ting fungerer: Hvis alle utviklere forlater sine skript overalt, den endelige brukeren vil ende med et helt oppblåst nettsted, og vi vil ikke ha det.

Nå som vi har dekket det, får vi se noen tips om hvordan du bare skal inkludere skriptene dine når det trengs.

1. Inkluder aldri Front End Files i Backend og Vice Versa

// FRONT END END add_action ('wp_enqueue_scripts', 'my_front_customs_scripts'); fungere my_customs_scripts () wp_enqueue_script ('script-handler', get_template_directory_uri (). '/js/my.js', array ('jquery'), '1.0.0', true);  // BACKEND ONLY add_action ('admin_enqueue_scripts', 'my_back_customs_scripts'); fungere my_customs_scripts () wp_enqueue_script ('script-handler', get_template_directory_uri (). '/js/my.js', array ('jquery'), '1.0.0', true); 

Men vent! La oss gå et skritt videre og bare inkludere skript i sidene du virkelig trenger dem. En god metode er å registrere dem først og deretter enque på de nødvendige sidene

2. Inkluder kun filer på de nødvendige sidene

// FRONT END END add_action ('wp_enqueue_scripts', 'my_front_customs_scripts'); funksjon my_customs_scripts () wp_register_script ('script-handler', get_template_directory_uri (). '/js/my.js', array ('jquery'), '1.0.0', true); hvis (is_page ('min side')) wp_enqueue_script ('script-handler');  // Vær kreativ for å bare inkludere filer ved behov // hvis (is_single ()) // hvis (is_home ()) // hvis ('cpt-name' == get_post_type ()) // BACKENDEND ONLY add_action (' admin_enqueue_scripts ',' my_back_customs_scripts '); fungere my_customs_scripts ($ hook) wp_register_script ('script-handler', get_template_directory_uri (). '/js/my.js', array ('jquery'), '1.0.0', true); // For å inkludere det bare når du redigerer et innlegg hvis ('edit.php' == $ krok) wp_enqueue_script ('script-handler');  // Hvis du la til en tilleggsside som denne // $ plugin_screen_id = add_options_page (...) // du kan gjøre $ screen = get_current_screen (); hvis ($ plugin_screen_id == $ skjerm-> id) wp_enqueue_script ('script-handler');  / * En annen måte å bruke skjerm ID * / add_action ('admin_print_styles-'. $ Plugin_screen_id, 'my_back_customs_scripts');

3. Er du Enqueueing Scripts å bruke med kortkoder?

// FRONT END END add_action ('wp_enqueue_scripts', 'my_front_customs_scripts'); funksjon my_customs_scripts () wp_register_script ('script-handler', get_template_directory_uri (). '/js/my.js', array ('jquery'), '1.0.0', true); // hvis du trenger et skript som skal inkluderes for en kortkode // Ikke legg det overalt // I stedet kan du bare inkludere det når det trengs global $ post; hvis (is_a ($ post, 'WP_Post') && has_shortcode ($ post-> post_content, 'tilpasset kortkode')) wp_enqueue_script ('script-handler'); 

4. Inkluder stiler med conditionals

Mens de andre kodestykkene gjelder både, skript og stiler, fungerer følgende kun med wp_enqueue_style (i hvert fall for nå).

// FRONT END END add_action ('wp_enqueue_scripts', 'my_front_customs_styles'); funksjon my_front_customs_styles () wp_register_style ('my-plugin-css', plugins_url ('my-plugin / css / plugin.css')); // La oss inkludere denne css bare for gamle (og crappy) nettlesere wp_enqueue_style ('my-plugin-css'); global $ wp_styles; $ wp_styles-> add_data ('my-plugin-css', 'betinget', 'lte IE 9'); 

Du kan se flere eksempler i Codex. Et annet godt eksempel som du kan bruke til å starte alle plugins er WordPress Plugin Boilerplate. Ta en titt på koden for å se hvordan skript og stiler er inkludert. Wpfavs-plugin (basert på WordPress Plugin Boilerplate) er et godt eksempel på hvordan du lager et plugin for backend av Wordpress.

2. Hvordan du skal utføre Ajax-anrop

For dette emnet vil jeg dele noen dårlige vaner som jeg så mye når jeg gjorde Ajax i WordPress og de kunne deles i følgende setninger:

  • Ajax-anrop skal ikke gjøres direkte til en fil
  • Ajax-anrop skal bruke en nonce-verdi
  • Sjekk om brukerrettigheter, om nødvendig
  • JavaScript-variabler skal inkluderes med wp_localize_script

Jeg vet at jQuery gjør Ajax kaller et stykke kake, og vi kan bare bare lage en fil som heter ajax.php, inkluderewp-load.php på den og gjør vår Ajax der. Men det er ikke "WordPress-måten" - det er ikke fremtidssikker. Enda mer, det er mindre sikkert, og du vil savne mye WordPress-funksjonalitet.

Den riktige måten er å bruke wp_ajax_my_action og wp_ajax_nopriv_my_action action kroker. Hovedforskjellen mellom de to er at den første brukes til loggede brukere, og den andre brukes til ikke-loggede brukere.

Merk at "my_action" bør endres for handlingsnavnet ditt. Vi vil se hvordan det fungerer i et øyeblikk.

La oss se alt dette i et enkelt eksempel med litt kode og fantasi. La oss forestille oss at vi vil vise 5 innlegg når en bruker (logget eller ikke) klikker på en knapp. Vi skal nevne denne handlingen som cool_ajax_example, så la oss begynne å legge til Ajax tilbakeringingsfunksjonene som vil returnere dataene.

Du kan inkludere denne koden på din functions.php eller inne i pluginet ditt.

// Først legger vi til handlingene kroker add_action ('wp_ajax_cool_ajax_example', 'cool_ajax_example_callback'); add_action ('wp_ajax_nopriv_cool_ajax_example', 'cool_ajax_example_callback'); funksjonen cool_ajax_example_callback () ...

Som du kan se, bruker begge kroker samme tilbakeringingsfunksjon som returnerer dataene. Vær også oppmerksom på at vårt handlingsnavn er på slutten av kroknavnet wp_ajax_cool_ajax_example

Det er veldig viktigå skrive handlingsnavnet rett overalt, eller dette vil ikke fungere i det hele tatt.

Før vi fortsetter med tilbakeringingsfunksjonen, må vi flytte til jQuery som trengs for Ajax-samtalen. JQuery-skriptet brann når vi trykker på en enkel HTML-knapp, og vi må sende den forespørselen til admin-ajax.php fil at det er skriptet som håndterer alle AJAX-forespørsler i Wordpress. Også vi trenger å legge til en nonce som vi allerede har sagt at vi vil gjøre det sikkert så her kommer til handling the wp_localize_script funksjon.

Hvis du inkluderte skriptene på riktig måte som forklart i begynnelsen av denne artikkelen, har du et skriptbehandlernavn (i våre eksempler over 'script-handler'), så la oss bruke den til å sende våre PHP-verdier til vår javascriptfil. Du kan inkludere denne delen av koden rett etter wp_enqueue_function pleide å inkludere JavaScript.

wp_localize_script ('script-handler', 'MyVarName', array ('ajax_url' => admin_url ('admin-ajax.php'), 'nonce' => wp_create_nonce ('return_posts')));

Som du kan se wp_localize_script er en ganske enkel måte å sende noen PHP-variabel til våre JavaScript-filer, og den vil skrive ut gyldig xhtml på grunn av  tags. Koden ovenfor blir skrevet ut i overskriften når JavaScript-filen med script-handler som navnet er lastet og det vil se ut som om:

Nå er det på tide å lage vår javascriptfil, la oss kalle det my.js og det vil se ut som om:

(funksjon ($) $ (funksjon () $ ('# knapp'). klikk (funksjon (e) e.preventDefault (); $ .ajax (url: myVarName.ajax_url, data: action: ' cool_ajax_example ', nonce: myVarName.nonce, suksess: funksjon (respons) $ (' # respons-container '). html (respons);, type: "POST";;);;; ) (jQuery);

Vær oppmerksom på hvordan vi bruker nonce og ajax_url som vi passerte med wp_localize_script. Kontroller også at vi sender en POST-verdi kalt "handling" som samsvarer med handlingsnavnet vi brukte i wp_ajax kroker. 

Nå er det på tide å fullføre vår tilbakeringingsfunksjon. Det første vi må gjøre er å kontrollere at nonce er riktig og da kan vi returnere noen innlegg.

funksjonen cool_ajax_example_callback () $ nonce = $ _POST ['nonce']; // Det første vi gjør er å sjekke nonce og drepe skriptet hvis det er feil hvis (! Wp_verify_nonce ($ nonce, 'return_posts')) dør ('Wrong nonce!'); $ args = array ('post_type' => 'innlegg', 'post_status' => 'publiser', 'posts_per_page' => 5,); // Spørringen $ the_query = ny WP_Query ($ args); // Loop hvis ($ the_query-> have_posts ()) echo '
'; mens ($ the_query-> have_posts ()) $ the_query-> the_post (); ekko '

'. get_the_title (). '

'; ekko '
'; annet echo 'innlegg ikke funnet'; / * Gjenopprett originale postdata * / wp_reset_postdata (); // ikke glem dette // Vi gjør en enkel samtale vi ønsker ikke noe annet å løpe dø ();

Hvis det er tilfelle at du trenger noe mer komplisert som å slette et innlegg, må du alltid sjekke om brukerrettigheter, som jeg nevnte ved tigget om dette emnet. For eksempel, hvis du bare vil ha administratorer til å gjøre visse handlinger, kan du gjøre i skriptet ditt noe som:

hvis (current_user_can ('administrator')) wp_delete_post ($ postid, $ force_delete); 

Med alle tipsene ovenfor er du nå en mester i WordPress Ajax, og du kan utføre enhver handling du vil ha. Prøv å spille med ovennevnte og juster det etter dine behov. Jeg personlig liker å bruke json datatype og jeg gjør ekko json_encode () i stedet for å gjøre enkle ekko på mine skript, men det er en annen sak.

3. Filtre og handlinger

Formålet med denne delen er ikke å lære deg hvordan filtre og handlinger fungerer, det er gode opplæringsprogrammer rundt det emnet som forklarer det i detalj. Det jeg skal forklare deg her, er hvorfor du bør legge til filtre og handlinger på pluginene dine og vise deg noen eksempler for enkel forståelse.

Men først la oss gjøre en introduksjon til disse begrepene:

  • Hooks: En handlingskrog legges til et bestemt punkt i pluginet ditt, vanligvis rundt viktige handlinger (f.eks. Før innhold, etter innhold). Enhver bruker kan deretter "koble" til det med funksjoner for å få sin kode kjørt på det tidspunktet. Når en handlingskrok løper, vil alle funksjoner som er tilkoblet, eller "hekta", også løpe.
  • filtre: Et filterkrok er også plassert i plugin for at andre funksjoner skal bindes inn. På dette tilfellet filtre tillate data å bli manipulert eller modifisert før den brukes. Så du plasserer det vanligvis med variabler som du vil la brukerne manipulere.

Undersøk Plugin API for mer informasjon om action kroker og filtre.

Hvorfor jeg burde gjøre Plugin Extensible?

Det er enkelt: Fordi det gjør pluggen din bedre. På den måten vil utviklere og normale brukere alle sammen kunne utvide, tilpasse eller forbedre pluginet ditt utover det opprinnelige formål uten å påvirke kjernen av det. 

Ta for eksempel en eCommerce-plugin. På grunn av kroker og filtre kan du opprette nye plugins som knytter seg til den, som for eksempel nye betalingsgateways, fraktfunksjoner og mye mer.

Høres fint ut, men hvor skal jeg legge dem til på pluggen min?

Ikke bli gal å legge til handlinger og filtre overalt. I begynnelsen finner du dette litt vanskelig eller irriterende, så prøv å tenke som om du var en annen utvikler som ser på en ny plugin og spør deg selv "Trenger jeg her en handlingskrog?". Også en stor prosentandel av handling og filtre vil bli lagt til etter behov når du begynner å få støtteforespørsel (ja, du får dem alltid!) Eller tilbakemelding fra brukerne dine.

Som alt i livet, når dette blir en vane, vil du se veldig klart hvor du skal inkludere dem.

Noen anbefalinger for hvor du skal ta med filtre:

  • Når arrays er installert, er det et godt alternativ å legge til et filter for å la brukerne endre dem.
  • Når dataobjekter settes opp, skjer det samme. Du vil kanskje la brukere endre objektet før det blir brukt
  • Når datastrenger er satt opp, kan du legge til filtre for å la brukerne endre dem.

La oss bruke tilbakeringingsfunksjonen som brukes på denne artikkelen, for å se et eksempel på anbefalingene ovenfor. For å lage filterbare variabler i denne saken bruker vi apply_filters ()

funksjonen cool_ajax_example_callback () $ nonce = $ _POST ['nonce']; // Det første vi gjør er å sjekke nonce og drepe skriptet hvis det er feil hvis (! Wp_verify_nonce ($ nonce, 'return_posts')) die ('Wrong nonce!');  $ args = array ('post_type' => 'innlegg', 'post_status' => 'publiser', 'posts_per_page' => 5,); // Forespørselen $ the_query = ny WP_Query (apply_filters ('cool_ajax_query', $ args)); // Loop hvis ($ the_query-> have_posts ()) echo '
'; mens ($ the_query-> have_posts ()) $ the_query-> the_post (); ekko '

'. get_the_title (). '

'; ekko '
'; annet echo 'innlegg ikke funnet'; / * Gjenopprett originale postdata * / wp_reset_postdata (); // ikke glem dette // Vi gjør en enkel samtale vi ønsker ikke noe annet å løpe dø ();

Som du kan se, la jeg til et filter til $ args variabel som vil løpe rett før WP_Query kjører spørringen. Med et enkelt filter kan enhver bruker endre for eksempel hvor mange innlegg som er returnert.

funksjon wpt_alter_coolajax_query ($ args) $ args ['posts_per_page'] = 10; returner $ args;  add_filter ('cool_ajax_query', 'wpt_alter_coolajax_query');

Du kan bruke filtre i forskjellige scenarier, bare bruk fantasien din. For eksempel på min plugin WordPress Social Invitasjoner lar jeg brukerne endre popup-stilarket med et filter hvis de har en helt annen stil.

Eller ved denne anledningen når pluginet sender e-post, gir jeg muligheten til å endre "Fra e-post" det wp_mail () kommer til å bruke.

funksjon get_from_email () if (isset ($ this -> _ user_data)) return apply_filters ('wsi_from_email', $ this -> _ user_data-> user_email);  return apply_filters ('wsi_from_email', get_bloginfo ('admin_email')); 

Når det kommer til handlinger, endres det litt. Du vil legge til handlingskroker i følgende scenarier (ikke begrenset til):

  • før oppgaven blir utført,
  • etter at oppgaver er utført,
  • Under oppgaven blir det utført for å for eksempel utvide markup.

For å lage disse koblebare områdene bruker vi do_action () funksjon. La oss bruke dem i vårt eksempel.

funksjonen cool_ajax_example_callback () $ nonce = $ _POST ['nonce']; // Det første vi gjør er å sjekke nonce og drepe skriptet hvis det er feil hvis (! Wp_verify_nonce ($ nonce, 'return_posts')) dør ('Wrong nonce!'); $ args = array ('post_type' => 'innlegg', 'post_status' => 'publiser', 'posts_per_page' => 5,); // Forespørselen $ the_query = ny WP_Query (apply_filters ('cool_ajax_query', $ args)); // Loop hvis ($ the_query-> have_posts ()) // vi kjører kroken før løkken er proccesed do_action ('cool_ajax_before_loop', get_the_ID ()); ekko '
'; mens ($ the_query-> have_posts ()) $ the_query-> the_post (); // vi kjører kroken før tittelen skrives ut do_action ('cool_ajax_before_title', get_the_ID ()); ekko '

'. get_the_title (). '

'; // vi kjører kroken etter at tittelen er trykt do_action ('cool_ajax_after_title', get_the_ID ()); ekko '
'; // vi kjører kroken etter at løkken er proccesed do_action ('cool_ajax_after_loop', get_the_ID ()); annet echo 'innlegg ikke funnet'; / * Gjenopprett originale postdata * / wp_reset_postdata (); // ikke glem dette // Vi gjør en enkel samtale vi ønsker ikke noe annet å løpe dø ();

Som du kan se, går jeg over et argument til krokene med get_the_ID () . Enhver funksjon som kroker inn i vår handlingskrok, vil kunne bruke det argumentet. La oss se noen eksempler:

/ ** * Vis innlegg utvalgt bilde før tittel * / funksjon wpt_show_post_image ($ post_id) echo get_the_post_thumbnail ($ post_id, 'miniatyrbilde');  add_action ('cool_ajax_before_title', 'wpt_show_post_image'); / ** * Vis postkategorier etter tittel * / funksjon wpt_show_post_cats ($ post_id) echo get_the_category_list (",", $ post_id);  add_action ('cool_ajax_after_title', 'wpt_show_post_cats');

Også du kan bruke do_action () kroker for å kjøre andre handlinger i stedet for å legge til ny markering som eksempelet ovenfor. For eksempel, i WordPress Social Invitasjoner har jeg en handlingskrok som brenner hver gang en melding sendes. Deretter bruker myCRED plugin Jeg kan hekte handlingen med å gi poeng til brukeren som nettopp sendte meldingen.

Som du kan se å legge til kroker og filtre, vil ikke bare fordeler pluginet ditt, det vil også være til nytte for andre utviklere og brukere. Så hvorfor ikke du begynne å legge til noen filtre og handlinger rundt?

Konklusjon

I dag lærte vi å inkludere skript og stiler, hvordan Ajax kaller WordPress-måten og noen grunnleggende tips for filter og handlinger. Vi har allerede mye info for å utvikle en fin plugin, og jeg kan nå si at disse seriene er nær slutten.

 I den kommende og endelige artikkelen skal jeg snakke om internasjonalisering, feilsøking og dokumentasjon for å pakke opp ting på hva jeg synes er de beste tingene å vurdere mens du utvikler et plugin.