Funcionalidades de un sitio privado para docentes: gestión de usuarios y contenido condicional

Tras examinar en el artículo anterior el concepto de sitio privado y explicar cómo se puede activar el contenido restringido y gestionar la autenticación de usuarios mediante un servidor externo, nos ocuparemos a continuación el resto de funcionalidades aconsejables para un sitio privado destinado exclusivamente a los docentes: la gestión de usuarios mediante roles personalizados y grupos de usuarios, la creación de contenido condicional, y otras funcionalidades de interés.

Gestión de usuarios. Roles personalizados y grupos de usuarios

A la hora de trabajar con un sitio de contenido privado o restringido, es muy importante tener en cuenta el sistema de roles y capacidades de WordPress, el cual determina qué pueden hacer cada uno de los usuarios de la aplicación. Resumiéndolo en sus rasgos esenciales, este sistema cuenta con cinco roles de usuario, que exponemos a continuación en orden decreciente de jerarquía:

• Administrador: en las instalaciones normales de WordPress es el usuario de máximo nivel, que dispone de todas las capacidades posibles. En las instalaciones multisitio, sin embargo, no puede hacerlo todo, ya que le están vedadas ciertas capacidades que afectan a la gestión del multisitio; por ejemplo, no puede instalar temas y plugins, crear o borrar sitios, administrar el multisitio, etc.
• Editor: puede crear y publicar y editar sus propias entradas, así como las entradas de los demás usuarios.
• Autor: solo puede crear, publicar y editar sus propias entradas.
• Colaborador: puede crear y editar sus propias entradas, pero no puede publicarlas; esta última tarea corresponde a un usuario con rol de editor o administrador.
• Suscriptor: es un usuario registrado de mínimo nivel, que solo puede consultar su propio perfil.

Además, en las instalaciones multisitio de WordPress existe lo que se denomina superadministrador, que es un administrador con varias capacidades adicionales: puede hacerlo todo, en cualquiera de los sitios de una instalación multisitio, y también puede administrar el propio multisitio.

Si se utiliza un sistema que permita autenticarse a los usuarios con las credenciales almacenadas en un servidor externo, es esencial que el rol atribuido por defecto a los usuarios sea el más bajo posible, para impedir de este modo que un usuario inexperto o excesivamente aventurero haga lo que no debe. Por tanto, conviene asignar por defecto a todos los usuarios que se autentiquen por LDAP el rol de suscriptor. Tiempo habrá, posteriormente, de modificar el rol de aquellos usuarios que deban tener capacidades más potentes.

Roles personalizados

En ciertas circunstancias, es posible que un sitio web de contenido privado o restringido exija modificar los roles que acabamos de citar, bien para crear nuevos roles, bien para cambiar las capacidades asignadas a los roles por defecto de WordPress. Por ejemplo, puede ser necesario contar con uno o varios profesores que desempeñen un rol específico, con las capacidades propias de un autor, más alguna de las capacidades exclusivas de un editor (algo así, como un “autor mejorado”). Pues bien, para esta tarea -muy delicada, y que no debe llevarse a cabo sin tomar las debidas precauciones- hay dos plugins que vienen como anillo al dedo: el ya citado Members y User Role Editor. Cualquiera de los dos permite definir nuevos roles o modificar los ya existentes. Incluso permiten definir capacidades personalizadas, aunque para ello es necesario programar las correspondientes funciones.

Grupos de usuarios

Cuando en un sitio web están dados de alta muchos usuarios, es frecuente que surja la necesidad de distribuirlos en varios grupos. Pues bien, para lograr esta funcionalidad también existen numerosos plugins, de entre los cuales recomendamos User Groups o Groups. El primer plugin solo permite definir y gestionar grupos de usuarios; el segundo, mucho más completo, proporciona además la posibilidad de gestionar capacidades, asignar permisos de contenido, etc.

Contenido condicional

En un sitio de contenido privado o restringido es posible no solo definir condiciones globales, como “nadie puede acceder a ningún contenido si no es un usuario registrado”, sino también condiciones más precisas, del tipo “solo los usuarios con el rol X podrán ver el contenido Y”. Por otro lado, hay que tener en cuenta que, cuando hablamos de contenido de un sitio web, no solo nos referimos a las entradas, páginas y otros tipos de contenido, sino también a elementos como menús, widgets, áreas de widgets, etc. A continuación veremos cómo se pueden configurar todos estos elementos para impedir que sean visibles por parte de visitantes o usuarios no deseados.

Menús condicionales

Aunque un sitio web sea enteramente privado, y aunque su contenido sea inaccesible para usuarios no registrados, los enlaces que forman parte de los menús siguen siendo visibles, lo cual puede dar pistas sobre el contenido del sitio a visitantes no deseados. Si se quiere proteger dichos elementos, hay que utilizar plugins diseñados a tal efecto. A continuación explicaremos el uso de dos complementos distintos, Nav Menu Roles y Conditional Menus, que permiten precisar las circunstancias en virtud de las cuales deben ser visibles los elementos individuales de menú, en el primer caso, y los menús completos, en el segundo.

Una vez activado el plugin Nav Menu Roles, cada elemento de menú dispone de opciones adicionales, que sirven para precisar las circunstancias en que dicho elemento es visible, y qué roles de usuario pueden ver dicho elemento. En la figura 1 se muestra un elemento de menú cuya visibilidad ha sido restringida solo a los usuarios suscriptores; las figuras 2 y 3, por su parte, muestran la página principal de un sitio web privado en dos circunstancias diferentes: con todos los elementos de menú visibles para los usuarios no registrados (figura 2), y con algunos elementos de menú -la categoría “Noticias” y la página “Página 1”- ocultos para dichos usuarios (figura 3).

Con el plugin Conditional Menus es posible configurar un sitio web privado con varios menús enteramente diferentes, en función de las circunstancias de los usuarios que lo visitan. Para el ejemplo de sitio web privado que estamos desarrollando, hemos definido dos menús distintos:

• El “menú para usuarios registrados”, que contiene 4 enlaces, tal como muestra la figura 2.
• El “menú para usuarios no registrados”, que contiene un único enlace, tal como muestra la figura 4.

La configuración es muy simple: basta con establecer, mediante las funciones del plugin Conditional Menus, una única condición: que el “menú para usuarios registrados” solo se muestre cuando los usuarios han iniciado sesión, tal como aparece en la figura 5. En todas las demás circunstancias, se mostrará el “menú para usuarios no registrados”.

Quienes deseen ver un ejemplo concreto y práctico de uso de este plugin (aunque no relacionado con la gestión de contenido privado o restringido) pueden recorrer la web del CREENA. Este stiio web ha optado por definir un gran número de menús, mediante los cuales se organiza el acceso al contenido de sus diversas áreas.

Widgets condicionales

Restricciones semejantes a las que hemos aplicado a los elementos de menú y a los menús completos se pueden definir también en los widgets individuales. Para ello hay que utilizar plugins como Widget Logic, Widget Options, Dynamic Widgets, Widget Context, Widgets Control o incluso el módulo Visibilidad de widgets del plugin Jetpack, que sirven para aplicar condiciones a cada widget. Para comprender su funcionamiento, lo mejor es analizar un ejemplo de uso del plugin Widget Logic, que describimos a continuación.

Si queremos conseguir que los widgets de búsqueda y archivos del sitio (véase la figura 2), sean invisibles para los usuarios que no han iniciado sesión, basta con añadir una condición específica al campo que el plugin Widget Logic añade al final de la caja de configuración de ambos widgets, tal como se muestra en la figura 6. La condición que hemos definido para tal propósito es is_user_logged_in(). Para más información sobre las condiciones que se pueden aplicar mediante este plugin, véase la completísima documentación sobre las denominadas conditional tags o etiquetas condicionales de WordPress.

El resultado de esta acción es una página sin los dos widgets que acabamos de reconfigurar y cuyo contenido, por tanto, está casi totalmente protegido de miradas indiscretas, tal como puede comprobarse en la figura 7. En efecto, la captura de pantalla muestra los elementos de información imprescindibles para quienes acceden al sitio privado: su título y descripción, un párrafo que define la naturaleza restringida del sitio, un único elemento de menú (que también se podría eliminar, pues resulta redundante) y el formulario de inicio de sesión,. En cuanto los usuarios introduzcan en en él sus credenciales de usuario, ya podrán ver la página completa, tal como aparece en la figura 8.

Áreas de widgets o barras laterales condicionales

No solo se pueden aplicar restricciones a los widgets individuales, sino también a las áreas de widgets o barras laterales en su conjunto. Aunque en este curso no vamos a considerar esta funcionalidad, ya que resulta excesivamente compleja para la mayoría de los casos, los interesados en conseguirla pueden acudir a plugins gratuitos como Custom Sidebars o Content Aware Sidebars, o sus “hermanos mayores”, de pago y mucho más potentes: Custom Sidebars Pro (el PNTE dispone de una licencia, por lo cual los centros pueden solicitar su instalación) y Content Aware Sidebars Pro.

Elementos condicionales de contenido

El último aspecto del contenido condicional que vamos a examinar es la restricción de acceso para elementos de contenido que forman parte de entradas o páginas. Es decir, explicaremos cómo se puede conseguir que los visitantes de un sitio puedan ver solo parte del contenido de un artículo concreto. Para ello, se pueden utilizar muchos plugins, aunque por su simplicidad de concepto y uso hemos decidido seleccionar el plugin Restrict Content, versión gratuita del celebérrimo Restrict Content Pro.

Para explicar su uso, nada mejor que mostrar un ejemplo del sitio web privado para profesores que hemos propuesto a modo de práctica: supongamos que deseamos que en la página de inicio de este sitio web aparezca una información visible para todos los visitantes, pero que en la misma página aparezca un bloque de información que solo deben ver los usuarios registrados. Pues bien, podemos definir dicho bloque con un simple shortcode, del siguiente modo:

[restrict]Bloque de información para usuarios que han iniciado sesión.[/restrict]

Si queremos precisar más el rol de usuarios que tendrán acceso a dicho bloque, podemos añadir un parámetro con el rol de usuario, del siguiente modo:

[userlevel="editor"]Bloque de información que solo verán los usuarios con el rol mínimo de editor.[/restrict]

También podemos conseguir el efecto contrario, es decir, crear un bloque de contenido que solo esté accesible para los usuarios que no han iniciado sesión. En este caso, el shortcode será el siguiente:

[not_logged_in]Este bloque de información solo se muestra a los usuarios que no han iniciado sesión.[/not_logged_in]

Estos shortcodes se pueden combinar para crear artículos que tengan bloques de contenido de visibilidad diferenciada: unos contenidos serán visibles para los visitantes normales, y otros solo para los usuarios registrados. De esta manera, el mismo artículo sirve para distintos propósitos, lo cual resulta muy útil. Un ejemplo de uso de los shortcodes puede verse en la figura 9:

El plugin Restrict Content no solo permite limitar el acceso a bloques de información, sino a todo un artículo. Para ello, dispone de una caja de metadatos que se añade al interfaz de edición de WordPress (véase la figura 10). No obstante, esta función resulta redundante si hemos utilizado un plugin como Authorizer, destinado a crear un sitio enteramente privado, tal como explicamos en el artículo anterior.