Share
Dit is een vierdelige serie-zelfstudie over het onderwerp WordPress-gebruikers, rollen en mogelijkheden. De serie behandelt de architectuur en het ontwerp van gebruikersrollen in WordPress; markeer de belangrijkste functies voor interactie met gebruikers en het beheren van rollen en mogelijkheden; en in de laatste twee artikelen gaan we een realistisch voorbeeld geven dat het nut van deze API aantoont.
In de laatste zelfstudie hebben we een realistisch voorbeeld gemaakt met behulp van het WordPress rollen- en capaciteitenysteem. Het systeem is ingekapseld in een enkele klasse; en kan worden gebruikt door de klasse te initialiseren en parameters door te geven. De parameters zijn de reeks ID's van gebruikers, een andere reeks namen van rollen; en ook een schakelaar voor toegang tot alle gebruikers. In de praktijk wilt u dat de WordPress-beheerder die parameters kan wijzigen; en dus bepalen welke gebruikers een "client_dashboard" toegang.
In deze zelfstudie bouwen we de interface die de beheerder de mogelijkheid biedt om onze klasse automatisch te initialiseren en deze met de juiste gegevens te voeden. Via de interface kan de beheerder rollen selecteren, gebruikers; of meld u aan voor volledige toegang.
De code voor deze nieuwe tutorial is beschikbaar op dezelfde Github-repository. Om toegang te krijgen tot de vorige code, navigeert u naar de eerste commit van de repository. Ik heb besloten om de code niet-licentie te geven, dus je bent vrij om het te gebruiken en het in te zetten zoals je wilt.
In tegenstelling tot gebruikers biedt WordPress geen interface voor rollen. U kunt geen bestaande rollen of mogelijkheden toevoegen, verwijderen of bewerken zonder de hulp van een plug-in van derden. U kunt echter een lijst met de bestaande rollen in uw blog hebben in de vervolgkeuzelijst met functieselectie bij het bewerken van een bestaand gebruikersprofiel. De interface beperkt u tot het selecteren van slechts één rol voor een bepaalde gebruiker. U kunt ook geen voorzieningen toewijzen aan gebruikers met de standaardinterface waarmee WordPress wordt geleverd.
Om die reden is het belangrijk dat uw plug-in de vereiste interface biedt om de gebruikerstoegangsmogelijkheden te configureren. Uw plugin-gebruikers moeten niet vertrouwen op een externe plug-in van derden. Afhankelijk van de verfijning van uw gebruikers en hun kennis van het WordPress-platform, willen ze mogelijk:
Als je een beetje in de war bent, hebben we het hier over een plug-in die twee dashboards heeft: één voor de blogbeheerder, die beheerdersspecifieke functies en instellingen heeft; en een andere voor geselecteerde gebruikers, die beperkte functies en instellingen heeft. Dus dit voorbeeld is niet van toepassing op alle plug-ins die er zijn; maar alleen degenen waarvoor beheerders- en clienttoegang vereist is.
Daarvoor hebben we twee verschillende interfaces: een voor het selecteren van rollen en een andere voor het selecteren van gebruikers. Voor rolselectie moeten we een aangepaste interface bouwen omdat WordPress geen visuele interface voor hen heeft. Voor gebruikersselectie kunnen we gebruik maken van de reeds bestaande gebruikersprofielpagina door extra aangepaste velden toe te voegen.
WordPress wordt geleverd met een klein aantal vooraf gedefinieerde rollen: Beheerder, Auteur, Bijdrager, Redacteur en Abonnee. Deskundige gebruikers van WordPress kunnen hun eigen rollen toevoegen om hun gebruikers te categoriseren en te beheren. Daarom moet onze interface alle rollen op de site ophalen en de optie bieden om te kiezen welke de clienttoegang moet autoriseren. Ik maakte ook van de gelegenheid gebruik om de "alles" -schakelaar op dezelfde interface te houden. Als u "alles" aanvinkt, heeft dit voorrang boven uw andere instellingen.
Om de interface te bouwen, gebruiken we de WordPress Settings API en maken we een aangepaste functie die de selectievakjes weergeeft. De volgende code wordt gebruikt om de "wptuts_settings"instellingenformulier. We registreren ook een sectie binnen die vorm en een veld binnen de sectie.
Accentsconagua
// Registreert een nieuw instellingenformulier add_action ('admin_init', 'wptuts_settings_form'); function wptuts_settings_form () // Registreer een nieuw instellingenformulier register_setting ('wptuts_settings', 'wptuts_settings'); // Registreer een nieuwe sectie add_settings_section ('wptuts_settings', 'General Settings', 'wptuts_section', 'general_settings_form', 'Client Access'); // Registreer een nieuw veld add_settings_field ('client_roles', 'Client Roles', 'wptuts_roles_check', 'general_settings_form', 'wptuts_settings', array ('client_roles', 'wptuts_settings')); function wptuts_section () return null; De functie add_settings_section () vereist een functie als de derde parameter die de sectiebeschrijving retourneert. Om dingen simpel te houden, heb ik een functie doorgegeven die null (of niets) retourneert.
De functie add_settings_field () accepteert een veld-ID, een label, een functie, de sectie en het formulier om het veld aan te haken; en het argument om door te geven aan de veldfunctie. De veldfunctie voert de HTML-code van het veld uit.
De WordPress-instellingen-API wordt gebruikt om formulieren te maken die hun inhoud automatisch magisch opslaan in een WordPress-optie. De optie is "wptuts_settings", en is een array met de verschillende instellingen van onze plug-in. Om WordPress onze formuliervelden te laten herkennen, moeten we ze eerst registreren met behulp van de hierboven vermelde functies en ook de juiste naam toewijzen voor elk veld. heb een naam in het formulier wptuts [FIELD_NAME].
In ons geval hebben we een onvoorspelbaar aantal rollen; en dus een onvoorspelbaar aantal selectievakjes. Het heeft geen zin om voor elke rol een veld aan te maken en te registreren. Gelukkig ondersteunt HTML array-elementen; dus we noemen onze selectievakjes wptuts [FIELD_NAME] [role_1], wptuts [FIELD_NAME] [role_2], wptuts [FIELD_NAME] [role_n]... WordPress zal dit HTML-array-element herkennen en opslaan als een PHP-array.
Hieronder is de inhoud van de "wptuts_settings"array wanneer de"allemaal","schrijver", en"abonnee"selectievakjes zijn geselecteerd.
'wptuts_settings' => array 'client_roles' => array 'all' => string 'on' (length = 2) 'author' => string 'on' (length = 2) 'subscriber' => string 'on' ( lengte = 2)
De functie gekoppeld aan het veld is "wptuts_roles_checkHet accepteert een array met de instellingen-ID en de veldnaam, waardoor onze functie herbruikbaar is in andere velden.U kunt deze parameter over het hoofd zien en de instellingen-ID en de veldnaam hardcoderen in uw functie.
De functie doorloopt een reeks namen van rollen die worden geretourneerd door "$ Wp_roles-> get_names ()". Het zal ook de beheerdersrol uitschakelen en een extra aankruisvakje" alles "toevoegen.
/ ** * Genereert de keuzevakjes voor de selectievakjes * * @param array $ param * / function wptuts_roles_check ($ param) // Rollenlijst $ settings = get_option ($ param [1]); if (isset ($ settings [$ param [0]])) $ val = $ settings [$ param [0]]; else $ val = "; // HTML-code genereren // WP-rollen krijgen globale $ wp_roles; $ roles = $ wp_roles-> get_names (); unset ($ roles ['administrator']); // HTML-code genereren if ($ val ['all'] === 'on') echo ' Allemaal
'; else echo ' Allemaal
'; foreach ($ roles als $ key => $ value) if ($ val [$ key] === 'on') echo ' '. $ waarde. '
'; else echo ' '. $ waarde. '
';
Zoals besproken in de eerste zelfstudie van deze serie, kunnen gebruikers aanvullende gegevens aan deze koppelen in de vorm van sleutel / waardeparen. We hebben de functies besproken voor het toevoegen, bijwerken en verwijderen van metadata van gebruikers in de tweede zelfstudie. In dit deel bekijken we hoe u een sectie aan elke gebruikersprofielpagina kunt toevoegen en kunt u de metadata van de gebruikers dienovereenkomstig bijwerken.
WordPress biedt vier acties om aan de gebruikersprofielpagina te haken. Twee acties om nieuwe velden aan de bewerkingspagina toe te voegen; en twee andere acties om het HTTP POST-verzoek af te handelen. Het verschil tussen de "show_user_profile"actie en"edit_user_profile"actie is dat de laatste een a passeert WP_User object voor de gebruiker die wordt bewerkt. Het verschil tussen de twee andere acties is echter niet duidelijk.
/ ** * Gebruiker Metabox hooks * / private function metabox_user () // Geef de metabox add_action ('show_user_profile', array (& $ this, 'display_metabox')); add_action ('edit_user_profile', array (& $ this, 'display_metabox')); // Save update add_action ('personal_options_update', array (& $ this, 'update_metabox')); add_action ('edit_user_profile_update', array (& $ this, 'update_metabox')); In tegenstelling tot de Settings API zijn er geen beperkingen of vereisten aan de HTML-code die door de functie wordt uitgevoerd. WordPress doet niet het opslaan van de metadata, dus je bent vrij om het te behandelen zoals je wilt.
/ ** * Geef het aangepaste veld weer * * @param-object $ user * / public function display_metabox ($ user) $ user_meta = get_user_meta ($ user-> ID, 'wptuts_client', true); if ($ user_meta) $ checked = 'checked'; else $ checked = "; afdrukken <<
