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!
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 ((''; // Lukk beholderen returnere $ faq; // Returner HTML. );% 1 $ s
% 2 $ s'), $ post-> post_title, wpautop ($ post-> post_content)); $ faq. = '
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:
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.
Ok, la oss få sprekke med dette.
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.
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:
$ filbane
- Banen til malfilen. Ikke glem at vi skal holde våre maler innenfor Utsikt mappe som vi opprettet tidligere$ teledata
- Eventuelle variabler som vi ønsker å ha tilgang til i malen (mye mer om dette senere)Kopier koden nedenfor til View.php:
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)
Da bruker vi PHPs utgangsbuffer. Det tillater oss å analysere en PHP-fil og lagre innholdet til en variabel
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 ...
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.
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 ()
vise()
Metodeklasse Slider offentlig statisk funksjon display () // Return HTML HERE.
/ * * 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.
Denne malen vil holde alle våre oppslag og tillate oss å få tilgang til dataene vi sende til det senere.
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.)
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->post_title?>
= $post->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.
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):
Utsikt
klasse eksisterer$ mal
Vis :: render ()
metode og send den til de to parametrene som trengsI 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.
vise()
Metoden i fullklasse 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.
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:
Slider
klasseklasse 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.
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:
Jeg ville være interessert i å vite hva du har funnet for denne teknikken, så vær så snill å dele i kommentarene :)