Gestión de archivos sin seguimiento en Drupal con File Inspector

Los sistemas de gestión de contenidos incluyen diferentes tipos de archivos como parte del contenido que manejan. Sin embargo, debido a varios motivos, la aplicación no siempre hace seguimiento de estos ficheros, lo que puede hacer que haya acumulación de ficheros sin uso y dar lugar a ciertos problemas. Esta artículo trata de este asunto y propone el módulo File Inspector como solución.

Los archivos de los que Drupal no hace seguimiento

Cualquier sitio Drupal con años de vida, ya almacene archivos en una carpeta local o en un bucket remoto como Amazon S3, acumula cientos de archivos sin forma fácil de saber de cuáles sigue Drupal haciendo seguimiento y de cuáles no. Los archivos provienen de cuatro fuentes: contenido activo, restos de nodos eliminados hace años, residuos de migraciones y copias de seguridad, y subidas directas, como un PDF se copió al servidor porque en su momento era "más rápido".

Es un problema habitual en el sector y no depende de la tecnología utilizada. Todo sistema de gestión de contenidos lo afronta tarde o temprano. La causa raíz son dos almacenes que deben coincidir: los datos en disco frente a la base de datos que se supone debe llevar un seguimiento de ellos. En cuanto ambos almacenes coexisten, se acaban desincronizando en algún momento. Esto ocurre de tres formas diferentes: cuando se eliminan registros en la base de datos pero no los archivos, cuando se suben archivos que nunca se registran en la base de datos, y, por último, cuando hay que procesos que fallan a media ejecución.

Estos archivos acumulados sin referencia son archivos sin seguimiento, una forma de datos oscuros: información que una organización conserva pero que ya no utiliza.

Coste de los archivos sin seguimiento

El primer coste es de almacenamiento y gobernanza, no solo espacio en disco. El segundo, más grave, es de exposición y seguridad. Un archivo sin seguimiento no siempre desaparece. En muchas configuraciones permanece físicamente presente, y cualquiera que conozca o descubra su URL puede descargarlo. Un documento eliminado del contenido puede seguir en el almacenamiento. Un archivo sensible subido directamente, ya sea por FTP, una migración u otro medio no llega a registrarse en Drupal. Queda expuesto en su URL pero ninguna pantalla de administración lo lista.

La gravedad depende del tipo de contenido: trivial para activos ordinarios, seria para contratos, datos personales o informes internos. Pero en cualquier caso la organización sigue siendo responsable de estos archivos que ni siquiera saber fácilmente que están ahí.

Cómo se manifiesta el problema en Drupal

Una file entity es el registro que Drupal mantiene de un archivo. Una media entity envuelve ese archivo con un tipo, metadatos y una identidad reutilizable. Es la forma recomendada de gestionar archivos en Drupal. Drupal, además, también registra dónde se usa cada archivo. Así, un archivo solo existe para Drupal a través de estos registros. Sin ese registro la aplicación no hace seguimiento del archivo, y por tanto no es gestionado en absoluto.

Este es el caso de los archivos no gestionados (unmanaged files): archivos en disco sin ninguna file entitya, y que por tanto Drupal no los ve. Dado que nada los referencia, nada los gobierna y ninguna pantalla los lista.

Existe otro caso: archivos conocidos por Drupal pero no usados en ningún sitio. Los archivos gestionados huérfanos (orphaned managed files) son este caso. La file entity existe, pero el contador de uso está a cero, normalmente porque se eliminó el nodo o media item que lo utilizaba. Drupal conoce el archivo, pero por defecto no lo elimina aunque no tenga usos.

En cualquier caso, el almacenamiento se va llenando poco a poco, y actualmente no hay ninguna pantalla de administración que reconcilie los archivos presentes en disco con las entidades gestionadas por Drupal.

Qué hacen los módulos existentes y dónde se quedan cortos

Existen otros módulos que abordan este problema, pero conviene saber hasta dónde llegan:

• Fancy File Delete elimina tanto archivos no gestionados como cfile entities desvinculadas. Funciona mediante Drush y la interfaz de Drupal, pero está más orientado a perfiles técnicos y solo permite borrar.
• Audit Files es el pariente más cercano. Sus informes cruzan almacenamiento, file entities, uso y referencias de contenido, e incluso puede añadir un archivo no gestionado a la base de datos. Pero solo crea una file entity básica, sin registro de uso ni presencia en la Media library, así que el archivo acaba siendo conocido pero inutilizable directamente. Drupal se entera de que el archivo existe, pero el archivo, al no estar metido en un media, no es usable. También parece estar orientado a perfiles técnicos y su mantenimiento ha sido intermitente.

Así que ambos comparten algo: son herramientas orientadas a perfiles técnicos cuya respuesta es borrar o registrar a medias. Ninguno lleva el archivo a una gestión completa como activo reutilizable, y ninguno se dirige a quien edita o construye el sitio y es responsable del contenido.

Los principios detrás de File Inspector

File Inspector hace tres cosas respecto al problema descrito: inventaría todo lo que hay en el almacenamiento, reconcilia cada archivo con lo que Drupal gestiona, y permite eliminar los huérfanos sin uso o convertir archivos aún útiles en entidades Media gestionados. Todo esto desde una interfaz amigable, no desde la línea de comandos, y esa interfaz es su principal factor diferenciador. Se apoya en varios principios:

• Visibilidad antes de actuar: parte de un inventario fiable de archivos y su estado, porque nada se puede gestionar, eliminar ni gobernar mientras sea invisible. Una vez localizados se actúa.
• Reconciliar, no solo borrar: muchos archivos son activos reales que nunca fueron registraron, así que la solución debe ser permitir que sean gestionados, envolviendo el archivo en una media entity en lugar de una file entity básica y difícil de usar o no usable para nada, de forma que pueda encontrarse y colocarse como cualquier otro activo.
• Pensado para editores y site builders, no solo para perfiles técnicos: provee informes y acciones claras en la interfaz, con filtros, batch operations y permisos adecuados, para que actuar sobre los archivos sea seguro sin necesidad de tocar código o la consola.
• Escala: los sitios reales albergan decenas o cientos de miles de archivos, así que el inventariado debe ejecutarse sin agotar la memoria ni provocar timeouts.
• Consciente de casos sutiles: los minisitios incrustados, como flipbooks HTML o micrositios estáticos, están compuestos por muchos archivos. Tratar cada archivo uno de los archivos como un fichero huérfano independiente generaría un ruido innecesario, así que la herramienta debe entender este tipo de estructuras.
• Alcance: se centra deliberadamente en los archivos no gestionados (unmanaged) que Drupal no puede ver, recorriendo el sistema de archivos y etiquetando cada uno como gestionado o no gestionado. Los archivos gestionados huérfanos se dejan a herramientas existentes del lado de entidades. File Inspector se ocupa de los archivos que Drupal nunca no sabe que existen.

Cómo funciona File Inspector

Los pasos para usarlo son los siguientes:

1. Configurar el módulo: un formulario de configuración para dirigir el objetivo del inventariado. Se eligen los tipos MIME a inspeccionar (imágenes, PDF, documentos de Office, o image/*), las carpetas a excluir (carpetas de activos y del sistema como css, js y styles), y las carpetas que contienen web incrustadas (los minisitios mencionados antes). Dos interruptores controlan si se ofrecen las opciones de eliminar e importar a Media.

2. Generar el informe: un tamaño de batch para ajustar cuántos archivos se procesan por pasada. El escaneo itera con generadores y el Batch API, inventariando archivos sin consumir demasiada memoria. Los resultados se almacenan en una tabla dedicada en lugar de recalcularse en cada vista.
    

   

3. Leer el informe, resumen y listado de archivos: la página de resumen es un informe fácil de leer, con el inventario reconciliado frente a las entidades gestionadas. Tiene dos pestañas: Overview muestra un total general por estado (gestionado, no gestionado o importado), y el listado de archivos muestra cada uno de los archivos encontrados.

   

4. Filtrar y actuar con Views: el informe está construido sobre Views: se puede filtrar por estado, tipo MIME o fecha, ejecutar operaciones masivas, y al ser una vista puede ser modificad mediante el interfaz estándar de Views. Esto ataca permite que el módulo no esté "pensado solo para técnicos".
    

   

5. Reconciliar cada archivo: se decide si eliminar un archivo o importarlo como media item. Para un archivo no gestionado que merece conservarse, se promueve a una entidad Media gestionada, eligiendo el tipo de media. Esto crea tanto la file entity como el Media item, que aparece en la Media library, y registra la relación entre la fila del informe y el Media producido. El archivo se convierte en un activo reutilizable, no solo registrado.
    

   

Conclusión

La desincronización entre almacenamiento y base de datos es universal, y acarrea costes reales en almacenamiento, gobernanza y confianza. Drupal solo la hace concreta: los archivos acaban sin entidad, invisibles para el sistema que debería hacer seguimiento de ellos. Las herramientas existentes están más orientadas a perfiles técnicos, y la solución ofrecida es borrar o registrar a medias.

File Inspector adopta un enfoque diferente, en cuatro puntos: inventariar primero; reconciliar hasta llegar a un Media item utilizable; hecho para quienes gestionan el contenido; escalar en sitios reales con mucho contenido. De esta forma, ahora existe una forma accesible para todos los usuarios, independientemente de su perfil, de gestionar archivos no rastreados en Drupal.