francescllorens.eu

Low-Intensity Philosophy

WordPress para educación: cómo configurar un entorno flexible. Un artículo no solamente técnico (ii)

<< Viene de WordPress para educación: cómo configurar un entorno flexible. Un artículo no solamente técnico (i)

Antes de continuar: pero, ¡si existe Buddypress!

Algún lector estará pensando que no he mencionado la existencia de Buddypress (http://buddypress.org/), una versión de WordPress que convierte a la plataforma en una red social, con soporte para grupos, con el popular sistema de foros bbPress (http://bbpress.org/) y con un buen número de plugins propios, desarrollados específicamente para esta versión social de WordPress. En efecto, si lo que se desea es un entorno preferentemente conversacional, orientado a la comunicación y a los perfiles de usuario, Buddypress resulta una excelente alternativa a tener en cuenta. Puede instalarse desde cero o bien sobre una instalación de WordPress estándar preexistente. Dicho queda, aunque de momento seguiré con los objetivos inicialmente autoimpuestos.

“Pluginizar” WordPress

El verbo no existe en español y quizás sea hasta un tanto feo. Pero en el mundo de los entornos digitales resuelve la cuestión de referirse a la configuración personalizada de una plataforma o servicio mediante el uso de pequeños (y no tan pequeños) subprogramas que se conectan o “enchufan” al código del programa principal (to plug in) para ampliar, restringir, modificar el número de funcionalidades con que éste viene dotado “de serie”. El núcleo del programa principal se denomina core y está escrito de tal modo que posee, por así decirlo, puertas al exterior por las que se conectan los plugins. WordPress libera en cada nueva versión un core relativamente sencillo, compacto y estable y toma la decisión (como, por otra parte, hacen la mayoría de los distribuidores de frameworks de blogging y gestión de contenidos o CMS) de que gran parte de la potencia de su producto recaiga en los plugins escritos por terceros, particulares o empresas, esto es, por desarrolladores independientes. Una parte de su modelo de negocio se encuentra aquí.

El repositorio de plugins de WordPress es impresionante: unos 22.000. La mayoría son gratuitos, los más profesionales tienen versiones gratuitas y versiones PRO con mayores prestaciones. Existe uno o más plugins para casi cualquier necesidad imaginable. El usuario final no tiene más que buscar el plugin deseado en el repositorio (normalmente lo hace el administrador desde el backend de WordPress) e instalarlo mediante un botón al propósito. Por lo tanto, no existe algo así como “una” sola versión de WordPress. Mediante el uso de plugins el usuario, el profesor en nuestro caso, obtiene una configuración adaptada a sus necesidades, personalizada, customizada, -o “tuneada”-.

Por esta razón he afirmado desde el principio que sin plugins no hay nada que hacer. Dicho lo cual, sin embargo, no sería noble no reconocer que los plugins tienen también aspectos problemáticos. Por una parte, sobre todo los plugins desarrollados altruístamente por programadores individuales pueden ser de pronto “descontinuados” esto es, cesados en su desarrollo. Aunque no suelen desaparecer del repositorio, a la larga pueden volverse incompatibles con los nuevos core de la plataforma (sin embargo, es frecuente que plugins bastante antiguos sigan funcionando correctamente en las versiones más recientes de WordPress. En el momento de la instalación, WordPress lanza una advertencia si el plugin no ha sido probado con la versión instalada del producto. Aún siendo así, lo normal es que el plugin se deje instalar y funcione bien, por lo que en principio ello no nos debería disuadir de intentar utilizarlo). Por otra parte, el incremento de productividad que supone el uso de plugins tiene un coste técnico: el aumento de la carga de trabajo del servidor y de las llamadas a la base de datos. Este problema habitualmente se manifiesta como ralentización de las peticiones de páginas, pero un plugin bien programado suele haberlo considerado de manera previa y minimizado. Ahora bien, la sobrecarga (el exceso) de plugins sí puede consumir el espacio de memoria asignado por defecto por WordPress y/o el servidor. En este caso recibiremos un error del tipo “excedido el límite de memoria” y la plataforma no será visible online (aunque no se perderá ningún dato). Entonces es preciso aumentar el espacio de memoria via wp-config.phpphp.ini (si se tiene acceso) o un archivo .htaccess. Un administrador del servidor virtual debería resolverlo con rapidez.

Es necesario ser conscientes también, por último, de que los plugins suelen agregar archivos a la instalación original (sobre todo de tipo *.js, *.php y *.css) por lo que podrían crearse agujeros de seguridad. Con todo, las ventajas derivadas del uso de plugins superan, a juicio del que escribe, en miles de veces a sus posibles inconvenientes (que, caso de presentarse, son solucionables en su totalidad). Sin plugins nos perdemos la potencia, la flexibilidad y la personalización (la adaptación de la tecnología a nuestras necesidades, y no de nosotros a ella) de una excelente plataforma de comunicación y gestión de contenidos. Sin plugins WordPress es sólo un gestor, un muy buen gestor, de blogs.

En adelante, recuérdese que todos los plugins que se mencionan pueden agregarse a una instalación de WordPress desde el menú Plugins/Añadir nuevo del área de administración o backend. Los plugins sólo pueden ser agregados y configurados por un administrador o, alternativamente, por un rol al que específicamente se le haya concedido el privilegio de agregar plugins.

Indicar también que los plugins explicados no son los únicos posibles para una función dada (bien, en ocasiones puede que sí, no lo sé con seguridad, pues a decir verdad no he examinado los 22.000). Por ejemplo, en la sección siguiente se menciona el uso del plugin User Role Editor. También existe un plugin llamado Members que hace prácticamente lo mismo que ése. Por diferentes motivos he optado por unos plugins en detrimento de otros. Ello no debe ser interpretado como que los aquí propuestos son los mejores, o los únicos. Sencillamente, son los que yo he usado.

Comencemos con la prometida descripción de las funciones.

 1. Roles extendidos de usuarios y grupos

Teóricamente hablando, un espacio virtual puede ser ocupado por personas para las que se han diseñado objetivos y roles diferentes. Un visitante no posee los mismos permisos o privilegios sobre el entorno que un autor de contenidos, ni éste que un administrador. Ello da lugar, desde el punto de vista conceptual, a la necesidad de establecer roles diferentes para tipos diferentes de usuarios y, además, a que estos usuarios puedan, si resulta de interés, constituir grupos entre sí, con iguales o distintos privilegios de grupo.

WordPress posee un conjunto de roles por defecto (de más a menos privilegios, son éstos: administrador, editor, autor, colaborador y suscriptor). Aunque parezcan suficientes, y lo sean en general, no son los más adecuados para nuestra propuesta formativa (mejor dicho, en realidad no necesitamos estos roles sino una estructura alternativa, de hecho más simple), así que hemos utilizado un par de plugins para añadir nuevos roles a nuestro proyecto. Por otra parte, WordPress no considera al simple visitante de la página web como un rol específico, de modo que resulta complicado desde una instalación estándar controlar qué páginas se muestran y qué páginas se ocultan al usuario, en función de si éste sólo está viendo el sitio web o si se ha registrado en él.

La casa de los filósofos (http://francescllorens.eu/1bat1213/), proyecto que nos sirve de referencia en esta explicación, utiliza dos plugins para gestionar los roles y privilegios de los estudiantes registrados. La creación de nuevos roles y la definición de los privilegios de cada uno se lleva a cabo mediante el plugin User Role Editor. Así, en la plataforma he definido tres roles nuevos, correspondientes a los alumnos de humanidades (1BATA, rol: alumnoa), ciencias sociales (1BATB, rol: alumnob) y ciencias (1BATX, rol: alumnox). A estos roles he concedido privilegios básicos de lectura y edición de páginas. La captura inferior muestra a User Role Editor en acción, con la asignación de privilegios al rol alumnox.

Sin embargo, User Role Editor define los roles y sus privilegios correspondientes, pero no permite asignar partes de la plataforma a cada rol, es decir, no permite que, por ejemplo, los alumnos de ciencias (el rol alumnox) sólo editen las páginas del grupo de ciencias. Para ello viene en nuestra ayuda otro poderoso plugin, Role Scoper, realmente impresionante, aunque difícil y poco intuitivo. Role Scoper crea una interfaz añadida para cada entrada o página de la plataforma, que permite restringir su edición a los roles deseados. En nuestro proyecto, cuando los alumnos registrados de ciencias accedan al entorno podrán ver cualquier contenido, pero sólo podrán editar las páginas que Role Scoper les permite, es decir, las del grupo de ciencias (1BATX). E igual para el resto de roles.

En este caso me gustaría señalar que existe otro plugin, CaPa, excepcional y mucho más sencillo, que limita la visualización de páginas y de categorías de entradas a determinados roles. El problema de CaPa es que sólo trabaja con los roles por defecto de WordPress (a los que añade, por cierto, el muy conveniente rol visitante) y no reconoce nuevos roles que un administrador pudiera haber creado con otro plugin. Así pues, CaPa no reconoce los roles alumnoa, alumnob y alumnox, que creé anteriormente con User Role Editor, en tanto que Role Scoper sí.

2. Registro selectivo y login

Por defecto, WordPress permite el registro de usuarios con un rol predeterminado, el que queramos; por ejemplo, con el rol colaborador. Esto quiere decir que todos los usuarios que se registren en el sitio serán asignados por WordPress a ese rol y compartirán sus privilegios. Pero ¿qué ocurre si deseo que usuarios diferentes se registren con roles diferentes? En nuestro proyecto eso es precisamente lo que perseguimos: los usuarios de 1BATA deben registrarse con el rol alumnoa, los de 1BATB con el rol alumnob y los de 1BATX con el rol alumnox (aunque los tres roles tienen los mismos privilegios, cada uno podrá editar sólo las páginas de su aula, gracias a Role Scoper).

Supongamos que aceptamos la configuración por defecto de WordPress. Procederíamos así: permitimos que todos los usuarios se registren con el mismo rol (pues no hay otra alternativa). Luego, como administradores, cambiamos manualmente los roles y ponemos a cada alumno en el suyo: a los alumnos de humanidades se les asigna al rol alumnoa, a los de ciencias sociales el rol alumnob, etc. Esta opción puede ser aceptable para un número pequeño de alumnos, pero tediosa, o incluso inviable, para un número elevado.

Por lo tanto, la solución óptima sería que ya durante el proceso de registro hubiese algún modo de asignar automática y selectivamente roles. Ello liberaría al administrador de revisar todas las cuentas de usuarios y realizar manualmente la tarea. El plugin Simplr User Registration Form permite crear páginas de registro diferenciadas por roles, reconociendo como roles válidos cualesquiera creados por un administrador con otro plugin, como es nuestro caso. Puede verse Simplr User Registration Form en funcionamiento en cualquiera de las páginas de registro del proyecto, por ejemplo, en la de 1BATA http://francescllorens.eu/1bat1213/?page_id=24. Obsérvese que se muestra un formulario convencional de registro, con unos campos predeterminados. El registro tiene lugar mediante el envío de una contraseña aleatoria al correo del alumno, contraseña que puede ser cambiada desde el área de perfil de la plataforma, como es habitual en la mayoría de sistemas de registro en servicios web actuales. La cuestión es: ¿cómo sabe el sistema que el usuario registrado en esta página debe ser asignado al rol alumnoa y no a cualquiera de los otros dos roles?

La respuesta se halla en el modo en que opera Simplr User Registration Form. Una vez instalado y activado el plugin, el administrador debe introducir un pequeño código (un shortcode, en lenguaje de WordPress) en el post o página donde desea que aparezca el formulario de registro. Muchos plugins funcionan a través de shortocodes, en vez de a través de interfaces gráficas. Este código contiene el nombre del rol al que será asignado el usuario que se registre a través de ese formulario. En concreto, el shortcode para la página de registro de los alumnos de 1BATA es éste:

[Register role=”alumnoa”]

No es preciso hacer nada más. Sólo con escribir el shortcode en cualquier entrada o página, el formulario de registro aparecerá automáticamente allí. Para las otras dos páginas de registro (1BATB y 1BATX) sólo cambiaremos el nombre del rol, dejando el resto del shortcode como está. El efecto final es que los estudiantes serán automáticamente asignados a sus roles respectivos en función de la página en la que se hayan registrado.

Hay que distinguir el proceso de registro en el entorno del proceso de acceso al mismo, es decir, del “logueo” o login. Habitualmente utilizo en mis instalaciones Login with Ajax, un plugin ligero que sustituye a la típica pantalla de acceso de WordPress. Login with Ajax permite, además de la entrada al entorno a los usuarios ya registrados, efectuar el proceso de registro en sí mismo. Esta funcionalidad puede desactivarse y de hecho en mi proyecto está desactivada, dado que para el registro he utilizado, como se acaba de explicar, Simplr User Registration Form. Pero en proyectos en los que no se necesite un sistema automático de asignación de roles Login with Ajax cumple la función de mostrar un sencillo formulario de registro. También permite, como es común en este tipo de plugins, recuperar la contraseña olvidada. Una vez que el usuario se ha validado en el sistema, Login with Ajax muestra un enlace a su perfil mediante el cual modificar sus datos personales y la incómoda contraseña aleatoriamente generada por el sistema durante el proceso registro. En el área de administración o backend, el plugin crea una página de configuración en la que podemos indicar dónde deberán ser redireccionados los usuarios una vez logueados, o una vez hayan cerrado la sesión. En mi proyecto, Login with Ajax puede verse en acción haciendo clic sobre la flecha de la esquina superior izquierda de la pantalla, ya que el plugin ha sido “escondido” utilizando otro plugin de tipo caja deslizante, que explicaré al final.

 

>> Ir a WordPress para educación: cómo configurar un entorno flexible. Un artículo no solamente técnico (iii)

próximo puesto

Atrás puesto

© 2017 francescllorens.eu

Tema de Anders Norén