Bitadir.com, un directorio histórico de blogs en castellano que se presenta como una “copia viva” de la primera blogosfera, acaba de completar una modernización integral que lo saca definitivamente de la era PHP 4/5 y lo lleva a PHP 8.4. La actualización no se limita a “hacer que vuelva a funcionar”: el proyecto incorpora un paquete completo de mejoras de seguridad, usabilidad y rediseño responsive, manteniendo la arquitectura original y sin una reescritura total.
El caso tiene un valor especial por lo que representa Bitadir: un archivo vivo de miles de bitácoras y registros de una etapa en la que el contenido generado por usuarios empezaba a marcar el ritmo de Internet. En su página informativa, el sitio subraya que conserva entradas incluso de blogs que ya no existen, como testimonio de aquella “época dorada” de la creación de contenidos en español.
Un “legacy” con dos décadas de deuda técnica… y riesgos reales
El punto de partida no era pequeño. La aplicación arrastraba tecnologías y decisiones típicas de principios de los 2000: PHP 4.x/5.x, un framework propietario (qFramework) datado en 2004, plantillas Smarty 2, bases de datos MySQL 4/5, maquetación con tablas HTML, CSS antiguo y una autenticación basada en MD5 sin salt.
En 2026, ese cóctel no solo complica el mantenimiento: también supone una exposición clara a problemas de seguridad y compatibilidad. El documento del proyecto identifica fallos clásicos de este tipo de plataformas: funciones de PHP ya eliminadas, constructores “a la antigua”, uso de mysql_*, ausencia de tipado, posibles puntos de SQL injection, falta de cabeceras HTTP de seguridad y formularios sin protección CSRF.
La decisión estratégica fue clara: modernizar por capas para conservar el funcionamiento y reducir el riesgo, en lugar de “tirarlo todo y empezar de cero”.
Migración a PHP 8.4: compatibilidad actual y horizonte de soporte
La actualización a PHP 8.4 coloca el proyecto en una rama moderna y oficialmente soportada por PHP. Según el calendario de versiones, PHP 8.4 mantiene soporte activo hasta el 31 de diciembre de 2026 y soporte de seguridad hasta el 31 de diciembre de 2028, un margen relevante para un servicio que quiere perdurar.
El trabajo se centró en actualizar archivo por archivo el framework qFramework y las piezas de aplicación: sustitución de patrones obsoletos (como var o constructores con nombre de clase), eliminación de referencias innecesarias y adaptación a los requisitos de PHP moderno. Para la capa de base de datos se adoptó compatibilidad con ADOdb y se reforzó el escape de parámetros, además de preparar el terreno para un futuro salto a PDO y consultas preparadas.
Seguridad: del MD5 “crackeable” a bcrypt, y del “barra libre” al control de intentos
Una de las mejoras más relevantes llega en autenticación. El proyecto incorpora una clase qPassword para utilizar bcrypt con factor de coste 12, y lo hace sin obligar a los usuarios a resetear contraseñas: si un usuario inicia sesión con un hash antiguo MD5, el sistema valida y migra automáticamente a bcrypt en ese mismo login.
La otra pata clave es la defensa contra fuerza bruta. Se añade un qRateLimiter que aplica límites por defecto (por ejemplo, 5 intentos, ventana de 15 minutos y bloqueo de 30 minutos tras excederlos) en rutas sensibles como login, recuperación de contraseña o registro.
A esto se suman cabeceras HTTP para frenar vectores habituales (clickjacking, MIME sniffing, políticas de referrer y una Content Security Policy), además de medidas como forzar HTTPS y endurecer cookies de sesión con flags HttpOnly y Secure.
Rediseño total: de tablas y ancho fijo a una web responsive “mobile-first”
La modernización también cambia la cara del proyecto. El rediseño abandona el layout con tablas, el ancho fijo y la tipografía rígida. En su lugar introduce un CSS moderno basado en variables (custom properties), componentes visuales consistentes (tarjetas, badges, mensajes de estado), y un layout responsive con Flexbox/Grid y breakpoints para tablet y móvil.
Incluso elementos pequeños, como iconos de carpeta, dejan atrás GIFs y pasan a resolverse con CSS puro. El objetivo es doble: mejorar la experiencia en móviles y, a la vez, facilitar el mantenimiento visual sin depender de frameworks pesados.
Rendimiento y caché híbrida: Redis si está disponible, disco como plan B
La actualización incorpora un sistema de caché híbrido: Redis cuando existe, y caché en archivos como alternativa. El TTL por defecto se fija en 24 horas para conjuntos de datos como categorías, noticias, últimos blogs o el conteo total. El cron que alimenta RSS se encarga además de limpiar caché al actualizar feeds o al expirar claves.
En métricas internas del proyecto, el salto se describe con mejoras claras: Lighthouse Performance de ~40 a ~85, Accessibility de ~50 a ~90, y una reducción del tiempo de carga aproximado de ~3 s a ~1 s, además del soporte móvil completo.
Correcciones de bugs: pequeños detalles que rompían el día a día
El proyecto documenta varios fallos “de herencia” que afectaban al uso real: pérdida de parámetros en navegación por no usar QSA, dobles barras en redirecciones, un login público que rechazaba a administradores por un filtro de rol, menús duplicados por includes repetidos, o una página de admin que mostraba datos incorrectos por un error histórico de copiar/pegar.
También se aclara un matiz importante: algunas rutas heredadas conservan nombres confusos por diseño original, y la modernización prioriza arreglar funcionamiento sin romper compatibilidad.
El factor IA: velocidad, coste y nueva forma de mantener software antiguo
El documento del caso añade un elemento que ya aparece en más modernizaciones recientes: el uso intensivo de un asistente de Inteligencia Artificial para acelerar el trabajo. Se habla de 2 sesiones de trabajo, alrededor de 62 archivos modificados, unas 4.800 líneas actualizadas y un total aproximado de 600.000 tokens procesados.
En su comparativa interna, el proyecto estima que una reescritura completa podría situarse entre 15.000 € y 30.000 € y llevar 2 a 4 meses, mientras que una migración manual “tradicional” rondaría 5.000 € a 10.000 € y 1 a 2 meses. Frente a eso, se presenta la modernización con IA como un trabajo de unas 8 horas más coste de uso de modelos. Ese coste, eso sí, depende de tarifas y condiciones: Anthropic publica que el precio de Claude Opus 4.5 “empieza” en 5 $ por millón de tokens de entrada y 25 $ por millón de tokens de salida, con posibles ahorros por técnicas como prompt caching.
Un legado que se mantiene vivo… con estándares de 2026
Bitadir se define como un proyecto de preservación de la historia de los blogs, ligado al legado digital de Color Vivo (fundada en 1995) y a su creador, David Carrero Fernández-Baillo, cuya trayectoria arranca en redes BBS y Fidonet en 1994, antes del Internet comercial. Hoy con su foco en soluciones de infraestructura cloud en Stackscale (Grupo Aire). En esa narrativa, la modernización no es solo técnica: es una forma de asegurar que un pedazo de la memoria de la web en español siga accesible y mantenible en los próximos años.
Preguntas frecuentes
¿Cómo se puede migrar una web en PHP 4/5 a PHP 8.4 sin reescribirla desde cero?
La vía más segura suele ser incremental: actualizar framework y librerías por capas, corregir incompatibilidades críticas (constructores antiguos, funciones eliminadas, mysql_*) y mantener la arquitectura mientras se moderniza la base.
¿Qué ventaja tiene migrar contraseñas de MD5 a bcrypt de forma transparente?
Permite endurecer la seguridad sin obligar a los usuarios a resetear credenciales: cuando el usuario inicia sesión, el sistema valida el hash antiguo y lo reemplaza por bcrypt automáticamente.
¿Qué medidas mínimas debería tener un login moderno para frenar ataques de fuerza bruta?
Rate limiting, bloqueo temporal tras varios intentos, registros de intentos fallidos, y cabeceras/cookies endurecidas. En paneles de administración, suele recomendarse además 2FA.
¿Redis es imprescindible para acelerar una web antigua modernizada?
No necesariamente. Un enfoque híbrido con Redis cuando está disponible y caché en disco como fallback puede aportar mejoras notables sin convertir Redis en un punto único de fallo.
