Advertisement
  1. Code
  2. Creative Coding

WordPress para el Desarrollo de Aplicaciones Web: Gestión de Usuarios

Scroll to top
Read Time: 9 min
This post is part of a series called Using WordPress for Web Application Development.
WordPress for Web App Development: Events, Actions, and Filters
WordPress for Web App Development: Sessions

() translation by (you can also view the original English article)

A lo largo de esta serie, hemos estado echando un vistazo a cómo WordPress puede servir como base para el desarrollo de aplicaciones web.

La cosa es, hasta este punto, que realmente no hemos echado un vistazo a las características de WordPress que realmente contribuyen a la construcción de aplicaciones web. Por el contrario, hemos invertido tiempo mirando cómo WordPress sirve como una base en lugar de un framework, y hemos mirado cómo WordPress está organizado en comparación con muchos de los frameworks modernos que están disponibles.

En concreto, hemos echado un vistazo al patrón de diseño dirigido por eventos en contraste con el patrón de diseño modelo-vista-controlador tan popular (y sus variantes), y cómo esto se ve en el contexto de WordPress.

Por eso, hemos trabajado en repensar la arquitectura de las aplicaciones y cómo su estructura dentro del contexto de WordPress nos ayuda a conseguir un mejor modelo conceptual de cómo las cosas encajan dentro de WordPress y cómo aprovechar el sistema de ganchos - es decir, acciones y filtros - y cómo inciden varios puntos durante el ciclo de vida de la página en WordPress.

Aunque esto merece un poco más de discusión, tenemos que echarle un vistazo a las facilidades que WordPress ofrece fuera de la caja con el fin de comprender plenamente las características y con cual tenemos que trabajar antes de realmente darle un vistazo a cómo trabajar con ellos.

En los próximos artículos, vamos a hacer precisamente eso.


Componentes de la Aplicación Web

Cuando piensas en los componentes de una aplicación web, una serie de cosas probablemente te vienen a la mente. Es decir, que aparte de la arquitectura normal de la base de datos, middleware y la capa de presentación, también se encuentran las siguientes características:

  • Gestión de Usuarios
  • Permisos
  • Manejo de Sesiones
  • Funcionalidad de Correo Electrónico
  • Recuperación y Serialización de Datos
  • Enrutamiento de URLs (a veces conocido como reescritura de URL o reglas de reescritura o incluso, solo rutas)
  • Almacenamiento en Caché
  • Soporte para Consultas Personalizadas

Aunque esta lista no es completa, llega a las notas altas de lo que ocurre en la construcción de una aplicación web estándar (por supuesto, si hay puntos que falten, no dudes en mencionarlos en los comentarios).

Y no - esto no es prescriptivo. A veces, las aplicaciones web no tienen gestión de usuarios, a veces los usuarios no tienen roles, tal vez no tengas necesidad de almacenamiento en caché y así sucesivamente.

Pero el punto no es hacer un caso de todas las cosas que necesitas. Por el contrario, se trata de hacer un caso para las cosas que están disponibles por si pudieras necesitarlas.

Así que dicho esto, echemos un vistazo a lo que WordPress ofrece en la forma de administración de usuarios, permisos, funcionalidad de correo electrónico y administración de sesiones.


Administración de Usuarios y Permisos

Quien ha utilizado WordPress - incluso si es sólo para blogs o administración de contenido básica - está familiarizado con el sistema del usuarios básico. Es decir, puede crear un nombre de usuario, una contraseña y luego llenar su perfil tanto como desee.

Además, los desarrolladores más experimentados están familiarizados con las ideas de los roles y las capacidades. Incluso me atrevería a decir que los que usan WordPress están familiarizados con el sistema incluso si nunca han echado un vistazo en el Códex o han probado con escribir cualquier código basado en usuarios.

Pero la idea general es muy simple: los usuarios representan un perfil individual para una cuenta en WordPress. Su papel está indicado por lo que se les ha asignado durante la creación de la cuenta.

Esos roles incluyen:

  • Suscriptor
  • Colaborador
  • Autor
  • Editor
  • Administrador

Una vez más, la mayoría de quienes han trabajado con WordPress está familiarizados con estas funciones, ¿bien? Pero, ¿cómo las capacidades encajan en la imagen?

En pocas palabras, las capacidades son las que conceden a los usuarios determinados permisos a través de la aplicación de WordPress, así como de lo que los restringe de ciertas áreas de la aplicación. Esto está relativamente bien documentado en el Codex.

Add New User with a RoleAdd New User with a RoleAdd New User with a Role
Agregar un Nuevo Usuario con un Rol

Pero aquí está la cosa: Si vas a compilar una aplicación en WordPress, las API disponibles permiten a los usuarios bloquear las áreas personalizadas que has creado basadas en sus funciones y capacidades.

Crear un Usuario Programáticamente

En primer lugar, digamos que en algún momento mientras estás trabajando en la aplicación web, quieres poder proporcionarle al usuario la capacidad de registrar o registrar un formulario personalizado (opuesto al método estándar para la creación de la cuenta de usuario en el servidor como se muestra arriba).

Esto puede hacerse creando una plantilla con un formulario y luego leyendo los datos enviados.

De hecho, realmente puede ser tan simple como capturar la dirección de correo electrónico del usuario. Digo esto porque, aunque los nombres de usuario son agradables y divertidos, los correos electrónicos tienden a ser únicos para un individuo por lo que hace más fácil la comprobación de errores.

Así que los pasos para hacerlo así serían:

  • Captura de la dirección de correo electrónico del usuario
  • Comprobar si un usuario ya existe con ese correo
  • Si no, crear el usuario.
  • De lo contrario, no crear el usuario y generar un mensaje de error

Relativamente directo, ¿correcto? Por supuesto, esto implica que eres capaz de generar una contraseña para el usuario durante la creación de su cuenta. Por suerte, hay una API para eso.

Así que aquí hay un ejemplo de cómo programáticamente crear un usuario basado en una dirección de correo electrónico especificada (mientras se auto-genera una contraseña).

1
if ( null == username_exists( $email_address ) ) {
2
3
  $password = wp_generate_password( 12, false );
4
	$user_id = wp_create_user( $email_address, $password, $email_address );
5
6
	wp_update_user(
7
		array(
8
			'ID'          =>    $user_id,
9
			'nickname'    =>    $email_address
10
		);
11
	);
12
13
} else {
14
	// The username already exists, so handle this accordingly...

15
}

Después de eso, de hecho necesitas crear una nueva instancia de WP_User.

1
$user = new WP_User( $user_id );

Esto es lo que nos permitirá definir los roles para el usuario.

Configuración del Rol y la Capacidad de un Usuario

Finalmente, es momento para determinar qué papel y conjunto de capacidades vas a asignar al usuario.

Por un lado, difícilmente puedes codificar estos valores basados en las opciones que ofrece WordPress. La verdad es, que puedes crear capacidades y roles personalizados. Por ahora, están fuera del alcance del artículo; sin embargo, podemos visitarlos en una futura serie.

Digamos que queremos darle a todos los usuarios que están actualmente inscritos el papel de suscriptor. Puedes ver qué conjunto de capacidades se les concederá en este artículo del Codex.

Configurar un Rol es Trivial:

1
$user->set_role( 'contributor' );

En este punto, has creado un nuevo usuario dentro de la aplicación de WordPress mediante programación sin tener que utilizar cualquiera de las funciones administrativas por defecto.

Simplemente conecta esto hasta tu propia plantilla, valida, desinfecta y comprueba los datos de la entrada $_POST, y estarás listo para avanzar.

El código completo se verá así:

1
if ( null == username_exists( $email_address ) ) {
2
3
	// Generate the password and create the user

4
	$password = wp_generate_password( 12, false );
5
	$user_id = wp_create_user( $email_address, $password, $email_address );
6
7
	// Set the nickname

8
	wp_update_user(
9
		array(
10
			'ID'          =>    $user_id,
11
			'nickname'    =>    $email_address
12
		);
13
	);
14
15
	// Set the role

16
	$user = new WP_User( $user_id );
17
	$user->set_role( 'contributor' );
18
19
} else {
20
	// The user already exists

21
} // end if/else

No está mal, ¿verdad?

Comprobando el Rol y la Capacidad de un Usuario

Pero crear un usuario y luago de hecho guardar su información en la base de datos en sólo la mitad ¿correcto?

Una vez que el usuario se registre y sea autenticado, probablemente vas a querer restringir el contenido basado en su rol. Para esto plantea la cuestión: una vez que un usuario inicia sesión, ¿cómo recuperamos el papel del usuario?

Por suerte, la API de WordPress lo hace relativamente fácil:

  • En primer lugar, tenemos que ser capaces de obtener el ID del usuario actual
  • Después de eso, podemos tomar el papel del usuario y proceder con la lógica condicional a partir de ahí

Vamos a tener que tomar ventaja de la función wp_get_current_user(), y luego necesitaremos obtener una instancia del objeto WP_User usando el ID del usuario actual después de que podamos observar las capacidades del usuario.

Echa un vistazo en el siguiente código:

1
// Get an instance of the current user

2
$user_id = wp_get_current_user()->ID;
3
$user = new WP_User( $user_id );

No está mal, ¿verdad?

Esto hace fácil escribir código condicional como:

1
// This will print the user capabilities

2
print_r( $user->wp_capabilities );
3
4
// Which in turn will allow you to perform a check like this:

5
if ( '1' === $user->wp_capabilities['subscriber'] ) {
6
	// We have a subscriber

7
}

Hay una forma alternativa de hacerlo, sin embargo:

1
global $current_user;
2
get_currentuserinfo();
3
4
if ( 0 === $current_user->user_level ) {
5
	// We have a subscriber

6
}

¿Pero esto plantea la pregunta de donde  viene ese cero ? Comprueba exactamente eso.

Las diferencias entre los dos enfoques dependen de qué tan orientado a objetos deseas tu código.

Tiendo a ser menos fan de usar global cuando existe un enfoque orientado a objetos disponible (tal como en el primer ejemplo); sin embargo, el segundo ejemplo proporciona una solución relativamente simple. Es tu elección.

De todos modos, una vez el condicional compruebe el rol de la cuenta de un usuario, puedes entonces limitarlo a áreas específicas de la aplicación.


Pero los Usuarios Necesitan Correos!

Tienes razón: por lo menos, los usuarios necesitan recibir mensajes para cuando se han creado sus cuentas y tienen que ser capaces de recibir mensajes de correo electrónico cada vez que algo acerca de su cuenta ha cambiado.

Una vez más, WordPress proporciona una API que lo hace realmente fácil, pero puede ser extendido más allá de acciones simples como cuando se cambia la información del perfil de un usuario.

De hecho, dado el hecho de que WordPress tiene un sistema rico en eventos, podría potencialmente engancharse en cualquier número de eventos y enviar correos electrónicos cuando algo sucede. Obviamente es excesivo, pero te va a demostrar cuán potente es realmente la API.

Así que en la siguiente sección, vamos a echar un vistazo a la API de email de WordPress y cómo puede ser utilizada para enviar mensajes sobre determinadas actividades, así como la forma en se puede enganchar en otras características de la aplicación.

Advertisement
Did you find this post useful?
Want a weekly email summary?
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.