WordPress Roller og evner Å bygge et administrasjonsgrensesnitt

Dette er en firedelers serieopplæring som dekker WordPress-brukere, roller og evner. Serien vil dekke arkitekturen og utformingen av brukerrollene i WordPress; Fremhev de viktigste funksjonene for samhandling med brukere og styring av roller og evner; og i de to siste artiklene skal vi bygge et virkelighetseksempel som demonstrerer nytten av denne APIen.

Introduksjon

I den siste opplæringen bygget vi et virkelighetseksempel ved hjelp av WordPress-roller og -funksjonssystemet. Systemet er innkapslet i en enkelt klasse; og kan brukes ved å initialisere klassen og passere parametere til den. Parametrene er en rekke bruker-IDer, en annen rekke roller-navn; og også en bryter for å gi tilgang til alle brukere. I praksis vil du at WordPress Administrator skal kunne endre disse parametrene; og dermed kontrollere hvilke brukere som har en "client_dashboard"tilgang.

I denne opplæringen bygger vi grensesnittet som gir administratoren muligheten til å initialisere vår klasse automatisk og matte den med tilstrekkelige data. Grensesnittet lar administratoren velge roller, brukere; eller ring inn for full tilgang.

Koden for denne nye opplæringen er tilgjengelig på samme Github-arkiv. For å få tilgang til forrige kode, naviger til første forpliktelse til depotet. Jeg har besluttet å holde koden ulisensiert, så du er fri til å bruke den og lisensiere den som du finner passende.

Hvorfor trenger vi et grensesnitt?

I motsetning til brukere gir WordPress ingen grensesnitt for roller. Du kan ikke legge til, fjerne eller redigere eksisterende roller eller evner uten hjelp av et tredjeparts plugin. Du kan imidlertid ha en liste over eksisterende roller i bloggen din fra rullegardinlisten for valg av rolle når du redigerer en eksisterende brukerprofil. Grensesnittet begrenser deg til å velge bare én rolle for en bestemt bruker. Du kan heller ikke tilordne evner til brukere med standardgrensesnittet WordPress leveres med.

Av den grunn er det viktig at pluginet gir det nødvendige grensesnittet for å konfigurere brukertilgangskapasiteten. Dine plugin-brukere bør ikke stole på et eksternt tredjeparts plugin. Avhengig av kundens sofistikering og deres kunnskap om WordPress-plattformen, kan de kanskje:

Tillat tilgang til alle brukere.
Begrens tilgang til enkelte brukere.
Begrens tilgang til en eller flere roller.
En kombinasjon av brukere og roller.

Hvis du er litt forvirret, snakker vi om et plugin som har to dashboards: En for bloggadministratoren, som har adminsspesifikke funksjoner og innstillinger; og en annen for utvalgte brukere, som har begrensede funksjoner og innstillinger. Så dette eksemplet gjelder ikke for alle plugins der ute; men bare de som krever admin og klient tilgang.

For det vil vi ha to forskjellige grensesnitt: En for å velge roller og en annen for å velge brukere. For valg av rolle, må vi bygge et tilpasset grensesnitt fordi WordPress ikke har noe visuelt grensesnitt for dem. For brukervalg kan vi utnytte den allerede eksisterende brukerprofil siden ved å legge til flere egendefinerte felt.

Bygg rollevalgspanelet

WordPress kommer med et lite antall forhåndsdefinerte roller: Administrator, Forfatter, Bidragsyter, Redaktør og Abonnent. Kunnskapsrike WordPress-brukere kan legge til egne roller for å kategorisere og administrere sine brukere. På grunn av dette, bør grensesnittet hente alle rollene på nettstedet, og tilby muligheten til å velge hvilke som skal godkjenne klientadgang. Jeg benyttet også muligheten til å holde "alle" bryteren til samme grensesnitt. Å sjekke "alle" vil overstyre de andre innstillingene dine.

Bruk av WordPress Settings API

For å bygge grensesnittet bruker vi WordPress Settings API og oppretter en egendefinert funksjon som vil vise avmerkingsboksene. Følgende kode brukes til å registrere "wptuts_settings"innstillingsskjema. Vi registrerer også en del i det skjemaet, og et felt inne i delen.

 // Registrerer et nytt innstillingsskjema add_action ('admin_init', 'wptuts_settings_form'); funksjon wptuts_settings_form () // Registrer et nytt innstillingsskjema register_setting ('wptuts_settings', 'wptuts_settings'); // Registrer en ny seksjon add_settings_section ('wptuts_settings', 'General Settings', 'wptuts_section', 'general_settings_form', 'Client Access'); // Registrer et nytt felt add_settings_field ('client_roles', 'Client Roller', 'wptuts_roles_check', 'general_settings_form', 'wptuts_settings', array ('client_roles', 'wptuts_settings'));  funksjon wptuts_section () return null;

Funksjonen add_settings_section () krever en funksjon som sin tredje parameter som returnerer avsnittbeskrivelsen. For å holde ting enkelt, passerte jeg en funksjon som returnerer null (eller ingenting).

Funksjonen add_settings_field () aksepterer et felt-ID, en etikett, en funksjon, delen og skjemaet for å koble feltet til; og argumentet for å overføre til feltfunksjonen. Feltfunksjonen vil sende HTML-koden til feltet.

API-innstillingene for WordPress brukes til å lage skjemaer som automatisk lagrer innholdet i et WordPress-alternativ. Alternativet er "wptuts_settings", og er en matrise som har de forskjellige innstillingene til pluginet vårt. For å få WordPress til å gjenkjenne skjemafeltene våre, må vi først registrere dem ved å bruke funksjonene som er angitt ovenfor, og også tildele riktig navn til hvert felt. Så hvert felt vil ha et navn i skjemaet wptuts [FIELD_NAME].

I vårt tilfelle har vi et uforutsigbart antall roller; og dermed et uforutsigbart antall avkrysningsbokser. Det er ikke fornuftig å opprette og registrere et felt for hver rolle. Heldigvis støtter HTML arrayelementer; så vi navngir våre bokser wptuts [feltnavn] [role_1], wptuts [feltnavn] [role_2], wptuts [feltnavn] [role_n]... WordPress vil gjenkjenne dette HTML-arrayelementet og lagre det som et PHP-array.

Nedenfor er innholdet av "wptuts_settings"array når"alle","forfatter"og"abonnenten"avmerkingsboksene er valgt.

 'wptuts_settings' => array 'client_roles' => array 'all' => streng 'på' (lengde = 2) 'author' => streng 'på' (lengde = 2) 'abonnent' => streng 'på' lengde = 2)

Utarbeide felt HTML-koden

Funksjonen knyttet til feltet er "wptuts_roles_check". Den aksepterer en matrise som har innstillings-ID og feltnavn, slik at funksjonen blir gjenbrukbar i andre felt. Du kan overse denne parameteren og hardkode innstillings-ID og feltnavn til funksjonen din.

Funksjonen vil gå gjennom en rekke roller-navn returnert av "$ Wp_roles-> get_names ()". Det vil også deaktivere administratorrollen, og legge til en ekstra avkrysningsboks" alle ".

 / ** * Genererer roller-boksene form * * @param array $ param * / funksjon wptuts_roles_check ($ param) // Roller liste $ settings = get_option ($ param [1]); hvis (isset ($ innstillinger [$ param [0]])) $ val = $ innstillinger [$ param [0]];  ellers $ val = "; // Generer HTML-kode // Få WP-roller globalt $ wp_roles; $ rolls = $ wp_roles-> get_names (); unset ($ roller ['administrator']); // Generer HTML-kode hvis ($ val ['all'] === 'på') echo ' Alle
';  annet echo ' Alle
';  foreach ($ roller som $ key => $ verdi) if ($ val [$ key] === 'på') echo ' '. $ verdi. '
';  annet echo ' '. $ verdi. '
';

Legge til egendefinerte brukerprofiler

Som dekket i den første opplæringen i denne serien, kan brukerne ha ytterligere data knyttet til dem i form av nøkkel / verdi par. Vi dekket funksjonene for å legge til, oppdatere og fjerne brukerens metadata i den andre opplæringen. I denne delen ser vi hvordan du legger til en seksjon på hver brukerprofilside, og oppdaterer brukermetadataene tilsvarende.

Trinn 1 Hooking til brukerprofilen

WordPress gir fire tiltak for å koble til brukerprofilsiden. To handlinger for å legge til nye felt på redigeringssiden; og to andre handlinger for å håndtere HTTP POST-forespørselen. Forskjellen mellom "show_user_profile"handling og"edit_user_profile"handling er at sistnevnte passerer a WP_User objekt for at brukeren skal redigeres. Men forskjellen mellom de to andre handlingene er ikke klar.

 / ** * Bruker Metabox kroker * / Private funksjon metabox_user () // Vis metabox add_action ('show_user_profile', array (& $ dette, 'display_metabox')); add_action ('edit_user_profile', array (& $ dette, 'display_metabox')); // Lagre oppdatering add_action ('personal_options_update', array (& $ this, 'update_metabox')); add_action ('edit_user_profile_update', array (& $ this, 'update_metabox'));

Trinn 2 Viser det egendefinerte feltet

I motsetning til Innstillings-API, er det ingen begrensninger eller krav til HTML-koden som funksjonen utfører. WordPress lagrer ikke metadataene, så du er fri til å håndtere det som du ønsker.

 / ** * Vis det egendefinerte feltet * * @param objekt $ bruker * / offentlig funksjon display_metabox ($ bruker) $ user_meta = get_user_meta ($ user-> ID, 'wptuts_client', true); hvis ($ user_meta) $ checked = 'checked';  ellers $ checked = "; print <<Wptuts + Klient   Aktiver klienttilgang   Aktiver tilgang til Wptuts + Plugin Client Dashboard  
 
 skjema;

Aktiver klienttilgang	Aktiver tilgang til Wptuts + Plugin Client Dashboard

Trinn 3 Lagre de egendefinerte brukerfeltene

Som nevnt tidligere må vi håndtere sparing på en annen funksjon. Denne funksjonen kalles når brukeren trykker på "Oppdater profil" -knappen og HTML-skjemaet blir sendt inn i en POST-forespørsel.

 / ** * Oppdater brukeren Meta-data * * @param integer $ user_id * / offentlig funksjon update_metabox ($ user_id) hvis (isset ($ _ POST ['wptuts_client']) && $ _POST ['wptuts_client'] === 'på') $ checked = true;  ellers $ checked = false;  update_user_meta ($ user_id, 'wptuts_client', $ checked);

Oppdaterer klassen initialisering

Endelig må vi oppdatere vår klasse. I den tidligere opplæringen er vår klasse konstruert med tre parametre. Vi trenger ikke disse parameterne nå; og vår funksjon bør hente dem fra dataene som er lagret av grensesnittene.

Vi har to kilder til data for å hente: "wptuts_settings"alternativet og brukerens metadata. Forhåpentligvis ble henting av metadata gjort ganske enkelt med funksjonen"get_users ()"som returnerer akkurat det vi trenger (en rekke bruker-IDer) ved bare å spesifisere metatasten og verdien som brukeren burde ha.

 / ** * Angi tillatelsesenhetene * * @param boolean $ all * @param array $ roller * @param array $ users * / private funksjon set_entities () $ settings = get_option ('wptuts_settings'); $ roller = $ settings ['client_roles']; // ALLE regel hvis (isset ($ roller ['all']) && $ roller ['all'] === 'på') $ this-> all = true;  ellers $ this-> all = false;  // Roller regelen $ this-> roller = $ roller; ikke-fikserte ($ dette-> roller [ 'alle']); // Brukere regel $ this-> users = get_users (array ('meta_key' => 'wptuts_client', 'meta_value' => true, 'fields' => 'ID'));

Konklusjon

Det er det! Nå har vi et grensesnitt i WordPress admin for roller og evner. Gi oss beskjed i kommentarene nedenfor hva dine tanker handler om roller og evner, og hvilke funksjoner du kan legge til i klassen og grensesnittet vi har opprettet i denne serien.

Kode