I de tidligere delene av denne serien så vi på tabellene i WordPress-databasen og forholdet mellom dem.
I denne delen vil jeg dekke et bord som er forskjellig fra de andre - den wp_options
bord. Som du kan se fra diagrammet nedenfor, er dette den eneste tabellen som sitter på egenhånd:
Alternativtabellen lagrer en annen type data fra de andre tabellene: i stedet for å lagre data om innholdet på nettstedet ditt, lagrer det data om selve nettstedet. Data er skrevet til alternativtabellen ved hjelp av Options API eller Settings API, som begge består av et sett med funksjoner som brukes til å legge til, oppdatere og slette data fra denne tabellen.
Du kan legge til verdier til eksisterende alternativer, og du kan også legge til nye poster i tabellen når du vil opprette nye alternativer.
I denne opplæringen ser jeg på ulike aspekter av alternativtabellen og hvordan du interagerer med det:
wp_options
bordwp_options
bordwp_options
bordJeg vil bare gi en oversikt over APIene og hvordan de samhandler med alternativtabellen - hvis du vil lære mer, les Tom McFarlin's serie på Innstillinger API.
Som wp_options
Tabell lagrer data som er relatert til oppsett og administrasjon av nettstedet som helhet, tilgang til det er begrenset. For å kunne endre innstillinger og alternativer, må brukerne ha manage_options
evne. Den eneste standardbrukerrollen med denne funksjonen er administratorrollen (og i Multisite, nettverksadministratorrollen).
Dette betyr at hvis du må legge til alternativer som andre brukerroller har tilgang til, må du tilordne manage_options
evne til dem. Dette bærer risiko, så gjør det bare hvis du er sikker!
Alternativtabellen har en lignende struktur til de tre metadatabordene. Den har fire felt:
option_ID
OPTION_NAME
option_value
Autostart
- angir om alternativet lastes automatisk på hver side last - standard til ja
i en enkelt installasjon og Nei
i multisite.Hver plate i OPTION_NAME
feltet vil være en unik verdi: Hvis du legger til mer enn en verdi til et alternativ, lagrer WordPress dette i en matrise i option_value
felt. Et godt eksempel på dette er active_plugins
alternativet, som lagrer en rekke plugins aktivert på nettstedet ditt.
Når du legger til, redigerer eller sletter data i wp_options
bord, må du alltid spesifisere OPTION_NAME
, som jeg vil vise senere i denne opplæringen.
De wp_options
Tabellen er befolket fra en av tre kilder:
Det finnes en rekke alternativer som er innebygd i WordPress - du kan se alle disse i tilleggsreferansen. Men du kan også lage din egen.
Hvis du vil opprette nye alternativer i temaet eller plugin-modulen, vil du bruke Alternativer API eller Innstillinger API. Jeg vil dekke dem mer detaljert nedenfor.
Alternativ API består av åtte funksjoner som lar deg legge til, få, oppdatere eller slette alternativer:
Funksjon | parametere | Merknader |
---|---|---|
add_option () | $ alternativ , $ verdi , $ foreldet , $ autoload | Bare $ alternativ er nødvendig. Hvis det er en eksisterende post med din $ alternativ parameter som verdien av dens OPTION_NAME feltet, vil WordPress legge til din $ verdi til en matrise i option_value feltet for den posten, ellers vil det opprette en ny post. |
delete_option () | $ alternativ | Sletter alle feltene for det alternativet |
get_option () | $ alternativ , $ standard | $ standard (valgfritt) er standardverdien å returnere hvis ingen verdi lagres mot alternativet i databasen. |
update_option () | $ alternativ , $ new_value | $ new_value er verdien som vil fylle ut option_value felt |
add_site_option () | $ alternativ , $ verdi | Lik add_site_option () men legger til opsjonen allround i Multisite (som betyr at alternativet er lagret i wp_options bord og ikke den wp_XX_options bord hvor XX er nettstedet ID). $ autoload er ikke inkludert som sidealternativer, ikke autoload i Multisite, og dette kan ikke overstyres. |
delete_site_option () | $ alternativ | Det samme som delete_option () men fungerer nettverksavhengig i Multisite. |
get_site_option () | $ alternativ , $ standard , $ use_cache | Lik get_option () men henter det nettverksbrede alternativet i Multisite. |
update_site_option () | $ alternativ , $ verdi | Identisk med update_option () men fungerer nettverksavhengig i Multisite. |
Vær oppmerksom på at når du oppretter alternativer, enten via Alternativer API eller Innstillinger API, kan du opprette poster uten verdi i option_value
felt. Dette gjør at nettstedadministratorer kan fylle dette feltet på et senere tidspunkt.
I tillegg til Alternativer API, kan du også bruke Innstillinger API for å samhandle med data i wp_options
bord. Innstillings-API lar deg lage innstillinger som nettstedet administratorer kan bruke til å legge til eller oppdatere data i alternativtabellen - det legger til et brukergrensesnitt til alternativene dine.
Innstillings-API-en har mer til det enn alternativ-API, så jeg vil ikke dekke det i detalj her, men det har i hovedsak tre elementer:
wp_options
bord)De to funksjonene i Innstillinger API som samhandler direkte med wp_options
bordet er som følger:
Funksjon | parametere | Merknader |
---|---|---|
register_setting () | $ option_group , $ OPTION_NAME , $ sanitize_callback | De $ OPTION_NAME parameter refererer til OPTION_NAME felt i wp_options bord; De andre parameterne samhandler med andre funksjoner i Innstillinger API |
unregister_setting () | $ option_group , $ OPTION_NAME , $ sanitize_callback | Deregisters innstillinger fra wp_options bord - normalt brukt med deaktivering kroker for temaer eller plugins. |
Disse funksjonene legger ikke til verdier i alternativene i wp_options
tabell, men de lager innstillinger som kan ha enn verdier lagt til dem via andre funksjoner i Innstillinger API.
De wp_options
Tabellen er unik blant WordPress-databasetabellene, fordi den ikke deler forhold til noen av de andre tabellene. Dette skyldes at det lagrer data om nettstedet eller nettverket, og ikke innholdet. For å samhandle med alternativtabellen kan du bruke funksjonene i Alternativer API eller Innstillinger API, og du kan også benytte funksjoner som legger til datanettverk i en Multisite-isolasjon.
I den siste delen av denne serien ser jeg på Multisite, da det bruker noen ekstra databasetabeller som ikke har vært dekket så langt i denne serien, og oppretter også flere forekomster av hver av kjernebordene, en for hver side.