Opprette egendefinerte WordPress-administrasjonssider, del 3

I denne serien har vi sett på hvordan du oppretter egendefinerte administrasjons sider i WordPress uten bruk av Innstillinger API. Dette er ikke å si at Innstillings-API ikke er nyttig (fordi det er!), Men det kan være ganger når vi trenger å implementere noen tilpassede funksjoner eller mer spesialiserte implementeringer av funksjoner som de tilgjengelige APIene ikke har råd til.

I tillegg ser vi på noen av de viktigste prinsippene for programvareutvikling, for eksempel prinsippet om enkeltansvar, og bruker dem til vårt arbeid. 

Hvis du bare er med i serien, anbefaler jeg at du leser de forrige innleggene slik at du er kjent med det vi har gjort opp til dette punktet, og du kan forstå hvorfor vi gjør noen av de avgjørelsene vi er gjør når du skriver vår kode.

En rask gjennomgang

Selv om jeg ikke kan oppsummere alt vi har dekket så langt i serien, kan jeg forsikre meg om at jeg markerer de viktige punktene.

• Vi har introdusert kjerneplugin og lagt til en undermenyelement og tilleggsside for plugin-modulen i WordPress dashboard.
• Vi har diskutert enkeltansvarsprinsippet og rollen det spiller i utviklingen vår.
• En eneste inngang elementet er lagt til som vil akseptere brukerens innspill.
• Vi har lagt til en ikke-verdi for siden, men vi har ikke gjort noe med det.

Med alt det som er sagt antar jeg at du har den nyeste versjonen av kildekoden (som er tilgjengelig som et vedlegg i forrige artikkel), og du er klar til å bevege deg fremover.

Før vi begynner

Som med de andre artiklene antar jeg at du har et lokalt WordPress utviklingsmiljø satt opp på maskinen din. 

Videre antar jeg at du har den nyeste versjonen av kildekoden, og du er klar til å fortsette å bygge på toppen av det, eller du er komfortabel å lese gjennom koden vi har her og implementere den når du har mer tid.

Til slutt vil vi gå trinnvis gjennom hver bit kode. Først skal jeg snakke om hva vi skal gjøre, så viser jeg koden, og så skal jeg forklare hva det er som koden gjør, så er det ingenting igjen som kan være forvirrende.

Hvis du imidlertid finner deg forvirret om noe i koden og veiledningen ikke gjør en god jobb med å forklare hva som skjer, vennligst legg igjen en kommentar, og jeg vil være sikker på å følge opp med deg.

La oss komme i gang.

Implementere nye funksjoner

I den siste artikkelen sluttet vi med et plugin som utseende som om det gjør noe, men faktisk ikke lagrer noe i databasen, enn si, hent alt fra databasen.

Kort sagt, vi har et plugin som ser funksjonelt ut, men det er det ikke. Og det er her vi skal hente denne opplæringen.

Spesielt skal vi takle følgende emner:

• Vi skal verifisere nonce-verdien som vi opprettet og definert i den forrige veiledningen for å få en forståelse av hvordan en komponent av WordPress-sikkerhet fungerer.
• Vi bekrefter at den eksisterende brukeren har tillatelse til å faktisk sende inn informasjonen (og forhindre at de gjør det, hvis de ikke gjør det).
• Hvis innleveringen er sikker og brukeren har tillatelse, vil vi sanitere informasjonen for å sikre at ingen skadelig innhold kommer inn i databasen.

Med det som vår veikart, er vi klare til å hoppe tilbake til koden og fortsette å jobbe på plugin.

Sikkerhet

Tilbakekall fra det forrige innlegget tok vi fordel av WordPress API-funksjonen wp_nonce_field. Denne spesielle funksjonen gjør følgende:

Non-feltet brukes til å validere at innholdet i skjemaforespørselen kom fra det nåværende nettstedet og ikke et annet sted. En nonce tilbyr ikke absolutt beskyttelse, men bør beskytte mot de fleste tilfeller. Det er veldig viktig å bruke nonce felt i skjemaer.

Hvis du forsøker å lagre alternativsiden, vil du sannsynligvis bli presentert med en hvit skjerm. Det er aldri bra, men det er det vi forventer gitt den nåværende tilstanden til pluginet vårt.

Vi må presentere en funksjon som vil hekte inn i en av de tilgjengelige WordPress-krokene, og vil kontrollere om nonce-verdien er gyldig. Hvis det er gyldig, så vil det la oss fortsette med å lagre informasjonen; ellers bør det ikke la oss fortsette.

Siden vi jobber med å skape en tilpasset administrasjonsside, trenger vi en annen krok enn det vi kan bruke til å bruke i slike situasjoner. I dette eksemplet skal vi bruke admin_post krok. 

Branner på en autentisert admin post forespørsel der ingen handling ble levert.

Husk fra våre tidligere diskusjoner, at vi ikke vil overbelaste våre klasser med mer ansvar enn det som er nødvendig. Husk at spørsmålet om at vi hele tiden må spørre oss selv er: "Hvilken grunn skulle denne klassen måtte forandre seg?" 

Akkurat nå har vi ikke en klasse som kan administrere lagringsalternativer. Så la oss introdusere en. I administrasjonsmappen til pluginet la vi opprette en Serializer klasse. Dette vil være ansvarlig for å spare verdien av alternativene våre.

Som du kan se, har jeg kalt filen min klasse serializer.php. Vi vet fra erfaring og fra koden ovenfor at den kommer til å trenge å hekte seg inn i admin_post krok nevnt ovenfor, og vi vet at vi skal ha en funksjon som er ansvarlig for å lagre informasjonen.

La oss definere de nå.

Selvfølgelig er det fortsatt jobb å gjøre (faktisk har vi ikke engang instansiert denne klassen!), Men koden ovenfor kan være nok til å se hvor vi er på vei.
En rask samtale om avhengigheter
Før vi legger til noen funksjonalitet, la oss gå videre og sette opp dette når vår plugin først laster. Først returner du custom-admin-settings.php. Nå, på dette tidspunktet, må vi spørre oss selv om noen av våre eksisterende klasser skal ha Serializer som en avhengighet.
Jeg tror at en sak kan gjøres at Submenu_Page bør ha en referanse til serializer siden siden har alternativene å lagre.
Alternativt er det også mulig å legge denne filen helt fra hverandre og få den tilgjengelig for et annet mønster. Hvis vi skulle gjøre det, ville vi være divergerende fra emnet ved hånden. Selv om jeg synes det er viktig, er det utenfor omfanget av det vi satser på å gjøre.
Så la oss instansere Serializer klassen, initialiser den, og send den deretter til konstruktøren på undermenysiden. Koden i pluginens bootstrap-fil skal nå se slik ut:
i det(); $ plugin = ny undermeny (ny Submenu_Page ($ serializer)); $ Plugin-> init (); 
Med det er vi klare til å fortsette å lagre alternativene våre.
Tilbake til utvikling
La oss gå tilbake til Serializer. Nå som vi har koblet den til resten av pluginet, er det på tide å skrive noen kode, slik som i kommentaren antyder, la oss verifisere den ikke-verdi som vi har opprettet på fronten.
Heldigvis gjør WordPress dette enkelt gjennom en innebygd API-funksjon: wp_verify_nonce. Denne funksjonen godtar to argumenter:
 
Handlingen
 
Navnet
 
Hvis du husker fra forrige artikkel, brukte vi Acme-innstillinger-save som vår handling og Acme-custom-melding som vår nonce verdi. For å validere det, må vi kontrollere at det eksisterer i $ _POST samling og at den passerer WordPress innfødte sjekker. 
For å gjøre dette, liker jeg å lage en privat metode som lar meg inkapslere denne logikken til en funksjon som jeg kan bruke i lagre funksjonen vi har definert ovenfor.
Når jeg har gjort det, kan jeg inkludere en samtale til denne funksjonen som gjør at vi kan sjekke innleveringens gyldighet og enten gå ut av rutinen eller fortsette til neste sjekk (som vi kommer til å få til en kort stund).
Merk at bare å returnere falsk i denne betingede er ikke en passende måte å håndtere dette på. I stedet vil det være renere å introdusere en feilmelding som vises på WordPress dashboard. Dette er noe vi skal se på i en fremtidig opplæring. 
For øyeblikket er vi imidlertid primært opptatt av å sørge for at vi kan sende inn data med hell. Dette bringer oss til neste del av koden vår.
Tillatelse
Selv om nummeret som brukes en gang (eller nonce) validering sjekket ut, er det fortsatt en ting vi må sjekke: Vi må sørge for at den nåværende brukeren har tillatelse til å lagre dataene.
For våre formål vil vi sørge for at den nåværende brukeren er en administrator. For å gjøre dette kan vi se på evnen til den nåværende brukeren (du kan se denne siden gir en referanse for hver rolle og tilhørende evner).
Legg merke til at en av administrasjonens evner er å administrere alternativer. Vi kan nå bruke WordPress API-funksjonen current_user_can for å se om den nåværende brukeren kan lagre alternativene på denne siden.
Men først løfter dette et spørsmål: Hvis brukeren ikke kan lagre alternativer, hvorfor burde de få lov til å se siden i utgangspunktet?
Hvis du husker fra tidligere i serien, skrev vi følgende bit kode:
submenu_page, 'render')); 
Dette sikrer at opsjonssiden er Bare tilgjengelig for administratorer; Vi vil imidlertid være ekstra forsiktige og ta en sjekk for dette under vår serialiseringsprosess også.
Nå kan vi oppdatere betingelsene der vi også sjekker nonce-verdien også for å sjekke gjeldende brukerens tillatelse:
has_valid_nonce () && current_user_can ('manage_options'))) // TODO: Vis en feilmelding.  // Hvis ovennevnte er gyldige, lagre alternativet. 
Nå som vi har kode på plass for å sikre at nonce-verdien er satt og at den nåværende brukeren kan lagre verdien, kan vi gå videre med sanitisering.
Husk, vi vil Gå tilbake til stedet der det står at vi må vise en feilmelding. Men det er ikke i denne opplæringen.
sanitization
"Men vent," sier du. "Jeg trodde vi var klar til å lagre muligheten!" Vi er, men før vi kan gjøre det, må vi gå gjennom en saneringsprosess. Kort sagt, sanitisering er ideen om å sikre at dataene er rene, trygge og, ahem, sanitær for databasen.
Enkelt sagt, forhindrer det ondsinnede brukere fra å sette inn informasjon i databasen som i siste instans kunne påvirke nettstedet vårt.
Heldigvis gir WordPress en fin hjelperfunksjon som gjør at vi kan sørge for at dette er så enkelt som mulig. For de som er interessert, kan du lese alt om validering og sanitizing data (selv om vi ser på validering i neste opplæring).
I vår kode skal vi bruke sanitize_text_field (som koblet over). Denne funksjonen gjør følgende:
 
Sjekker for ugyldig UTF-8
 
Konverterer single '<' characters to entities
 
Striper alle tagger
 
Fjerner linjeskift, faner og ekstra hvitt plass
 
Strips oktetter
 
Ganske fint å ha dette tilgjengelig, ikke sant? La oss sette dette på jobb. For å gjøre det, finn det lagre funksjonen som vi har jobbet med, og oppdater den slik at den ser slik ut:
has_valid_nonce () && current_user_can ('manage_options'))) // TODO: Vis en feilmelding.  // Hvis ovennevnte er gyldige, rydde og lagre alternativet. hvis (null! == wp_unslash ($ _POST ['acme-melding'])) $ value = sanitize_text_field ($ _POST ['acme-message']); update_option ('tutsplus-custom-data', $ verdi); 
Legg merke til at vi leser innspillet fra $ _POST innsamling, sanering det, og deretter lagre resultatet i en egen variabel. Deretter blir den variabelen skrevet til databasen ved hjelp av update_option funksjon. 
For denne artikkelen velger jeg å bruke nøkkelen tutsplus-custom-data. Uansett hva du bruker, er det viktig at det er prefiks med noe unikt slik at et annet plugin eller tema ikke overskriver alternativet og du ikke overskriver et eksisterende alternativ.
Til slutt må vi omdirigere tilbake til alternativsiden. Siden vi ikke bruker en innebygd API, må vi skrive en funksjon for å gjøre dette for oss. Heldigvis er det veldig enkelt. 
Først oppretter du en funksjon som kalles omadressering, og sørger for at den ser slik ut:
Koden ovenfor bør være selvforklarende, men for å sørge for at det er klart, gjør det følgende:
 
Det kontrollerer at en privat WordPress-verdi er til stede i $ _POST samling. Hvis den ikke er angitt, vil den sette den lik WordPress-innloggingsadressen. Dette vil tvinge folk til påloggingssiden dersom henvisningsadressen ikke er angitt; Det er imidlertid ingen grunn til at det ikke burde være.
 
Deretter tar vi henvisningen og sanitiserer dataene. Dette er noe som kodingsstandardene krever, og det sørger for at dataene er rene.
 
Endelig initierer vi en wp_safe_redirect til nettadressen slik at vi blir returnert til valgsiden.
 
Når alt dette er gjort, legg dette til som den siste linjen i lagre funksjonen ovenfor. Den endelige versjonen av koden skal se slik ut:
has_valid_nonce () && current_user_can ('manage_options'))) // TODO: Vis en feilmelding.  // Hvis ovennevnte er gyldige, rydde og lagre alternativet. hvis (null! == wp_unslash ($ _POST ['acme-melding'])) $ value = sanitize_text_field ($ _POST ['acme-message']); update_option ('tutsplus-custom-data', $ verdi);  $ this-> omdirigere ();  / ** * Bestemmer om ikke-variabelen som er knyttet til opsjonssiden, er angitt * og er gyldig. * * @access privat * * @return boolean False hvis feltet ikke er satt eller nonce-verdien er ugyldig; * ellers, sant. * / privat funksjon har_valid_nonce () // Hvis feltet ikke er engang i $ _POST, er det ugyldig. hvis (! isset ($ _POST ['acme-custom-message'])) // Input var ok. returner falsk;  $ field = wp_unslash ($ _POST ['acme-custom-message']); $ action = 'acme-settings-save'; returnere wp_verify_nonce ($ felt, $ action);  / ** * Omdirigere til siden vi kom fra (som alltid skal være * admin-siden. Hvis henvisningen ikke er angitt, omdirigerer vi brukeren til * påloggingssiden. * * @Access privat * / privat funksjonen omdirigering () // For å gjøre kodingsstandarderene lykkelige må vi initialisere dette. hvis (! isset ($ _POST ['_ wp_http_referer'])) // Inngang var ok. $ _POST ['_ wp_http_referer'] = wp_login_url (); // Sanitiser verdien av $ _POST-samlingen for kodingsstandardene. $ Url = sanitize_text_field (wp_unslash ($ _POST ['_wp_http_referer']) // Inngang var okay.); // Endre omdirigere tilbake til admin side. wp_safe_redirect (urldecode ($ url)); avslutte; 
Her er saken: Vi har sikkerhet, sanitisering, serialisering og omdirigering på plass. Men vi viser ikke feilmeldinger, og vi henter ikke dataene. 
Det er her vi skal hente med neste opplæring.
Konklusjon
På dette tidspunktet har vi et semi-funksjonelt plugin, men det er fortsatt mer arbeid å gjøre. Åpenbart er informasjonen vi sender inn i databasen ikke vist hvor som helst, og det er ikke bra.
Men akkurat som med å lagre informasjon, er det viktige ting å vurdere når du henter informasjon. I neste veiledning ser vi på å hente informasjonen, vise den på forsiden, vise den på opsjonssiden, og også oppdatere informasjonen som en bruker endrer verdien av inngangselementet.
I mellomtiden, hvis du leter etter andre verktøy for å hjelpe deg med å bygge ut ditt voksende sett med verktøy for WordPress eller koden for å studere og bli mer kjent med WordPress, ikke glem å se hva vi har tilgjengelig i Envato Marked.
Husk at du kan fange alle 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.
Til slutt, ikke nøl med å legge igjen noen spørsmål eller kommentarer i feedet under. Jeg gjør mitt beste for å delta og svare på alle spørsmål eller kritikk du tilbyr som det gjelder dette prosjektet.
ressurser
 
Innstillings-API
 
Den komplette guiden til Innstillinger API
 
Enkelt ansvar prinsipp
 
wp_nonce_field
 
admin_post
 
wp_verify_nonce
 
 wp_nonce_field
 
Roller og evner
 
current_user_can
 
Validerer og unngår brukerdata
 



		
			
	   
	




Kode