Gestores de descargas para WordPress 4: WP-Filebase en entornos multiusuario

En el artículo anterior de esta serie, glosé las posibilidades que el plugin WP-Filebase Download Manager ofrece como herramienta integral para subir archivos al blog y gestionar sus descargas. Pues bien, me interesa ahora profundizar en el análisis de las capacidades de esta extensión bajo dos circunstancias que hacen muy aconsejable su uso, esto es, en sitios web con múltiples usuarios, por una parte, y en entornos multisitio o multiblog, por otra. En este artículo analizaré cómo se comporta la extensión en una configuración de múltiples usuarios, y en una próxima entrega de la serie daré cuenta de su funcionamiento en una instalación multisitio de WordPress.

A diferencia de otros plugins de gestión de descargas (como por ejemplo el WordPress Download Monitor), WP-Filebase no define ninguna capacidad nueva, y por tanto asume como propia la estructura de roles y capacidades de WordPress, en virtud de la cual los usuarios administradores, editores y autores tienen la capacidad de subir ficheros (upload_files). Por tanto, su funcionamiento en entornos multiusuario sigue los patrones de dicha aplicación a la hora de definir qué usuarios tienen la capacidad de llevar a cabo las acciones que se detallan a continuación. Conviene aclarar que, aunque WordPress no distingue entre frontend y backend a la hora de establecer la mayor parte de sus capacidades, yo sí lo he hecho, con el único propósito de conseguir una mayor claridad expositiva:

1. Configurar el plugin desde el backend: solo los administradores pueden modificar las opciones de la extensión.
2. Subir ficheros desde el frontend o desde el backend: estas acciones pueden ser realizadas por los administradores, editores y autores.
3. Gestionar ficheros desde el backend: tienen capacidad para llevar a cabo esta tarea los administradores, editores y autores.
4. Crear categorías de ficheros desde el frontend: tanto los administradores como los editores y autores tienen tal capacidad.
5. Crear y gestionar categorías de ficheros desde el backend: es una tarea solo disponible para administradores y editores.
6. Insertar listados de fichero desde el backend, mediante el editor del blog: esta acción puede realizarla cualquier usuario registrado con derecho a crear contenido, esto es, los administradores, editores, autores y colaboradores.
7. Descargar ficheros desde el frontend: en la configuración por defecto del plugin, esta acción puede llevarla a cabo cualquier cualquier visitante del sitio. No obstante, es posible configurar las categorías de ficheros, y también los ficheros individuales, para restringir su acceso a un rol determinado. Desde la versión 0.2.9.4 también es posible definir los ficheros como privados, situación en la que solo puede acceder a un fichero el usuario que lo ha subido y el administrador del sitio.

Esta relación entre las tareas que se pueden llevar a cabo con el plugin WP-Filebase y los roles de usuario de WordPress es sin duda muy potente, y en general está bien estructurada, pero no carece de ciertos puntos discutibles, a saber:

• Que los administradores y editores puedan editar y borrar los ficheros subidos por otros usuarios es coherente con la organización general de WordPress. Ahora bien, el hecho de que los autores también dispongan de esta capacidad constituye una circunstancia que, si no ha sido advertida por el administrador, puede ser causa de un funcionamiento no deseado del sitio web, ya que un usuario (por ejemplo, un autor) puede borrar ficheros que hayan sido subidos por usuarios que tienen más capacidades (por ejemplo, editores o administradores).
• Que los autores disfruten de la capacidad de crear categorías de ficheros desde el frontend parece una innovación del plugin con respecto a la configuración por defecto de WordPress, que solo permite crear y gestionar categorías de entradas y enlaces (en esto consiste la capacidad manage_categories) a los administradores y los editores. No obstante, debe advertirse que, aunque un autor pueda crear categorías desde el frontend, carece de cualquier control para ajustar sus características y comportamiento desde el backend. En todo caso, creo que es una buena idea que un autor pueda crear categorías de ficheros desde el frontend, pues ello dota al sistema de mayor flexibilidad, siempre que dicha circunstancia sea bien conocida por el administrador del sitio web.
• El plugin dispone de la capacidad de restringir los ficheros y las categorías de ficheros a uno o varios roles de usuarios, lo cual es muy útil para prevenir que un usuario de bajo nivel puede borrar o modificar ficheros y categorías creadas por un usuario de nivel de usuario superior. La desventaja de esta función es que, si se configura una categoría o un fichero para que solo sea accesible por determinados roles de usuario, tal característica afecta tanto al backend como al frontend, lo cual impide que una categoría de ficheros, o un fichero concreto, sean visibles y descargables desde el sitio web por parte de usuarios con roles diferentes. Por otra, parte, esta capacidad puede volverse en contra de los usuarios; por ejemplo, se da la paradoja de que un autor puede acceder desde el backend a un fichero que no está restringido para ningún rol y modificarlo de forma que solo esté disponible para otros roles que el suyo, con lo que lo convierte en inaccesible para sí mismo.
• La posibilidad de convertir los ficheros en privados solo puede activarse para todo el sitio web; es decir, no cabe decidir a qué ficheros se aplica. No hace falta insistir en el hecho de que esta característica puede ser muy interesante en ciertas situaciones, pero también puede volverse en contra de los usuarios si no se maneja con sentido común.

El plugin WP-Filebase no proporciona por sí mismo ningún control sobre la forma en que se presentan a los usuarios las acciones que estos pueden ejecutar desde el frontend. Es decir, solo con el plugin WP-Filebase no se puede escoger que, por ejemplo, los widgets para subir ficheros, crear categorías y generar listados de ficheros y de categorías solo aparezcan en determinadas páginas, o para determinados usuarios y no para otros. No obstante, estas limitaciones se pueden subsanar con bastante facilidad mediante diversos plugins, a saber:

• Members, para limitar el acceso a la página solo a aquellos roles que el administrador haya decidido y proporcionar un mensaje de advertencia en caso de que no se dé tal circunstancia.
• Widget Logic, para obligar a que los widgets sean visibles solo en las condiciones deseadas.

He llevado a cabo buen número de pruebas con los tres plugins, y no he encontrado ninguna incompatibilidad o limitación que impida poner en práctica cualquier combinación concebible entre las funciones de las tres extensiones. Por ejemplo, en el blog al que corresponden las capturas de pantalla de este artículo, elaborado con el tema Graphene, he publicado los widgets de subida de ficheros y creación de categorías de ficheros bajo las siguientes condiciones: en primer lugar, ambos widgets solo deben aparecer en la página denominada “Subida de ficheros”; en segundo lugar, los dos widgets solo deben aparecer cuando el usuario que se conecta al blog sea un administrador o un editor. En caso de que no concurran ambas condiciones, aparecerá una advertencia de error.

Pues bien, para conseguir este efecto, he utilizado los plugins Widget Logic y Members, del siguiente modo:

• • Mediante el plugin Members he restringido la visibilidad de la citada página a los administradores y editores. De este modo, solo los usuarios que tengan estos roles podrán subir ficheros y añadir categorías de ficheros, mientras que los demás usuarios y los visitantes del blog verán un mensaje de advertencia: «Esta página solo está disponible para usuarios administradores o editores». La configuración de las opciones del plugin Members para la página “Subida de ficheros” puede observarse en la figura 1.
  • Con el plugin Widget Logic he conseguido que los widgets de subida de ficheros y creación de categorías de ficheros sean visibles en la citada página y solo para usuarios administradores y editores, para lo cual he utilizado las etiquetas condicionales is_page y current_user_can. La primera está asociada al identificador del artículo (el 1034); la segunda, a la capacidad edit_other_posts, que es exclusiva de los dos roles mencionados. Las dos condiciones están unidas mediante el operador lógico “&&”, lo cual significa que los dos widgets solo se mostrarán si se dan, a la vez, ambas condiciones (figura 2).

Las figuras 3-5 muestran el efecto simultáneo de ambos plugins, en tres circunstancias diferentes:

• Cuando el usuario conectado es el administrador, tiene acceso a los widgets (figura 3).
• Cuando se trata de un autor, no lo tiene (figura 4).
• Cuando es un simple visitante del blog, tampoco se le concede dicha capacidad (figura 5).

Como puede verse en estas capturas de pantalla, los demás widgets del blog aparecen siempre, puesto que no se les ha aplicado ninguna restricción.

Una última observación: la zona de widgets que puede advertirse en la figura 2, denominada “Graphene After Post Content”, es una característica muy interesante del tema Graphene, que permite activar áreas de widgets asociadas a determinados lugares del blog, mediante los denominados action hooks. Yo he utilizado el action hook denominado “graphene_after_post_content”, asociado al fichero loop.php del tema, con el cual es posible incluir widgets tras el contenido de un artículo, donde hay mucho más espacio que en la barra lateral.

Queda claro, pues, que con el plugin WP-Filebase, en combinación con un tema que sea suficientemente flexible, y aliado con otras extensiones que permitan una gestión más afinada de usuarios y permisos que la que WordPress proporciona por sí mismo, ofrece enormes posibilidades para la gestión de la subida y la descarga de ficheros. Animo a los lectores y lectoras de este blog a probarlo, y les brindo mi ayuda y colaboración, si la necesitan.