Opprette egendefinerte WordPress-administrasjonssider, del 4

Når vi starter den endelige artikkelen i serien om å skape egendefinerte WordPress-administrasjonssider i WordPress, synes jeg det er viktig å gjenta at dette ikke er ment å si at vi bør kringgå Innstillinger API (eller noen av de innfødte APIene). 

Faktisk har hver API sitt sted, og vi bruker åpenbart mange av dem gjennom denne koden. Men det er sannsynlig at det er tider hvor du jobber med en tilpasset plugin eller et tilpasset program, og du må kunne implementere litt av din egen tilpassede validering, serialisering, ruting og så videre..

Og det er det vi har gjort gjennom hele denne serien. Så når vi går videre med å fullføre pluginet vårt, vil jeg være sikker på at du forstår at jeg ikke fortaler å omgå noen av de innfødte APIene. Jeg fortaler å bruke hvilke APIer som er tilgjengelige for kravene til prosjektet ditt.

For din anmeldelse

På dette punktet antar jeg at du er opptatt av de forrige artiklene. Hvis ikke, vil du sannsynligvis ha det vanskelig å forstå hvor vi kommer fra, og hvorfor vi gjør noen av de beslutningene vi gjør som det gjelder kode.

Videre vil du gå glipp av noen av prinsippene vi tidligere har diskutert. Kort sagt, jeg anbefaler å fange opp og deretter tilbake til denne artikkelen.

Før vi begynner

Med det sagt (og snakker om krav), er det bare noen få flere ting vi trenger å pakke opp som det gjelder denne plugin.

Spesielt må vi:

• hente informasjonen fra databasen
• bekreft informasjonen
• vis det på instrumentbrettet
• vis informasjonen på fronten

Heldigvis har flertallet av arbeidet blitt gjort for oss. Vi har all informasjonen vi trenger i databasen. På dette punktet handler det om å introdusere funksjonalitet som vil gjøre noe med dataene.

Som vanlig antar jeg at du har den nyeste versjonen av kildekoden, og du er klar til å fortsette med denne serien og legger til den gjenværende bit av kode. 

Med det sagt, la oss komme i gang.

Fullfører plugin

Før vi begynner å skrive kode, vil jeg gjøre det klart at koden vi skal skrive er grei, men det er et nivå av refactoring som vi kanskje må presentere når vi kommer til å gjøre informasjonen tilgjengelig på begge back-end og front-end.

Det er en god ting, skjønt.

Ikke bare vil det gi oss sjansen til å tenke kritisk på organisasjonen av koden vår, men det vil også avsløre oss for noen andre objektorienterte teknikker som vi ikke har sett i hele opplæringsserien så langt.

Med det for øye, la oss jobbe for å hente informasjonen fra databasen.

Hent informasjon fra databasen

Å ta tak i informasjonen fra databasen er en enkel prosess. Siden vi tidligere har jobbet med funksjoner som update_option, Dette burde være veldig enkelt. 

Vi skal jobbe med get_option. Det krever bare et enkelt argument, og det er ID eller nøkkel som vi brukte til å lagre informasjonen. I vårt tilfelle er det det tutsplus-custom-data. Hvis du vil bli kreativ, kan du passere et valgfritt andre argument som vil bli returnert dersom informasjonen ikke blir funnet.

For å vise hvordan dette kan brukes, får jeg funksjonen tilbake en tom streng slik vi har noe gyldig for visning til brukeren (selv om det ikke er noe). Kodestykket for å gjøre dette ser slik ut:

Men dette reiser to spørsmål:
 
Hvor går dette (spesielt hvis vi skal gjengi dette på to steder i pluginet)?
 
Skal vi ikke validere denne informasjonen?
 
Vi ser på det første spørsmålet litt senere i opplæringen. La oss først snakke om validering.
Bekreft informasjonen
Det er mye som kan sies om validering i WordPress. Men for å holde denne opplæringen så enkel som mulig, skal vi snakke om inntast validering. Tross alt har vi å gjøre med brukerinngang via en inngang element, så det gir mening.
Du kan lese alt om det i Codex, men inntast validering er ofte definert som følgende:
Data validering er prosessen med å sikre at et program opererer på rene, korrekte og nyttige data.
I den siste artikkelen dekket vi temaet sanitisering, som i utgangspunktet sørger for at dataene er rene før de blir satt inn i databasen. På samme måte sikrer validering at den er ren, sikker og lesbar for brukerne.
Til det formål er det ikke nok bare å hente informasjonen fra databasen. Vi må også validere det. I tilfelle av plugin er dataene enkle nok til at det kan virke som overkill for å validere det; Formålet med øvelsen er imidlertid å bidra til å utvikle tankegangen for hvordan vi trenger å gå om sanitizing, lagring, henting, validering og visning av data.
Valideringsteknikker
Og akkurat som tilfellet er med sanitering, tilbyr WordPress noen funksjoner som gjør validering enkelt, spesielt når det gjelder inngangsvalidering. I denne situasjonen kan vi være så aggressive som vi liker. 
I vårt tilfelle kan det være nok bare å bruke esc_attr når du gjør alternativene. Hvis vi har tillatt brukere å skrive inn noen type HTML, så kan vi kanskje bruke wp_kses.
Sistnevnte funksjon kan kreve en opplæring alt i seg selv, spesielt hvis du er ny for WordPress, så vi skal holde fast med den tidligere til våre formål.
deserialization
Tidligere i prosjektet opprettet vi en klasse spesielt for å lagre informasjon til databasen. Vi kalte denne klassen Serializer. For de som ikke husker akkurat hva det gjør:
 
Klassen definerer en funksjon som brenner på admin_post krok og lagrer informasjonen som sendes til serveren.
 
Funksjonen verifiserer at informasjonen er trygt å lagre og brukeren har tillatelse til å lagre i databasen.
 
Funksjonen sanitiserer dataene og skriver den til databasen.
 
Men vi vil ikke overbelaste den klassen med et ansvar som ikke gir mening. Og siden vi skal vise denne informasjonen på både opsjonssiden og forsiden av nettstedet, ville det være grunn til at vi har en klasse for å deserialisere verdien og gjøre den tilgjengelig for hele WordPress-applikasjonen.
Så i roten til plugin-katalogen, opprett en delt katalog og legg til en fil som heter klasse deserializer.php.
Deretter vil vi at vår kode skal settes opp slik at den:
 
er basert på objektorienterte prinsipper
 
henter informasjonen som den blir spurt om
 
validerer informasjonen
 
returnerer den til den som ringer
 
Til det formål kan det første skjelettet i klassen se slik ut:
Det er enkelt å være sikker på. Vi legger til flere koden til det gjennom hele denne opplæringen, men husk prinsippet om enkeltansvar, og dette er en klasse som må brukes mellom to deler av WordPress-programmet.
Legg merke til at i koden ovenfor har vi definert tre funksjoner. La oss diskutere hva hver enkelt vil gjøre:
 get_value vil bruke den innkommende alternativtasten som i vårt tilfelle er tutsplus-custom-data, og returnerer verdien til den som ringer. I henhold til WordPress Coding Standards må vi bruke "sen escape" for å sikre at vi korrekt validerer informasjonen. Vi ser dette spille av øyeblikkelig.
Med det sagt, la oss gå videre og stub ut funksjonene. Jeg vil også gi PHP DocBlocks å forklare hva hver funksjon gjør.
På dette tidspunktet må ovennevnte kode være lett å følge med punktpunktene ovenfor og kommentarene i koden.
Vis det på siden Alternativer
For å vise dette på opsjonssiden, må vi revidere måten vi instantierer Submenu_Page i custom-admin-settings.php fil. Spesielt må vi instantiere deserialiseringen og sende den inn i konstruktøren til Submenu_Page.
Først må vi inkludere filen. Dette kan skje like etter at vi sjekker for å se om hoved pluginfilen nås direkte:
Koden i hovedfunksjonen til roten til pluginet skal nå se slik ut:
i det(); $ deserializer = ny deserializer (); $ plugin = ny undermeny (ny Submenu_Page ($ deserializer)); $ Plugin-> init (); 
Og så konstruktøren for Submenu_Page skal se slik ut:
deserializer = $ deserializer;  
Herfra kan vi takle alternativsiden. Vi oppdaterer bare verdi Tilordne ved å ringe til funksjonen i deserialiseringen. Husk, siden vi ubetinget henter verdien og til slutt returnerer en tom streng hvis ingenting eksisterer, bør det fungere helt fint.
 Hvilken melding vil du vise over hvert innlegg? 
  
Og med det, bør du kunne lagre og hente verdien på opsjonssiden.
Vis det på forsiden
Vi er nesten ferdige. Det siste vi må gjøre er å sette opp pluginet for å vise den egendefinerte meldingen på forsiden. Spesielt ønsker vi å vise hva brukeren har skrevet inn på enkelt innleggssiden (versus en arkivside eller en annen type side) og å gjøre det over hvert innlegg.
Dette betyr at vi skal gjøre følgende:
 
Sett opp en funksjon som vil bruke the_content hook.
 
Les verdien ved hjelp av vår deserializer.
 
Forbedre verdien før innholdet (kanskje i eget element).
 
Heldigvis er det ikke at mye arbeid, spesielt fordi vi har mesteparten av arbeidet som vi trenger for å komme i gang. Likevel må vi opprette et område av pluginet som er spesielt ansvarlig for håndtering av fronten på nettstedet.
Til slutt skal du opprette en offentlig katalog i roten til plugin katalogen din og legg til klasse-innhold-messenger.php.
I klassen må vi definere en konstruktør som vil akseptere deserialiseringen som en avhengighet. Konstruktøren (og nødvendig eiendom) skal se slik ut:
deserializer = $ deserializer; 
Da må vi lage en i det funksjon som vil registrere en intern funksjon (som vi vil ringe vise) for å gjøre innholdet sammen med den nye meldingen.
Deretter må vi oppdatere hoved pluginfilen slik at den instantiates vår nye klasse og sender deserialiseringen til konstruktøren. Da vil det initialisere klassen.
Først vil vi inkludere det:
Da vil vi instantiere det:
i det(); 
Herfra bør vi være klare til å gå. Pass på at du har angitt en verdi på alternativsiden. Lagre arbeidet ditt og sjekk ut en enkelt innleggsside på nettstedet ditt. Det skal se slik ut:
Hvis ikke, sammenlign deretter koden med hva som er over (eller hva som er vedlagt) og sørg for at du har satt opp alle klassene, funksjonene og krokene ordentlig.
Et ord om synspunkter og avhengigheter
Selv om vi har snakket om enkeltansvarsprinsippet gjennom hele denne serien, har vi ikke faktisk snakket mye om mer avanserte emner som vi kunne bruke for å gjøre koden enda renere og følge bedre praksis.
Noen av disse emnene inkluderer ting som PHP autoloading og ting som Dependency Injection. Jeg har ikke snakket om disse fordi de er utenfor kjernefokuset og det primære punktet denne serien har som mål å lære.
Avhengig av hvordan denne serien er mottatt, vurderer jeg å lage noen opplæringsprogrammer spesifikt om disse emnene.
Konklusjon
Og med det konkluderer vi serien om å skape tilpassede administrasjons sider. Jeg håper at i hele denne serien har du lært noen ting utover den vanlige måten å opprette administrasjonssider på.
I tillegg håper jeg at du har sett hvordan du kan bruke noen programvareutviklingsmetoder i ditt daglige arbeid med WordPress. Videre håper jeg også diskusjonen om synspunkter og avhengigheter har gitt interesse for mer avanserte emner. Dette er ting jeg håper å dekke i fremtidige opplæringsprogrammer også.
Som vanlig kan du se mine kurs og opplæringsprogrammer på min profilside, og du kan følge meg på bloggen min og / eller Twitter på @tommcfarlin hvor jeg snakker om ulike programvareutviklingspraksis og hvordan vi kan bruke dem i WordPress.
Ikke glem å laste ned koden på sidepanelet i dette innlegget, se gjennom det, lek med det, og se hva du kan gjøre for å utvide det og legge til din egen funksjonalitet. Som vanlig, ikke nøl med å kontakte meg via kommentarene om opplæringen.
ressurser
 
Innstillings-API
 
Den komplette guiden til Innstillinger API
 
update_option
 
get_option
 
Inngangsvalidering
 
Datavalidering
 
esc_attr
 
wp_kses
 
admin_post
 
Enkelt ansvar prinsipp
 
Sen Escaping
 



		
			
	   
	




Kode