dp_cookieconsent para TYPO3: Gestión de cookies conforme con el RGPD

Por qué un banner de cookies por sí solo no garantiza el cumplimiento del RGPD

Cualquier instalación TYPO3 que integre Google Analytics, vídeos de YouTube, plugins de redes sociales o fuentes tipográficas externas se enfrenta, desde la entrada en vigor del RGPD y la LSSI, a la misma tarea: antes de cargar un script de terceros debe existir un consentimiento activo e informado del usuario. En España, la AEPD verifica estas exigencias regularmente en inspecciones y advierte expresamente sobre banners que solo son decorativos. dp_cookieconsent es la extensión más extendida en la comunidad TYPO3 que se ocupa exactamente de esa tarea. Se dirige a empresas que quieren operar su web conforme al RGPD sin una herramienta externa de gestión de consentimiento, y por tanto a pymes, administraciones y centros educativos que no quieren asumir costes recurrentes de CMPs comerciales.

Escenarios típicos de uso

Una empresa industrial con catálogo de productos y 45 landing pages utiliza Google Analytics, un vídeo explicativo en YouTube, formularios de HubSpot y Google Fonts. Sin dp_cookieconsent, todos esos servicios establecerían cookies en cuanto un usuario abriera la página, arriesgando un procedimiento sancionador de la AEPD. La extensión agrupa los servicios por categoría, carga el código de HubSpot solo tras el consentimiento de marketing y sirve Google Fonts de forma alternativa autoalojada, con lo que la solicitud de consentimiento allí desaparece por completo.

Un segundo cuadro típico lo ofrece una universidad como la UAM o la UCM con un portal principal y varios sitios web de facultad descentralizados. Cada facultad mantiene sus propios contenidos e integra sus propios servicios: a veces un mapa incrustado de OpenStreetMap, a veces un vídeo de YouTube, a veces un tracking de Piwik. dp_cookieconsent centraliza la gestión del consentimiento en la instalación principal, entrega el banner mediante Fluid Partials a todos los subsitios y almacena el consentimiento de forma interdominio, de modo que un usuario no tiene que volver a aceptar en cada sitio de facultad.

Un tercer caso son las administraciones municipales con formularios en línea y aplicaciones cartográficas. Aquí se añade la complicación de que la AEPD y las agencias autonómicas de protección de datos realizan inspecciones periódicas y exigen documentación completa de los servicios empleados. dp_cookieconsent entrega la categorización y el texto de privacidad directamente desde TypoScript, lo que permite que la redacción mantenga los datos sin intervención de un desarrollador.

Arquitectura técnica: bloqueo de scripts a nivel de template

dp_cookieconsent trabaja según el principio de “type attribute swapping”: todos los scripts de terceros en el código fuente no se entregan con type=“text/javascript”, sino con un tipo neutro como type=“text/plain” y un atributo data-cookieconsent adicional. El navegador ignora esas etiquetas y no las ejecuta. Solo cuando el usuario acepta en el banner, un pequeño runner JavaScript reemplaza los atributos de tipo y dispara la ejecución diferida. El mismo mecanismo se aplica a los iframes, que hasta el consentimiento se muestran como marcadores de posición.

La extensión se configura por completo mediante constantes y setup de TypoScript, complementados con un archivo YAML para las definiciones de servicios. Cada servicio está ahí definido con nombre, descripción, categoría, nombre de cookie y duración de cookie, lo que simplifica considerablemente la posterior documentación para el responsable de protección de datos. Fluid Partials definen la apariencia del banner y del modal de ajustes, con lo que el diseño puede adaptarse a la identidad corporativa sin modificar la extensión.

Problemas frecuentes y soluciones

El primer y más frecuente problema: a pesar del banner activado, los scripts de terceros siguen cargándose porque están integrados a través de rutas de inclusión que no pasan por TypoScript. Son típicos los bloques HTML estáticos, los elementos de contenido Fluid con etiquetas de script hardcodeadas o los includes de footer de plantillas antiguas. Una solución limpia requiere un crawling completo del sitio con las devtools del navegador o con una herramienta automatizada que registre todas las peticiones salientes y compare cuáles se disparan antes del consentimiento.

El segundo problema es el almacenamiento del consentimiento. dp_cookieconsent guarda el consentimiento en una cookie local, lo que provoca que usuarios con configuración estricta del navegador o en modo incógnito vean el banner repetidamente. Quien quiera medir las tasas de consentimiento debe activar adicionalmente un logging del lado del servidor que deposite los consentimientos junto con timestamp y hash de IP en una tabla de base de datos, entregando así documentación sólida para auditorías.

El tercer tema afecta al rendimiento. El banner carga un bundle JavaScript que, según el número de servicios configurados, puede llegar a ser notablemente grande y retrasar el First Contentful Paint. Gosign optimiza la entrega mediante deferred loading, reduce Fluid Partials innecesarios y apuesta, siempre que es posible, por una combinación de analítica sin cookies y assets autoalojados, de modo que el banner solo sea necesario para unos pocos servicios.

Un cuarto problema aparece con los cambios de consentimiento: un usuario otorga su consentimiento, usa la página, cambia de opinión más tarde y revoca la autorización. dp_cookieconsent reinicia el flag de la cookie, pero los scripts ya cargados siguen funcionando en segundo plano hasta que el usuario recarga la página. Una solución limpia requiere un trigger de recarga o la eliminación selectiva de cookies ya establecidas al revocar, de modo que la revocación de consentimiento sea realmente efectiva y no solo quede formalmente documentada.

Migración y compatibilidad de versiones

dp_cookieconsent está disponible para TYPO3 v11, v12 y v13, y la compatibilidad con v13 se actualiza regularmente y se considera actualmente apta para producción. El salto de v11 a v12 suele requerir un re-mapeo de las constantes TypoScript, ya que algunas han sido renombradas. Para usuarios de versiones más antiguas de la extensión hay que tener en cuenta que las definiciones de servicios se mantenían antes exclusivamente a través de formularios del backend, mientras que las versiones más nuevas trabajan basadas en YAML y son por tanto mucho más fáciles de integrar en flujos Git.

Quien migra desde otra herramienta de consentimiento como Cookiebot, OneTrust o Usercentrics ahorra los costes de licencia recurrentes, pero debe reconstruir la configuración de servicios. Gosign realiza esas migraciones incluyendo un análisis de la tasa de consentimiento, de modo que el cambio no provoca pérdidas medibles en la tasa de aceptación.

Además, vale la pena una mirada estratégica a la pregunta de si un banner de cookies sigue siendo la respuesta correcta. Quien utiliza fuentes autoalojadas de forma consistente, cambia a analítica sin cookies como Matomo con cookies desactivadas o Plausible y sustituye vídeos incrustados por imágenes de vista previa estáticas con carga al clic, puede eliminar el banner por completo en muchas páginas. La ventaja legal es considerable, porque cada consentimiento evitado también es un riesgo sancionador evitado, y al mismo tiempo la tasa de conversión deja de verse frenada por el diálogo del banner.