WordPress Settings API, Del 7 Validering, Sanitisering og Input

Hvis du nå er med på oss, har vi dekket mange emner i denne serien - vi har forsøkt å gi en fullstendig oversikt over WordPress Settings API samt de relaterte funksjonene. Vi har diskutert innstillinger, alternativer, navigasjon og menyer. Vi har også jobbet gjennom praktiske eksempler som bruker hvert av emnene vi har diskutert.

Vi er nesten ferdige. I de to siste artiklene i denne serien skal vi se på sanitisering, validering og de grunnleggende innspillingselementene vi kan bruke i WordPress-plugins og -temaer.

Før vi kommer i gang: Denne artikkelen antar at du har fulgt sammen med resten av serien, har en arbeidskopi av prøvekoden installert, og er nå relativt kjent med innstillings-API og temaalternativer. Hvis du er usikker på noen av de ovennevnte, anbefaler jeg på det sterkeste å lese resten av artiklene før du går inn i dette innlegget.


Forstå validering og sanering

Før vi begynner å skrive noen kode, må vi forstå nøyaktig hva det er som vi skal utføre - nemlig validering og sanitisering. Enkelt sagt, disse er de to aspektene ved trygt å skrive og lese data fra en WordPress-opsjonsside og den underliggende databasen.

Vi skal dykke mye dypere inn i dette som vi ser på hver av inngangstyper og arbeider gjennom eksemplene, men la oss gi noen sammenheng til hva vi faktisk skal gjøre:

  • Validering er prosessen der vi undersøker dataene som kommer inn fra alternativsiden - eller snarere brukerinngangen - og avgjøre hvorvidt det er akseptabelt å lagre.
  • sanitization er prosessen der vi sørger for at data som kommer ut av databasen er rent og riktig formatert for gjengivelse på siden.

Kanskje den mest konsise oppsummeringen er at validering bør gjøres før du skriver dataene til databasen og sanitisering skal gjøres mellom lesing av data fra databasen og sending av den til nettleseren.

Ofte er validering relatert til lagring av data og sanitisering er relatert til å hente data, men det er også helt mulig å sanitere data etter at det har bestått validering for å sikre at bare rene data blir lagret i databasen. Når vi jobber med vår egen kode, er det lettere å gjøre dette; Vi kan imidlertid ikke alltid stole på at andre utviklere har sanitisert sine data, slik at ansvaret for å sanitere alle dataene som kommer ut av databasen, faller på oss.


Oppdaterer vårt prosjekt

For å gjøre det enkelt å forstå fullstendig validering og sanitisering, la oss introdusere en ny kategori i vår opsjonsside. Hvis du har introdusert en ny toppmeny, vil dette også kreve at vi legger til legg til et nytt undermenyelement, og oppdater fanen Alternativer. La oss ta vare på det nå.

Finn først sandbox_example_theme_menu funksjon og legg til følgende undermenyelement:

add_submenu_page ('sandbox_theme_menu', 'Input Examples', 'Input Examples', 'administrator', 'sandbox_theme_input_examples', create_function (null, 'sandbox_theme_display ("input_examples");'));

Deretter må vi fortsette og stubbe ut en funksjon som vil skape gruppen av alternativer for vår nye innstillinger-fanen. Forutsatt at du har fulgt med serien, bør dette være lett å følge:

funksjon sandbox_theme_initialize_input_examples () if (false == get_option ('sandbox_theme_input_examples')) add_option ('sandbox_theme_input_examples');  // ende hvis // slutt sandbox_theme_initialize_input_examples add_action ('admin_init', 'sandbox_theme_initialize_input_examples');

Til slutt må vi oppdatere sandbox_theme_display funksjon for å gjengi flippen og riktig velge den når du får tilgang enten via fanene eller undermenyelementet. La oss først oppdatere betingelsene som undersøker spørringsstrengen og funksjonens argumenter. Spesielt må den håndtere saken for inngangseksemplene. Oppdater betingelsene for å se slik ut:

hvis (isset ($ _GET ['tab'])) $ active_tab = $ _GET ['tab'];  annet hvis ($ active_tab == 'social_options') $ active_tab = 'social_options';  annet hvis ($ active_tab == 'input_examples') $ active_tab = 'input_examples';  else $ active_tab = 'display_options';  // slutt hvis / annet

Deretter må vi legge til en ny fane i navigasjonen. Oppdater nav-tab-wrapper beholder for å inkludere dette nye ankeret:

"> Input Eksempler

Til slutt må vi legge til en betingelse for formelementet som er ansvarlig for visning av alternativene. Oppdater betingelsene for å se slik ut:

hvis ($ active_tab == 'display_options') settings_fields ('sandbox_theme_display_options'); do_settings_sections ('sandbox_theme_display_options');  elseif ($ active_tab == 'social_options') settings_fields ('sandbox_theme_social_options'); do_settings_sections ('sandbox_theme_social_options');  annet settings_fields ('sandbox_theme_input_examples'); do_settings_sections ('sandbox_theme_input_examples');  // slutt hvis / annet

Hvis du antar at du har tatt med hele koden riktig, bør administrasjonspanelet nå se slik ut:

Vi er nå klar til å begynne å introdusere nye alternativelementer og validering og sanitiseringsfunksjonalitet. Hvis koden ovenfor virker uklar, må du sjekke ut artikler tidligere i serien som innstillinger, menysider og faner er alle dekket.


Elementtyper

Det finnes fem grunnleggende elementtyper som vi kan bruke for innspilling i våre WordPress-opsjons sider. Disse er innganger, tekstområder, avkrysningsbokser, radioknapper og velg bokser. I resten av denne artikkelen skal vi se på innspillingselementer og tekstområder, og vi vurderer de tre siste i den endelige artikkelen i serien.

Input

Inndataelementer er ideelle for situasjoner der vi trenger å fange en liten mengde tekst fra en bruker. Dette kan være noe som deres navn eller telefonnummer eller noe bare litt mer komplisert som en URL, deres e-postadresse eller en API-nøkkel. Faktisk bruker vi faktisk inntastingsfelter på siden "Sosiale valg" når vi ber om brukerens sosiale nettverksprofiladresser.

Validering av tekstinngang kan være en komplisert operasjon, spesielt hvis du vil håndheve visse begrensninger. Telefonnumre følger for eksempel et bestemt format, og hvis du spør en bruker for hans / hennes telefonnummer, kan du sette opp en funksjon som bestemmer om telefonnummeret overholder det strenge formatet. Tydeligvis kan vi ikke fange alle disse brukstilfellene i våre eksempler her, da det bare er for bredt et felt.

I stedet er det vi skal gjøre, at ingen skadelig kode skrives inn i databasen. Dette betyr at når en bruker skriver inn tekst i tekstboksen, skal vi fjerne alle HTML-koder og potensielt problematiske tegn. Men før du gjør det, la oss introdusere et nytt alternativ, forstå merkingen, og se hva som skjer hvis vi ikke håndheve enhver type validering.

Gå videre og introduser den nye delen og feltet ved hjelp av sandbox_theme_initialize_input_examples funksjon:

add_settings_section ('input_examples_section', 'Input Examples', 'sandbox_input_examples_callback', 'sandbox_theme_input_examples'); add_settings_field ('Input Element', 'Input Element', 'sandbox_input_element_callback', 'sandbox_theme_input_examples', 'input_examples_section'); register_setting ('sandbox_theme_input_examples', 'sandbox_theme_input_examples');

Definer deretter tilbakeringingen til delen:

funksjon sandbox_input_examples_callback () echo '

Gir eksempler på de fem grunnleggende elementtyper.

';

Til slutt, introdusere det faktiske inputelementet som vi skal bruke for å fange inn input:

funksjon sandbox_input_element_callback () $ options = get_option ('sandbox_theme_input_examples'); // Gjenopprett output echo ''; 

Alternativsiden din skal nå se ut som følgende bilde:

Forstå Markup

Frem til dette punktet har vi opprettet alternativene våre, og jeg har nevnt at vi til slutt vil diskutere hvert av attributter senere i serien. Dette er artikkelen der vi begynner å se på betydningen av id og Navn egenskaper.

Merk at ved starten av funksjonen leser vi alternativene for denne kategorien ved hjelp av WordPress ' get_option funksjon. Denne funksjonen returnerer alternativene i en matrise. De id Attributtet til inngangselementet identifiserer dette elementets verdi i arrayet. De Navn Attributt er navnet på gruppen som er merket med ID-en. Gir mening?

For å være fullstendig, tenk på det på denne måten:

  • WordPress vil opprette en matrise basert på navnet på delen du har definert. I dette tilfellet er det sandbox_theme_input_examples
  • Hvert element vil bli identifisert av id Egenskap. I dette eksemplet er det "input_example"
  • Du kan lese verdien av denne gruppen ved å bruke sandbox_theme_input_examples [input_example]

id av elementet representerer nøkkelen til verdien i alternativvalg, Navn Attributt representerer navnet på matrisen med nøkkelen til verdien i matrisen.

Legge til validering og sanitisering

På dette punktet er det helt mulig å begynne å skrive inn verdier i inngangselementet og lagre alternativet. Gå videre og prøv det - sett inn en verdi, klikk på "Lagre endringer", og du bør se inputelementet vise verdien du nettopp har opprettet. Men her er problemet: prøv å lime inn noe slikt inn i inntastingsfeltet:

Deretter hopp over til index.php og legg til følgende kodenavn:

 

Oppdater hjemmesiden og du bør legge merke til en iframe som dukker opp midt på temaets hjemmeside:

Virker som et relativt lite problem, men dette er akkurat den typen ting vi trenger for å hindre. Vi vil ikke at brukerne skal ha den typen kontroll over databasen, nettsidene og så videre. Selvfølgelig er lagring av en enkel iframe et mindre eksempel - hvis brukerne kan sette inn JavaScript, kan de påvirke visse aspekter av hele nettstedet ditt. Enda mer alvorlig, hvis brukerne kan sette inn ondsinnet SQL, kan databasen din bli kompromittert.

Så la oss innføre noen validering. Som nevnt ovenfor, vil vi fjerne eventuelle oppslag og problematiske tegn. For å gjøre dette må vi først definere et tilbakekallingsbekreftelse for vårt innspillingselement. For å gjøre dette, la oss gå tilbake til register_setting ring og oppdater det slik at det ser slik ut:

register_setting ('sandbox_theme_input_examples', 'sandbox_theme_input_examples', 'sandbox_theme_validate_input_examples');

Neste, la oss definere den funksjonen:

funksjon sandbox_theme_validate_input_examples ($ input)  // slutt sandbox_theme_validate_input_examples

Legg merke til at denne funksjonen aksepterer en enkelt parameter som vi har kalt inngang. Dette argumentet representerer det ugyldige settet av alternativer som WordPress sender til denne funksjonen fra alternativsiden som vi nettopp lagret. Vær også oppmerksom på at når vi legger til tilleggsutstyr, bruker vi denne samme funksjonen.

Oppretting av en valideringsfunksjon følger vanligvis tre trinn:

  1. Opprett en matrise som vil bli brukt til å lagre de validerte alternativene
  2. Valider (og rengjør, når det er nødvendig) alle innkommende valg
  3. Returner arrayet som vi opprettet tidligere

La oss gjøre det nå. Ta en titt på følgende implementering med stor oppmerksomhet til kommentarene:

funksjon sandbox_theme_validate_input_examples ($ input) // Opprett vårt array for lagring av de validerte alternativene $ output = array (); // Loop gjennom hver av de innkommende alternativene foreach ($ input som $ key => $ value) // Sjekk for å se om det nåværende alternativet har en verdi. Hvis ja, behandle det. hvis isset ($ input [$ key])) // Strip alle HTML- og PHP-koder og håndter riktig citerte strenger $ output [$ key] = strip_tags (stripslashes ($ input [$ key]));  // end if // end foreach // Returner array behandlingen eventuelle tilleggsfunksjoner filtrert av denne handlingsreisen apply_filters ('sandbox_theme_validate_input_examples', $ output, $ input); 

Det meste av koden skal være relativt rett frem, men de to viktigste aspektene kommer til uttalelsen inne i betingelses- og avkastningserklæringen.

  • Vi bruker strip_tags funksjon, som er innfødt i PHP, for å fjerne alle HTML og PHP-koder
  • Vi bruker stripslashes funksjon, som er en annen innfødt PHP-funksjon, som vil håndtere anførselstegn rundt en streng.

Til slutt kunne vi bare ha returnert $ utgang array på slutten av funksjonen, men returnerer resultatet av samtalen til apply_filters er en god praksis. Selv om det overstiger omfanget av denne artikkelen, er det verdt å merke seg at denne erklæringen i utgangspunktet kaller andre funksjoner som blir filtrert av denne funksjonen før du returnerer verdien.

Prøv nå å gi noen prøveinngang til inngangselementet. Prøv å gi en enkel streng, et telefonnummer, en e-postadresse, en nettadresse, en blokk med HTML, en linje med JavaScript og så videre. Ryddig, hei?

Til slutt, la oss gå tilbake index.php og gi en siste endring for å demonstrere hvordan vi kan utføre produksjonen sanitisering. Husk at det er god praksis å sanitere alternativer, selv om du arbeider med verdier som ikke kommer fra ditt eget arbeid.

Finn linjen som leser:

Og oppdatere den slik at den leser:

De sanitize_text_field funksjon er en annen WordPress-innfødt funksjon som er spesielt ment å sanitere brukerinngang fra tekstfelt eller fra databasen.

Vi vil se nærmere på denne artikkelen og den neste, men det er en fullstendig oversikt over disse funksjonene som er tilgjengelige i WordPress Codex.

textarea

Når vi så på input elementer, dekket vi mye av bakken. Heldigvis gjelder mange av de samme prinsippene for ikke bare tekstområder, men også resten av elementene. Som sådan må vi ikke bruke så mye tid med hvert element. Dette vil frigjøre oss for å se på noen av de idiosynkrasiene som følger med hver enkelt elementtyper.

For nå, la oss introdusere et tekstområdeelement. I vårt eksempel vil dette bestemte elementet tillate brukere å skrive inn noen setninger om seg selv - tenk på det som en kort biografi. Først legger du til følgende anrop til sandbox_theme_initialize_input_examples funksjon:

 add_settings_field ('Textarea Element', 'Textarea Element', 'sandbox_textarea_element_callback', 'sandbox_theme_input_examples', 'input_examples_section');

Neste, la oss definere tilbakeringingen som er nødvendig for å gjengi tekstområdet:

funksjon sandbox_textarea_element_callback () $ options = get_option ('sandbox_theme_input_examples'); // Gjenopprett output echo ''; 

Legg merke til at dette anropet virker veldig likt det inngående elementet som er definert ovenfor. Spesielt har vi levert en id Tilordne for å gi denne verdien en nøkkel i alternativvalgene, og vi har angitt det eksakte navnet og nøkkelen i elementets Navn Egenskap. Vi har også gitt tekstområdet en bestemt størrelse, selv om dette er rent vilkårlig.

Husk at siden dette elementet tilhører samme seksjon som inngangselementet, blir det behandlet med samme valideringsfunksjon. Som sådan får vi samme nivå for validering gratis. Prøv det - forsøk å lagre oppskrift, skript og andre typer kode ved hjelp av tekstområdet.

Til slutt, la oss oppdatere den offentlige siden av temaet vårt for å hente denne verdien og skikkelig hygge den for visning. I index.php, legg til følgende kodenavn:

  

Selv om det er praktisk talt det samme som inngangsfeltet, må vi sørge for at vi er komplette i valideringen og sanitiseringen.


Konklusjon

Selv om vi bare så på to typer elementer, dekket vi mye bakken. I tillegg til å bringe vårt tema oppdatert, har vi også implementert grunnleggende validering og har begynt å utforske sanitiseringsfunksjonene i WordPress.

I den endelige artikkelen tar vi en titt på de resterende tre elementtypene og hvordan de håndteres ved hjelp av validering og sanitisering. I mellomtiden eksperimentere med noen av det vi dekket her og husk å se gjennom de relaterte kildeartene som er koblet nederst i innlegget.


Beslektede kilder

  • WordPress Data Validation
  • get_option
  • strip_tags
  • stripslashes
  • apply_filters
  • sanitize_text_field