Forbedre arbeidsflyten din - skill deg fra din logikk!

I denne opplæringen skal jeg forklare en teknikk som lar deg bruke en malfil for alle dine HTML-behov! Ikke lenger trenger du å "ekko" strenger fra innsiden av dine funksjoner, eller bekymre deg for å slippe inn og ut av PHP bare for å utføre noen mark-up.

Jeg har brukt mange år på å bruke MVC-rammer (for eksempel Zend og i dag Laravel), der det er en god praksis å skille programmeringslogikken din (funksjoner eller metoder) fra "visningen" (den resulterende HTML-markeringen). Dette alltid fører til en mer vedlikeholdbar kodebase og det er faktisk mye lettere å skrive. Å ha denne bakgrunnen ba meg om å komme opp med en lignende løsning når jeg utvikler plugins for WordPress! Det er ikke noe for fancy - det er bare en liten "hjelper" som lar deg fjerne alle HTML-kodene og ubehagelig "rømme" fra dine funksjoner og plassere dem trygt i deres egen "mal" -fil.

Så, jeg håper denne opplæringen høres interessant ut for deg og uten videre, la oss begynne!


Trinn 1 Forstå hva vi skal forbedre

La oss sparke denne opplæringen ved å se på hva vi skal forbedre.

Det er veldig vanlig å se noe slikt i et plugin: (dette stykket kommer faktisk fra en av mine egne veiledninger på dette nettstedet: p)

 add_shortcode ('faq', funksjon () $ posts = get_posts (array (// Få FAQ tilpasset posttype 'numberposts' => 10, 'orderby' => 'menu_order', 'order' => 'ASC' 'post_type' => 'faq',)); $ faq = '
'; // Åpne beholderen foreach ($ innlegg som $ post) // Generer markeringen for hver Question $ faq. = Sprintf (('

% 1 $ s

'), $ post-> post_title, wpautop ($ post-> post_content)); $ faq. = '
'; // Lukk beholderen returnere $ faq; // Returner HTML. );

Hva er galt med det?

Vel ingenting, egentlig. Men det kan være renere, lettere å skalere og mer vedlikeholdsdyktig!

Kjører fra topp til bunn, vi kan se at alt innen en enkelt funksjon er vi:

  1. Spør databasen for innlegg av en bestemt type
  2. Tilordne en HTML-streng til en variabel
  3. Utfører en sløyfe og sammenføyer ytterligere markering til strengen
  4. Returnerer den oppbyggede strengen

Nå kan du godt se på dette og tenke "Big deal! Det er bare noen få linjer med HTML, hva er problemet?" I noen henseender er du godt innenfor dine rettigheter til å tenke slik. Men husk, det er bare 17 kodelinjer for øyeblikket - hva skjer når du utvider / forbedrer plugin? Hva skjer når pluginet ditt vokser til 50/100/1000 kodelinjer (eller mer!). Vil du fortsatt være glad for å ha HTML-strenge spredt rundt din funksjon på forskjellige steder? Hva skjer når du vil sende ut noen HTML som trenger litt vanskelig å "rømme" for å fungere skikkelig i PHP-koden din?

Forhåpentligvis kan du se at denne tilnærmingen til å lage og skrive ut HTML Markup kan bli svært problematisk! For ikke å nevne at det blir svært vanskelig å vedlikeholde og forbedre HTML når den bare er spredt rundt.

Så med alt dette i tankene har jeg tatt det på meg selv for å endre måten du tenker på å skrive ut HTML i WordPress. For alltid.


Trinn 2 Bygg Vis Renderer Plugin

Ok, la oss få sprekke med dette.

Lag filene og mappene

  1. Opprett en ny plugin-mappe som heter Utsikt
  2. Inne i den mappen, opprett pluginfilen view_renderer.php
  3. Lag nå en fil som heter View.php - Dette blir vår klasse

Inkluder klassen

Vårt plugin er enkelt, det inkluderer bare Utsikt klassen slik at vi kan bruke den i noen av våre andre plugins.

 / * view_renderer.php * / include ('View.php');

Ok, nå har vi tatt med Utsikt klassen, det er på tide å faktisk bygge den.

Visningsklassen

Her har vi en klasse kalt Utsikt med en enkelt statisk funksjon kalt gjengi (dette vil tillate oss å bruke syntaksen View :: render ($ template) fra hvor som helst i våre plugins) og det tar to parametere:

  1. $ filbane - Banen til malfilen. Ikke glem at vi skal holde våre maler innenfor Utsikt mappe som vi opprettet tidligere
  2. $ teledata - Eventuelle variabler som vi ønsker å ha tilgang til i malen (mye mer om dette senere)

Kopier koden nedenfor til View.php:

 

Så hva er det som skjer her?

  1. Først av alt sjekker vi om $ teledata varible har en verdi (dvs. sendte vi noe som skal brukes i malen?). Hvis det gjør, trekker vi ut innholdet (mer om dette senere)

  2. Da bruker vi PHPs utgangsbuffer. Det tillater oss å analysere en PHP-fil og lagre innholdet til en variabel

  3. Til slutt returnerer vi strengen

Merk: Ikke glem å aktivere plugin nå fra administrasjonspanelet

Virker ganske enkelt hei? Nøyaktig! Men mens det ser ut til å være en veldig enkel liten funksjon, gir det oss egentlig luksusen til å kunne skrive våre plugins på en super-organisert, skalerbar, vedlikeholdbar måte. Vær så snill, la meg demonstrere ...


Trinn 3 En Real-World Eksempel

La oss lage en enkel plugin som heter Slider

** Merk: Dette er kun for demonstrasjonsformål. Du er velkommen til å bruke ditt eget plugin her.

  1. Opprett en mappe som heter Slider
  2. I den mappen, opprett en fil som heter Slider.php
  3. Kopier koden nedenfor til Slider.php
 

Legg til en kortkode

OK, nå skal vi legge til en kortkode som henter de siste 5 innleggene og viser dem i en liste med tittel og innhold. (For korthetens skyld legger vi til plugin-klassen og handlingene i samme pluginfil, men vær så snill å ikke gjøre dette i "virkeligheten": p)

 / ** * Legg til kortnummeret (PHP 5.3 og over) * / add_shortcode ('skyvekontroll', funksjon () return Slider :: display (););

Det vil tillate oss å bare bruke [Skyve] i hvilket som helst innlegg / side og det vil utgjøre resultatet av Slider :: display ()

Legg til gliderklassen & vise() Metode

 klasse Slider offentlig statisk funksjon display () // Return HTML HERE. 

Få de siste 5 innleggene.

 / * * Få de siste 5 innleggene * / offentlig statisk funksjonsvisning () $ posts = get_posts (array ('numberposts' => 5)); 

Nå har vi en rekke av post objekter, og vi er klare til å bygge opp våre HTML ved looping gjennom dem. Men vi skal ikke bare begynne å sette inn HTML-strenger i vår funksjon her! I stedet skal vi passere rekke objektene til en malfil og få all HTML generert ut av skadeens måte.

Opprett mal

  1. Opprett en mappe som heter maler
  2. Inne i den mappen, opprett en fil som heter 01.template.php

Denne malen vil holde alle våre oppslag og tillate oss å få tilgang til dataene vi sende til det senere.

Sende data til malen

Hver gang vi vil bruke noen variabler i våre maler, kan vi bare sende dem ved å sette en verdi i $ teledata array. Alle som er kjent med bruk av MVC-rammer vil føle seg veldig hjemme med denne tilnærmingen.

 $ viewData = array ('posts' => $ innlegg);

Arrayet nøkkel her ('innlegg') er viktig fordi det er hvordan vi refererer til dataene fra malen. (Du kan ringe dette uansett hva du liker, men hold deg til noe som gir mening.)

Bygg malen

Ok, så vi har sett på hvordan du henter de siste 5 innleggene og hvordan du sender det utvalgte objekter til malen, det er nå på tide å kutte ut malfilen.

 
  • post_title?>

    post_content?>

Ah! Hvor fint føles det å ha alt det oppslaget i sin egen separate fil, borte fra vår datainnhenting og programmeringslogikk? Flott, jeg vet! Den viktigste delen av denne tilnærmingen er at vi bare får tilgang til data fra variabler i malen. Alle 'logikken' bør gjøres innenfor metoden som kaller malen. Dette fører til en veldig fin arbeidsflyt ettersom du har fullstendig separasjon av bekymringer.

Tenk deg hvor lett det vil være nå når du er klar til å bygge på denne plugin. Ikke flere sammenknippede strenge og rømme tegn i funksjoner.

Tilbakestiller den returnerte malen

Ok, vi har sett alle komponentene, la oss se hvordan alt passer sammen slik at vi kan lage en mal og få en streng tilbake (det kan vi da komme tilbake til vår kortkode):

  1. Først må vi lagre en referanse til vår mal i en statisk egenskap
  2. Da må vi sjekke at Utsikt klasse eksisterer
  3. Deretter genererer vi hele banen til vår malfil ved å ta en referanse til gjeldende plugin-katalog og sammenkoble vår statiske egenskap $ mal
  4. Til slutt, vi kaller vår Vis :: render () metode og send den til de to parametrene som trengs

I dette tilfellet, vi komme tilbake Resultatet av den gjengitte mal fordi det er slik kortkoder arbeid. Men hvis du skulle trenge det ekko Resultatene i stedet (for eksempel når du oppretter en Admin-side, forventer tilbakeringingen at utskriften din skal skrives ut direkte), og deretter bare erstatte komme tilbake med ekko.

De vise() Metoden i full

 klasse Slider static $ template = '/templates/01.template.php'; offentlig statisk funksjon display () if (class_exists ('View')) // Få de siste 5 innleggene $ posts = get_posts (array ('numberposts' => 5)); // Sett visning Data $ viewData = array ('posts' => $ innlegg); // Hent hele banen til malfilen. $ templatePath = dirname (__FILE__). statisk :: $ mal; // Returner gjengitt HTML-retur: Vis: gjengivelse ($ templatePath, $ viewData);  else return "Du prøver å lage en mal, men vi kan ikke finne View Class"; 

Jeg håper du kan sette pris på organisasjonsnivået denne tilnærmingen vil ha råd til deg! Nå din vise funksjonen er bare ansvarlig for å samle inn dataene den trenger og returnerer resultatet av den gjengitte mal.


Tar det videre

Vårt eksempel ovenfor er omtrent så grunnleggende som det blir. Likevel er det fortsatt en betydelig forbedret arbeidsflyt. La oss nå se på et annet eksempel som viser hvor nyttig det egentlig kan være.

Si for eksempel at pluginet ditt bruker en egendefinert meta-boks. For å gjøre det, må vi:

  1. Legg til en konstruktors funksjon i Slider klasse
  2. Legg til en metode for å legge til metaboxet for hvert innlegg
  3. Legg til en tilbakeringingsmetode for å gjengi HTML for meta-boksen
  4. Legg til riktig krok i pluginfilen for å ordne klassen bare når du legger til / redigerer innlegg
  5. Til slutt vil vi legge til en malfil som vi gjorde tidligere, og legge den til som en eiendom i starten av klassen
 klasse Slider static $ metaBox = '/templates/metabox.template.php'; offentlig funksjon __construct () add_action ('add_meta_boxes', array ($ dette, 'add_some_meta_box')));  / ** * Legger til metaboksbeholderen * / offentlig funksjon add_some_meta_box () add_meta_box ('some_meta_box_name', 'Noen Meta Box Headline', array ($ dette, 'render_meta_box_content'), 'post', 'advanced' høyt ");  / ** * Render Meta Box innhold * / offentlig funksjon render_meta_box_content () / ** Fra Codex ** / echo '

TEST UTGANG - dette blir gjengitt inne i meta-boksen.

'; // class // legg til handlingskrok-funksjonen call_Slider () returner ny skyveknapp (); hvis (is_admin ()) add_action ('last-post.php', 'call_Slider');

Ta en titt på render_meta_box_content metode der. Det er den perfekte muligheten til å bruke View Renderer! Tenk deg et mer realistisk eksempel som dette:

 / ** * Render Meta Box innhold * / offentlig funksjon render_meta_box_content ($ post) $ name = get_post_meta ($ post-> ID, "name"); $ fieldName = statisk :: $ fieldName; ekko '

Navnet ditt:

'; ekko ''; ekko ''; ekko '';

Urg! Jo, det blir jobben gjort, men det er så vanskelig å gjøre det på denne måten! Hva med å bruke vår View Renderer i stedet.

 / ** * Render Meta Box innhold * / offentlig funksjon render_meta_box_content ($ post) $ viewData = array ('name' => get_post_meta ($ post-> ID, 'navn'), 'field' => static :: $ feltnavn ); $ templatePath = dirname (__FILE__). statisk :: $ Metabox; ekkovisning :: gjengivelse ($ templatePath, $ viewData); 

Og i malfilen:

 

Navnet ditt:

Det kan bare virke som en svært liten fordel i dette eksemplet. Men tro på meg, hvis du holder bekymringene dine skilt slik som dette, blir du en langt bedre WordPress-utvikler ganske raskt.


Konklusjon

Jeg tror nå at du sikkert har en god forståelse av hva vi prøver å oppnå her, og jeg oppfordrer deg til å prøve å bruke denne teknikken når du bygger plugins i fremtiden. Forhåpentligvis finner du "adskillelse av bekymringer" for å være til nytte for deg.

Tutorial Notes:

  • Selv om vi gjorde View Renderer til et plugin av seg selv, kan du ganske enkelt bare legge det til eksisterende plugins i stedet. Dette vil fjerne det ekstra trinnet med å sørge for at pluginet er aktivert før du bruker det hvor som helst.
  • Du er ikke begrenset til brukstilstandene som er forklart i denne opplæringen, den kan brukes uansett hvor du vanligvis sender ut HTML (Hva med å bruke en malfil for å utføre noe "in-line" JavaScript? Eller hva med noen spesifikke CSS-regler basert på alternativer hentet fra databasen?)

Jeg ville være interessert i å vite hva du har funnet for denne teknikken, så vær så snill å dele i kommentarene :)