WordPress Roller och Möjligheter Bygga ett Admin Interface

Detta är en serie med fyra delar, som omfattar WordPress-användare, roller och funktioner. Serien kommer att täcka arkitekturen och utformningen av användarroller i WordPress; markera de viktigaste funktionerna för att interagera med användare och hantera roller och funktioner; och i de två senaste artiklarna kommer vi att bygga ett verkligt exempel som visar användbarheten av detta API.


Introduktion

I den sista handledningen byggde vi ett verkligt exempel med hjälp av WordPress-roller och kapacitetssystem. Systemet är inkapslat i en enda klass; och kan användas genom att initialisera klassen och passera parametrar till den. Parametrarna är arrayen av användar ID, en annan grupp av roller namn. och även en växel för att tillåta åtkomst till alla användare. I praktiken vill du att WordPress-administratören ska kunna ändra dessa parametrar. och därmed kontrollera vilka användare som har en "client_dashboard" tillgång.

I denna handledning bygger vi gränssnittet som ger administratören möjlighet att automatiskt initiera vår klass och mata in den med tillräckliga data. Gränssnittet tillåter admin att välja roller, användare; eller välja full tillgång.

Koden för den här nya handledningen finns tillgänglig i samma Github-arkiv. För att komma åt den föregående koden, navigera till första förplikten av förvaret. Jag har beslutat att hålla koden olicensierad, så du är fri att använda den och licensera den som du passar.


Varför behöver vi ett gränssnitt?

Till skillnad från användare ger WordPress inget gränssnitt för roller. Du kan inte lägga till, ta bort eller redigera befintliga roller eller funktioner utan hjälp av ett plugin från tredje part. Du kan emellertid få en lista över befintliga roller i din blogg från rullgardinsmenyn för rollval när du redigerar en befintlig användarprofil. Gränssnittet begränsar dig till att bara välja en roll för en viss användare. Du kan inte heller tilldela funktioner till användare med standardgränssnittet WordPress levereras med.

Av den anledningen är det viktigt att ditt plugin tillhandahåller det önskade gränssnittet för att konfigurera användaråtkomstfunktionerna. Dina plugin-användare borde inte förlita sig på ett externt tredjeparts plugin. Beroende på dina användares sofistikerade kunskaper och deras kunskaper om WordPress-plattformen kan de vilja:

  • Tillåt åtkomst till alla användare.
  • Begränsa åtkomst till vissa användare.
  • Begränsa åtkomst till en eller flera roller.
  • En kombination av användare och roller.

Om du är lite förvirrad, pratar vi här om ett plugin som har två instrumentbrädor: En för bloggadministratören, som har adminspecifika funktioner och inställningar; och en annan för utvalda användare, som har begränsade funktioner och inställningar. Så det här exemplet gäller inte alla plugins där ute. men bara de som kräver administratör och klientåtkomst.

För det har vi två olika gränssnitt: En för att välja roller och en annan för att välja användare. För val av roll behöver vi bygga ett anpassat gränssnitt eftersom WordPress inte har något visuellt gränssnitt för dem. För användarval kan vi utnyttja den redan befintliga användarprofilsidan genom att lägga till ytterligare anpassade fält.


Bygga rollvalpanelen

WordPress levereras med ett fåtal fördefinierade roller: Administratör, Författare, Bidragsgivare, Redaktör och Prenumerant. Kunniga WordPress-användare kan lägga till egna roller för att kategorisera och hantera sina användare. På grund av detta bör vårt gränssnitt hämta alla roller på webbplatsen och erbjuda möjlighet att välja vilka som tillåter klientåtkomst. Jag tog också chansen att hålla kontakten "alla" till samma gränssnitt. Att kontrollera "alla" kommer att åsidosätta dina andra inställningar.

Använda API: n för WordPress

För att bygga gränssnittet använder vi API: n för WordPress och skapar en anpassad funktion som visar kryssrutorna. Följande kod används för att registrera "wptuts_settings"Inställningsformulär. Vi registrerar också en sektion inuti den formen och ett fält i avsnittet.

 // Registrerar ett nytt inställningsformulär add_action ('admin_init', 'wptuts_settings_form'); funktion wptuts_settings_form () // Registrera ett nytt inställningsformulär register_setting ('wptuts_settings', 'wptuts_settings'); // Registrera ett nytt avsnitt add_settings_section ('wptuts_settings', 'General Settings', 'wptuts_section', 'general_settings_form', 'Client Access'); // Registrera ett nytt fält add_settings_field ('client_roles', 'Client Rolls', 'wptuts_roles_check', 'general_settings_form', 'wptuts_settings', array ('client_roles', 'wptuts_settings'));  funktion wptuts_section () return null; 

Funktionen add_settings_section () kräver en funktion som sin tredje parameter som returnerar sektionsbeskrivningen. För att hålla det enkelt, passerade jag en funktion som returnerar null (eller ingenting).

Funktionen add_settings_field () accepterar ett fält-ID, en etikett, en funktion, sektionen och formuläret för att koppla fältet till; och argumentet att övergå till fältfunktionen. Fältfunktionen kommer att mata ut HTML-koden i fältet.

API: n för WordPress används för att skapa formulär som automatiskt lagrar innehållet i ett WordPress-alternativ. Alternativet är "wptuts_settings"och är en array som har olika inställningar för vårt plugin. För att WordPress ska kunna känna igen våra formulärfält måste vi först registrera dem med hjälp av ovan angivna funktioner och också att tilldela rätt namn för varje fält. Så varje fält kommer att ha ett namn i formuläret wptuts [FIELD_NAME].

I vårt fall har vi ett oförutsägbart antal roller; och sålunda ett oförutsägbart antal kryssrutor. Det är inte meningsfullt att skapa och registrera ett fält för varje roll. Lyckligtvis stöder HTML arrayelement; så vi heter våra kryssrutor wptuts [FIELD_NAME] [role_1], wptuts [FIELD_NAME] [role_2], wptuts [FIELD_NAME] [role_n]... WordPress kommer att känna igen det här HTML-elementet och spara det som en PHP-array.

Nedan är innehållet i "wptuts_settings"array när"Allt","författare"och"abonnent"kryssrutorna är markerade.

 'wptuts_settings' => array 'client_roles' => array 'all' => sträng 'på' (längd = 2) 'author' => sträng 'på' (längd = 2) 'subscriber' => sträng 'på' längd = 2)

Utmatning av fältets HTML-kod

Funktionen kopplad till fältet är "wptuts_roles_check". Den accepterar en array som har inställnings-ID och fältnamn, vilket gör att vår funktion kan återanvändas i andra fält. Du kan förbise denna parameter och hardkoda inställnings-ID och fältnamn i din funktion.

Funktionen kommer att slingra igenom en rad roller namn som returneras av "$ Wp_roles-> get_names ()". Det kommer också att avaktivera administratörsrollen och lägga till en extra kryssrutan" alla ".

 / ** * Genererar rutorna kryssrutor formulär * * @param array $ param * / funktion wptuts_roles_check ($ param) // Rolllista $ settings = get_option ($ param [1]); om (isset ($ settings [$ param [0]])) $ val = $ inställningar [$ param [0]];  andra $ val = "; // Skapa HTML-kod // Hämta WP-roller globalt $ wp_roles; $ roles = $ wp_roles-> get_names (); unset ($ roller ['administrator']); // Skapa HTML-kod om ($ val ['all'] === 'på') echo ' Allt
'; annars echo ' Allt
'; foreach ($ roller som $ key => $ värde) om ($ val [$ key] === 'på') echo ' '. $ värde. '
'; annars echo ' '. $ värde. '
';

Lägga till anpassade användarprofilfält

Såsom omfattas av den första handledningen i denna serie kan användarna ha ytterligare data i samband med dem i form av nyckel / värdepar. Vi täckte funktionerna för att lägga till, uppdatera och ta bort användarnas metadata i den andra handledningen. I den här delen ser vi hur du lägger till en sektion på varje användarprofil sida och uppdaterar användarmetadata i enlighet därmed.

Steg 1 Hooking till användarprofilen

WordPress ger fyra åtgärder för att koppla till användarprofilsidan. Två åtgärder för att lägga till nya fält på redigeringssidan; och två andra åtgärder för att hantera HTTP POST-förfrågan. Skillnaden mellan "show_user_profile"åtgärd och"edit_user_profile"Åtgärden är att den senare passerar en WP_User objekt för att användaren ska redigeras. Skillnaden mellan de två andra åtgärderna är dock inte tydlig.

 / ** * Användare Metabox krokar * / privat funktion metabox_user () // Visa metabox add_action ('show_user_profile', array (& $ this, 'display_metabox')); add_action ('edit_user_profile', array (& $ this, 'display_metabox')); // Spara uppdateringen add_action ('personal_options_update', array (& $ this, 'update_metabox')); add_action ('edit_user_profile_update', array (& $ this, 'update_metabox')); 

Steg 2 Visa det anpassade fältet

Till skillnad från inställnings API, finns det inga begränsningar eller krav på HTML-koden som funktionen matar ut. WordPress sparar inte metadata, så du är fri att hantera det som du vill.

 / ** * Visa det anpassade fältet * * @paramobjektet $ användaren * / offentlig funktion display_metabox ($ user) $ user_meta = get_user_meta ($ user-> ID, 'wptuts_client', true); om ($ user_meta) $ checked = 'checked';  annars $ checked = "; print <<
Wptuts + Klient
Aktivera åtkomst till Wptuts + Plugin Client Dashboard
form;

Steg 3 Spara de anpassade användarfälten

Som tidigare nämnts måste vi hantera besparingen på en annan funktion. Den här funktionen heter när användaren trycker på "Uppdatera profil" -knappen och HTML-formuläret skickas i en POST-förfrågan.

 / ** * Uppdatera användaren Meta-data * * @param heltal $ user_id * / public function update_metabox ($ user_id) om (isset ($ _ POST ['wptuts_client']) && $ _POST ['wptuts_client'] === 'på') $ checked = true;  annat $ checked = false;  update_user_meta ($ user_id, 'wptuts_client', $ checked); 

Uppdatering av klassinitiering

Slutligen måste vi uppdatera vår klass. I den tidigare handledningen är vår klass konstruerad med tre parametrar. Vi behöver inte nu dessa parametrar; och vår funktion bör hämta dem från de data som sparas av gränssnitten.

Vi har två datakällor att hämta: "wptuts_settings"alternativet och användarens metadata. Förhoppningsvis hämtades metadata ganska enkelt med funktionen"get_users ()"som returnerar exakt vad vi behöver (en rad användar-ID) genom att helt enkelt ange metatangenten och värdet som användaren borde ha.

 / ** * Ange behörighetsenheter * * @param boolean $ alla * @param array $ roller * @param array $ users * / privat funktion set_entities () $ settings = get_option ('wptuts_settings'); $ roller = $ settings ['client_roles']; // ALL regel om (isset ($ roller ['all']) && $ roller ['all'] === 'på') $ this-> all = true;  annat $ this-> all = false;  // Roller regel $ this-> roller = $ roller; unset ($ this-> roller [ 'alla']); // Användare reglerar $ this-> users = get_users (array ('meta_key' => 'wptuts_client', 'meta_value' => true, 'fields' => 'ID')); 

Slutsats

Det är allt! Nu har vi ett gränssnitt i WordPress-administratören för roller och funktioner. Låt oss veta i kommentarerna nedan vad dina tankar handlar om roller och funktioner, och vilka funktioner du kan lägga till i klassen och gränssnittet vi har skapat i denna serie.