typo3db_legacy para TYPO3

Por qué typo3db_legacy supone un riesgo de seguridad desde TYPO3 v12

TYPO3 cambió completamente la abstracción de base de datos a Doctrine DBAL con la versión 8. La antigua API vía $GLOBALS['TYPO3_DB'] se marcó como deprecated desde v9 y se eliminó completamente en v12. A pesar de ello, miles de instalaciones TYPO3 funcionan en la práctica con extensiones basadas en la API legacy. typo3db_legacy mantiene estas extensiones vivas emulando la antigua API como capa de compatibilidad.

El problema: la extensión no es una solución permanente, sino un puente. Cada nueva versión de TYPO3 aumenta el riesgo de que la propia capa de compatibilidad falle. Quien hoy aún usa typo3db_legacy se enfrenta a una decisión clara - migrar o arriesgarse con la actualización a v13.

Escenarios de uso habituales

Extensiones propias con accesos directos a base de datos. Muchas agencias desarrollaron entre 2012 y 2018 extensiones que llaman directamente a $GLOBALS['TYPO3_DB']->exec_SELECTquery(). En una instalación típica de PYME se encuentran de 3 a 8 extensiones de este tipo. Sin typo3db_legacy, fallarían con Fatal Errors tras una actualización a v10+.

Extensiones de terceros sin mantenedor activo. Extensiones como versiones antiguas de add-ons de tt_address, directorios sectoriales o herramientas de importación especializadas fueron a menudo mantenidas por desarrolladores individuales. Si el mantenedor ya no está activo, typo3db_legacy es la única opción para conservar la funcionalidad durante la actualización.

Migración por fases de instalaciones grandes. Empresas con más de 50 extensiones no pueden migrar todo simultáneamente. typo3db_legacy permite un enfoque gradual: primero la actualización del core, luego extensión por extensión a Doctrine DBAL. Gosign planifica estas migraciones en sprints de 3 a 5 extensiones priorizadas por criticidad de negocio.

Arquitectura técnica

typo3db_legacy se registra como extensión TYPO3 y proporciona la clase DatabaseConnection que implementa los mismos métodos que la antigua API: exec_SELECTquery(), exec_INSERTquery(), exec_UPDATEquery(), exec_DELETEquery() y las variantes de prepared statements.

Internamente, la capa redirige todas las llamadas a Doctrine DBAL. Esto funciona de forma fiable para queries estándar. Se vuelve problemático con funciones MySQL directas en queries, prepared statements con parámetros nombrados en formato antiguo, y manejo de transacciones que no mapea 1:1 a Doctrine. Además, cada query atraviesa una capa de abstracción adicional con un overhead de rendimiento del 5-15 %.

Problemas frecuentes y soluciones

La extensión no funciona pese a typo3db_legacy tras la actualización. La causa suele ser que la extensión no solo usa $GLOBALS['TYPO3_DB'], sino también otras APIs eliminadas. Solución: un análisis completo del código de la extensión, no solo de las llamadas a base de datos. El Extension Scanner de TYPO3 proporciona una lista priorizada. Gosign realiza estos análisis como inventario previo - esfuerzo típico: 2 a 4 horas por instalación.

Las queries devuelven resultados distintos a antes de la actualización. Doctrine DBAL trata los tipos de forma más estricta que la antigua API basada en mysqli. Un WHERE uid = '5' (string en vez de integer) puede causar comportamiento inesperado en casos límite. Solución: revisar todas las queries para tipos PHP correctos.

Caída de rendimiento tras la instalación. Instalaciones con más de 100.000 registros y queries frecuentes notan el overhead de la doble abstracción. Solución: solo la migración completa a Doctrine DBAL con QueryBuilder hace innecesaria la capa legacy.

Migración y compatibilidad de versiones

typo3db_legacy fue parte oficial del TYPO3 Core hasta la versión 9.5 LTS. Para TYPO3 v10 y v11 existía como paquete Composer separado. Para TYPO3 v12 LTS ya no hay release oficialmente soportado. Para TYPO3 v13 no hay capa de compatibilidad prevista ni realista.

La ruta de migración recomendada: cada llamada exec_SELECTquery() se reescribe al QueryBuilder de Doctrine DBAL. Una extensión típica con 10 a 20 llamadas a queries se migra en 4 a 8 horas. Para extensiones complejas con queries construidas dinámicamente, el esfuerzo sube a 2 a 3 días por extensión. Gosign emplea análisis de código automatizado que identifica todas las llamadas a la API legacy y sugiere código de migración.