Share
Este es un tutorial de cuatro partes que cubre el tema de usuarios, roles y capacidades de WordPress. La serie cubrirá la arquitectura y el diseño de roles de usuario en WordPress; resalte las funciones más importantes para interactuar con los usuarios y administrar roles y capacidades; y en los últimos dos artículos, vamos a construir un ejemplo de la vida real que demuestra la utilidad de esta API..
En el último tutorial, creamos un ejemplo de la vida real utilizando el sistema de funciones y capacidades de WordPress. El sistema está encapsulado en una sola clase; y se puede utilizar inicializando la clase y pasándole parámetros. Los parámetros son la matriz de ID de usuarios, otra matriz de nombres de roles; y también un interruptor para permitir el acceso a todos los usuarios. En la práctica, desea que el Administrador de WordPress pueda cambiar esos parámetros; y así controlar qué usuarios tienen una "client_dashboard"acceso.
En este tutorial, construiremos la interfaz que le dará al administrador la capacidad de inicializar automáticamente nuestra clase y alimentarla con los datos adecuados. La interfaz permitirá al administrador seleccionar roles, usuarios; u optar por el acceso completo.
El código para este nuevo tutorial está disponible en el mismo repositorio de Github. Para acceder al código anterior, navegue a la primera confirmación del repositorio. He decidido mantener el código sin licencia, por lo que es libre de usarlo y licenciarlo como mejor le parezca.
A diferencia de los usuarios, WordPress no proporciona interfaz para roles. No puede agregar, eliminar o editar funciones o capacidades existentes sin la ayuda de un complemento de terceros. Sin embargo, puede tener una lista de los roles existentes en su blog de la lista desplegable de selección de roles al editar un perfil de usuario existente. La interfaz lo limita a seleccionar solo un rol para un usuario en particular. Además, no puede asignar capacidades a los usuarios con la interfaz predeterminada WordPress viene con.
Por esa razón, es importante que su complemento proporcione la interfaz necesaria para configurar sus capacidades de acceso de usuario. Los usuarios de su complemento no deben confiar en un complemento externo de terceros. Dependiendo de la sofisticación de sus usuarios y de su conocimiento de la plataforma WordPress, es posible que deseen:
Si está un poco confundido, aquí estamos hablando de un complemento que tiene dos paneles: uno para el administrador del blog, que tiene características y configuraciones específicas de administrador; y otro para usuarios seleccionados, que tiene características y configuraciones limitadas. Así que este ejemplo no se aplica a todos los complementos que existen; pero solo los que requieren acceso de administrador y cliente.
Para eso, tendremos dos interfaces diferentes: una para seleccionar roles y otra para seleccionar usuarios. Para la selección de roles, necesitamos crear una interfaz personalizada porque WordPress no tiene una interfaz visual para ellos. Para la selección de usuarios, podemos aprovechar la página de perfil de usuario ya existente agregando campos personalizados adicionales.
WordPress viene con una pequeña cantidad de roles predefinidos: Administrador, Autor, Colaborador, Editor y Suscriptor. Los usuarios expertos de WordPress pueden agregar sus propios roles para categorizar y administrar a sus usuarios. Debido a eso, nuestra interfaz debe obtener todos los roles en el sitio y ofrecer la opción de elegir cuáles autorizar el acceso del cliente. También aproveché la oportunidad para pegar el interruptor "todos" a la misma interfaz. Al marcar "todos" se anularán tus otras configuraciones.
Para construir la interfaz, usaremos la API de configuración de WordPress y crearemos una función personalizada que mostrará las casillas de verificación. El siguiente código se utiliza para registrar el "wptuts_settings"formulario de configuración. También registramos una sección dentro de ese formulario; y un campo dentro de la sección.
Accentsconagua
// Registra una nueva forma de configuración add_action ('admin_init', 'wptuts_settings_form'); función wptuts_settings_form () // Registre una nueva configuración de register_setting ('wptuts_settings', 'wptuts_settings'); // Registre una nueva sección add_settings_section ('wptuts_settings', 'General Settings', 'wptuts_section', 'general_settings_form', 'Client Access'); // Registrar un nuevo campo 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; La función add_settings_section () requiere una función como su tercer parámetro que devuelve la descripción de la sección. Para mantener las cosas simples, pasé una función que devuelve nulo (o nada).
La función add_settings_field () acepta un ID de campo, una etiqueta, una función, la sección y el formulario para enganchar el campo a; y el argumento para pasar a la función de campo. La función de campo dará salida al código HTML del campo..
La API de configuración de WordPress se utiliza para crear formularios que guardan automáticamente su contenido en una opción de WordPress. La opción es "wptuts_settings", y es una matriz que tiene las diferentes configuraciones de nuestro complemento. Para que WordPress reconozca nuestros campos de formulario, primero debemos registrarlos usando las funciones mencionadas anteriormente, y también para asignar el nombre correcto para cada campo. Por lo tanto, cada campo tener un nombre en el formulario wptuts [field_name].
En nuestro caso, tenemos un número impredecible de roles; y por lo tanto un número impredecible de casillas de verificación. No tiene sentido crear y registrar un campo para cada rol. Afortunadamente, HTML soporta elementos de matriz; así que nombramos nuestras casillas de verificación wptuts [field_name] [role_1], wptuts [field_name] [role_2], wptuts [field_name] [role_n]... WordPress reconocerá este elemento de matriz HTML y lo guardará como una matriz de PHP.
A continuación se muestra el contenido de la "wptuts_settings"matriz cuando el"todos"autor", y"abonado"las casillas de verificación están seleccionadas.
'wptuts_settings' => array 'client_roles' => array 'all' => string 'on' (length = 2) 'author' => string 'on' (length = 2) 'subscriber' => string 'on' ( longitud = 2)
La función vinculada al campo es "wptuts_roles_check". Acepta una matriz que tiene el ID de configuración y el nombre del campo; esto hace que nuestra función sea reutilizable en otros campos. Puede pasar por alto este parámetro y codificar la ID de configuración y el nombre del campo en su función.
La función recorrerá una matriz de nombres de roles devueltos por "$ wp_roles-> get_names ()". También anulará la función de administrador y agregará una casilla de verificación adicional" todos ".
/ ** * Genera las casillas de verificación de los roles * * @param array $ param * / function wptuts_roles_check ($ param) // Lista de roles $ settings = get_option ($ param [1]); if (isset ($ settings [$ param [0]])) $ val = $ settings [$ param [0]]; else $ val = "; // Generar código HTML // Obtener roles WP globales $ wp_roles; $ roles = $ wp_roles-> get_names (); unset ($ roles ['administrator']); // Generar código HTML if ($ val ['all'] === 'on') echo ' Todos
'; else echo ' Todos
'; foreach ($ roles como $ clave => $ valor) si ($ val [$ clave] === 'en') eco ' '. $ valor. '
'; else echo ' '. $ valor. '
';
Como se explica en el primer tutorial de esta serie, los usuarios pueden tener datos adicionales asociados en forma de pares clave / valor. Cubrimos las funciones para agregar, actualizar y eliminar los metadatos de los usuarios en el segundo tutorial. En esta parte, veremos cómo agregar una sección a cada página de perfil de usuario y actualizar los metadatos del usuario en consecuencia.
WordPress proporciona cuatro acciones para enlazar a la página de perfil de usuario. Dos acciones para agregar nuevos campos a la página de edición; y otras dos acciones para manejar la solicitud HTTP POST. La diferencia entre el "show_user_profile"acción y"edit_user_profile"La acción es que esta última pasa un WP_User Objeto para el usuario que está siendo editado. Sin embargo, la diferencia entre las otras dos acciones no está clara..
/ ** * User Metabox hooks * / private function metabox_user () // Muestra el metabox add_action ('show_user_profile', array (& $ this, 'display_metabox')); add_action ('edit_user_profile', array (& $ this, 'display_metabox')); // Guardar actualización add_action ('personal_options_update', array (& $ this, 'update_metabox')); add_action ('edit_user_profile_update', array (& $ this, 'update_metabox')); A diferencia de la API de configuración, no hay restricciones ni requisitos para el código HTML que genera la función. WordPress no guarda los metadatos, por lo que puede manejarlo como desee..
/ ** * Muestra el campo personalizado * * @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 = "; print <<
