Share
Questo è un tutorial in quattro parti che copre l'argomento WordPress utenti, ruoli e capacità. La serie riguarderà l'architettura e il design dei ruoli utente in WordPress; evidenziare le funzioni più importanti per interagire con gli utenti e gestire ruoli e capacità; e negli ultimi due articoli, costruiremo un esempio di vita reale che dimostra l'utilità di questa API.
Nell'ultimo tutorial, abbiamo creato un esempio di vita reale utilizzando il sistema di ruoli e funzionalità di WordPress. Il sistema è incapsulato in una singola classe; e può essere utilizzato inizializzando la classe e passando i parametri ad essa. I parametri sono la matrice di ID degli utenti, un altro array di nomi di ruoli; e anche un interruttore per consentire l'accesso a tutti gli utenti. In pratica, vuoi che l'amministratore di WordPress sia in grado di modificare tali parametri; e quindi controllare quali utenti hanno un "client_dashboard"accesso.
In questa esercitazione creeremo l'interfaccia che darà all'amministratore la possibilità di inizializzare automaticamente la nostra classe e alimentarla con i dati adeguati. L'interfaccia consentirà all'amministratore di selezionare i ruoli, gli utenti; o optare per l'accesso completo.
Il codice per questo nuovo tutorial è disponibile sullo stesso repository Github. Per accedere al codice precedente, vai al primo commit del repository. Ho deciso di mantenere il codice senza licenza, quindi sei libero di usarlo e concederlo in licenza come meglio credi.
A differenza degli utenti, WordPress non fornisce alcuna interfaccia per i ruoli. Non è possibile aggiungere, rimuovere o modificare i ruoli o le funzionalità esistenti senza l'ausilio di un plug-in di terze parti. Tuttavia, puoi avere un elenco dei ruoli esistenti nel tuo blog dall'elenco a discesa della selezione dei ruoli durante la modifica di un profilo utente esistente. L'interfaccia ti limita a selezionare un solo ruolo per un particolare utente. Inoltre, non è possibile assegnare funzionalità agli utenti con l'interfaccia predefinita fornita da WordPress.
Per questo motivo, è importante che il tuo plugin fornisca l'interfaccia richiesta per configurare le sue capacità di accesso degli utenti. Gli utenti del tuo plug-in non devono fare affidamento su un plug-in esterno di terze parti. A seconda della sofisticazione dei tuoi utenti e della loro conoscenza della piattaforma WordPress, potrebbero voler:
Se sei un po 'confuso, qui stiamo parlando di un plugin che ha due dashboard: uno per l'amministratore del blog, che ha caratteristiche e impostazioni specifiche dell'amministratore; e un altro per utenti selezionati, che ha funzionalità e impostazioni limitate. Quindi questo esempio non si applica a tutti i plugin là fuori; ma solo quelli che richiedono l'accesso come amministratore e client.
Per questo, avremo due interfacce diverse: una per la selezione dei ruoli e un'altra per la selezione degli utenti. Per la selezione dei ruoli, abbiamo bisogno di costruire un'interfaccia personalizzata perché WordPress non ha un'interfaccia visiva per loro. Per la selezione degli utenti, possiamo sfruttare la pagina del profilo utente già esistente aggiungendo campi personalizzati aggiuntivi.
WordPress viene fornito con un numero limitato di ruoli predefiniti: Amministratore, Autore, Collaboratore, Editor e Sottoscrittore. Gli utenti esperti di WordPress possono aggiungere i propri ruoli per categorizzare e gestire i propri utenti. Per questo motivo, la nostra interfaccia dovrebbe recuperare tutti i ruoli nel sito e offrire la possibilità di scegliere quali autorizzare l'accesso al client. Ho anche colto l'opportunità per inserire il "tutto" nella stessa interfaccia. Il controllo di "tutti" annullerà le altre impostazioni.
Per costruire l'interfaccia, utilizzeremo l'API di impostazioni di WordPress e creeremo una funzione personalizzata che visualizzerà le caselle di controllo. Il seguente codice è utilizzato per registrare il "wptuts_settingsmsgstr "forma delle impostazioni. Registriamo anche una sezione all'interno di tale modulo e un campo all'interno della sezione.
Accentsconagua
// registra un nuovo modulo delle impostazioni add_action ('admin_init', 'wptuts_settings_form'); function wptuts_settings_form () // Registra un nuovo modulo impostazioni register_setting ('wptuts_settings', 'wptuts_settings'); // Registra una nuova sezione add_settings_section ('wptuts_settings', 'Impostazioni generali', 'wptuts_section', 'general_settings_form', 'Client Access'); // Registra un nuovo campo add_settings_field ('client_roles', 'Client Ruoli', 'wptuts_roles_check', 'general_settings_form', 'wptuts_settings', array ('client_roles', 'wptuts_settings')); function wptuts_section () return null; La funzione add_settings_section () richiede una funzione come suo terzo parametro che restituisce la descrizione della sezione. Per mantenere le cose semplici, ho passato una funzione che restituisce null (o niente).
La funzione add_settings_field () accetta un ID campo, un'etichetta, una funzione, la sezione e il modulo per agganciare il campo; e l'argomento da passare alla funzione di campo. La funzione campo emetterà il codice HTML del campo.
L'API delle impostazioni di WordPress viene utilizzata per creare moduli che salvano automaticamente il loro contenuto in un'opzione WordPress. L'opzione è "wptuts_settings", ed è un array che ha le diverse impostazioni del nostro plugin.Per fare in modo che WordPress riconosca i nostri campi modulo, dobbiamo prima registrarli usando le funzioni sopra indicate e anche assegnare il nome giusto per ogni campo. avere un nome nel modulo wptuts [FIELD_NAME].
Nel nostro caso, abbiamo un numero imprevedibile di ruoli; e quindi un numero imprevedibile di checkbox. Non ha senso creare e registrare un campo per ogni ruolo. Fortunatamente, l'HTML supporta gli elementi dell'array; quindi chiamiamo le nostre checkbox wptuts [FIELD_NAME] [role_1], wptuts [FIELD_NAME] [role_2], wptuts [FIELD_NAME] [role_n]... WordPress riconoscerà questo elemento di matrice HTML e lo salverà come array PHP.
Di seguito è il contenuto del "wptuts_settings"matrice quando il"tutti","autore", e "abbonato"le caselle di controllo sono selezionate.
'wptuts_settings' => array 'client_roles' => array 'all' => stringa 'on' (lunghezza = 2) 'author' => stringa 'on' (lunghezza = 2) 'subscriber' => stringa 'on' ( lunghezza = 2)
La funzione collegata al campo è "wptuts_roles_checkMsgstr "accetta un array che ha l'ID impostazioni e il nome del campo, questo rende la nostra funzione riutilizzabile in altri campi.Puoi trascurare questo parametro e inserisci l'ID delle impostazioni e il nome del campo nella tua funzione.
La funzione eseguirà un ciclo attraverso una serie di nomi di ruoli restituiti da "$ Wp_roles-> get_names ()". Disattiverà anche il ruolo di amministratore e aggiungerà un'ulteriore casella di controllo" tutto ".
/ ** * Genera il modulo caselle di controllo * * @param array $ param * / function wptuts_roles_check ($ param) // Elenco ruoli $ settings = get_option ($ param [1]); if (isset ($ settings [$ param [0]])) $ val = $ settings [$ param [0]]; else $ val = "; // Genera codice HTML // Ottieni ruoli WP globali $ wp_roles; $ ruoli = $ wp_roles-> get_names (); unset ($ roles ['administrator']); // Genera codice HTML if ($ val ['all'] === 'on') echo ' Tutti
'; else echo ' Tutti
'; foreach ($ role as $ key => $ value) if ($ val [$ key] === 'on') echo ' '. $ valore. '
'; else echo ' '. $ valore. '
';
Come spiegato nel primo tutorial di questa serie, gli utenti possono avere a loro volta dati aggiuntivi associati sotto forma di coppie chiave / valore. Abbiamo coperto le funzioni per aggiungere, aggiornare e rimuovere i metadati degli utenti nel secondo tutorial. In questa parte vedremo come aggiungere una sezione a ciascuna pagina del profilo utente e aggiornare di conseguenza i metadati dell'utente.
WordPress offre quattro azioni per collegarsi alla pagina del profilo utente. Due azioni per aggiungere nuovi campi alla pagina di modifica; e altre due azioni per gestire la richiesta HTTP POST. La differenza tra "show_user_profile"azione e"edit_user_profile"l'azione è che quest'ultimo passa a WP_User oggetto per l'utente che si sta modificando. Tuttavia, la differenza tra le due altre azioni non è chiara.
/ ** * Ganci utente Metabox * / funzione privata metabox_user () // Visualizza il metabox add_action ('show_user_profile', array (& $ this, 'display_metabox')); add_action ('edit_user_profile', array (& $ this, 'display_metabox')); // Salva aggiornamento add_action ('personal_options_update', array (& $ this, 'update_metabox')); add_action ('edit_user_profile_update', array (& $ this, 'update_metabox')); A differenza dell'API Settings, non ci sono restrizioni o requisiti per il codice HTML generato dalla funzione. WordPress non salva i metadati, quindi sei libero di gestirlo come desideri.
/ ** * Visualizza il campo personalizzato * * @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 = "; stampa <<
