filefill para TYPO3

filefill ahorra a desarrolladores y agencias días de sincronización: la extensión carga automáticamente los archivos faltantes del fileadmin desde el servidor de producción cuando realmente se necesitan

Quien trabaja en un proyecto TYPO3 existente conoce el ritual: el setup local está listo, el dump de base de datos importado, pero en cada segunda página aparecen placeholders en lugar de imágenes. La causa es banal: el directorio fileadmin del sistema en producción contiene gigabytes de assets que faltan localmente. La solución clásica eran rsync o scp durante horas. filefill elimina ese paso por completo. En lugar de copiar todos los archivos de antemano, la extensión carga en el primer acceso exactamente el archivo necesario desde el servidor remoto configurado: bajo demanda, de forma transparente, con caching. Para agencias que trabajan de forma permanente en varios proyectos, eso no solo ahorra almacenamiento, sino horas por cada setup.

La ganancia de productividad es mayor de lo que parece a primera vista. Un nuevo desarrollador no es operativo solo tras una hora de espera de descarga, sino tras pocos minutos. Una revisión de código sobre una rama de feature olvidada no necesita una sincronización de archivos actualizada. Una breve reproducción de un bug no se alarga durante medio día. La pequeña extensión aborda, por tanto, un cuello de botella real del trabajo diario del desarrollador.

Escenarios típicos de uso

El caso más frecuente es el setup de desarrollo local. Un desarrollador clona el proyecto TYPO3, configura DDEV o Docker e importa el dump actual de base de datos. En lugar de descargar además 30 GB de datos fileadmin, configura filefill con la URL base del sistema en producción. En cada petición de página que requiera una imagen o documento, la extensión comprueba si el archivo existe localmente y, si hace falta, lo carga. Tras unos pocos días de trabajo, solo los archivos realmente necesarios están en local; el resto permanece en el servidor.

El segundo caso son los entornos de staging. Una agencia mantiene para cada proyecto un sistema de staging en el que los redactores prueban contenidos antes del pase a producción. Esos sistemas de staging no necesitan guardar todas las imágenes, sino solo las de los releases actuales. filefill garantiza que los contenidos más antiguos sigan funcionando porque los archivos se tiran del sistema en producción bajo demanda.

Tercer uso: disaster recovery y escenarios de hotfix. Cuando un sistema TYPO3 debe levantarse rápidamente en una máquina nueva - tras una caída de servidor o en una migración urgente de entorno - filefill puede cubrir durante las primeras horas el aprovisionamiento de activos mientras se completa la restauración total del backup.

Arquitectura técnica

filefill se engancha al sistema FAL de TYPO3, más en concreto al mecanismo de retrieval de recursos. En cuanto TYPO3 solicita un archivo desde el storage local y constata que no existe, un EventListener de filefill interviene. La extensión comprueba una lista de “sources” configuradas por orden de prioridad e intenta cargar el archivo desde allí. Los archivos cargados con éxito se almacenan localmente, de modo que el siguiente acceso no necesite petición remota.

La configuración se realiza mediante los ajustes de la extensión en el Install Tool. Típicamente se registra una source remota con URL base, opcionalmente con credenciales HTTP Basic Auth. Para setups con CDN o S3 también ese path puede servir como fuente. La extensión soporta varias sources, lo que es útil para escenarios más complejos con servidores de activos separados.

Es importante que filefill trabaje solo de forma pasiva. La extensión no carga nada por adelantado, sino que reacciona exclusivamente a peticiones concretas de archivos. Eso la hace frugal en consumo de recursos y discreta en operación. La integración con DDEV, Docker Compose o Lando es trivial, porque la extensión no necesita servicios adicionales.

Problemas frecuentes y soluciones

El primer problema son las restricciones de acceso. Cuando el servidor en producción entrega imágenes solo para usuarios logueados o protege determinadas rutas por htaccess, filefill no puede recargarlas sin más. La solución está en la configuración correcta de la autenticación HTTP y, si hace falta, en una regla de whitelist en el servidor en producción que dé al entorno de desarrollo acceso al path fileadmin.

Segundo problema: uso accidental en producción. Si filefill está activo en un entorno live y la source remota es el mismo entorno, se produce una recursión peligrosa. La extensión nunca debería correr en producción. La solución pragmática es mantener filefill solo en el bloque Composer “require-dev” y activarlo mediante variables de entorno, no por el Install Tool.

Tercer problema: estados de archivo inconsistentes. Cuando el sistema en producción sustituye un archivo pero la copia local ya está cacheada, el desarrollador ve la versión antigua. La solución es un vaciado ocasional del fileadmin local o un cache busting mediante la source remota. Para el trabajo diario rara vez es un problema, porque los nombres de archivo al sustituir suelen ser nuevos.

Migración y compatibilidad de versiones

filefill es compatible con TYPO3 v11, v12 y v13 y se sigue desarrollando activamente. En los upgrades, la versión de la extensión debería encajar con la versión de TYPO3, porque el sistema de eventos del FAL ha experimentado pequeños cambios entre v11 y v12. Quien usa la extensión en procesos de desarrollo existentes debe probar brevemente en upgrades mayores si todas las sources siguen siendo accesibles correctamente.

Una solución relacionada es EXT:aus_driver_amazon_s3, que mantiene fileadmin directamente en un bucket S3. La diferencia: aus_driver_amazon_s3 es una solución de producción, filefill es una ayuda de desarrollo. Ambas se complementan: un proyecto con storage S3 en producción puede usar filefill localmente para tirar del bucket solo los archivos que se están editando.

Para agencias que usan filefill de forma estandarizada, merece la pena una documentación en el wiki del proyecto que explique cómo se activa la extensión, qué credenciales hacen falta y cómo proceder ante problemas. Eso reduce la carga de soporte en el equipo y hace el onboarding de nuevos desarrolladores fiable. De forma complementaria, vale la pena un script corto que, al montar un nuevo entorno local, inserte automáticamente la configuración correcta.

Gosign instala y configura filefill en entornos de desarrollo e integra la extensión en setups DDEV y Docker, de modo que los nuevos miembros del proyecto sean operativos en pocos minutos.