WordPress 4.9 en retrospectiva: la versión anterior a Gutenberg

WordPress 4.9 “Tipton” (lanzado en 2017) fue una versión especial. Fue la última versión importante antes de la Revolución 5.0, que introdujo el editor Gutenberg.

Descubre más sobre los servicios de desarrollo WordPress en WPPoland.

Visto desde 2026, la versión 4.9 fue el momento en que WordPress “maduró” como plataforma para desarrolladores, introduciendo características que ahora damos por sentadas.

Si quieres la versión corta, WordPress 4.9 importa porque mejoró los flujos de trabajo reales de editores y desarrolladores justo antes de que Gutenberg cambiara por completo el modelo de edición.

#El contexto histórico: WordPress 4.9 como punto de inflexión

WordPress 4.9 “Tipton” (nombrado en honor al músico de jazz Billy Tipton) fue lanzado el 16 de noviembre de 2017. Representó la culminación de la era “clásica” de WordPress - la última versión antes de que Gutenberg cambiara fundamentalmente la forma en que construimos sitios WordPress.

Para entender la importancia de WordPress 4.9, hay que situarlo en el contexto de su época. En 2017, WordPress alimentaba aproximadamente el 29% de todos los sitios web en Internet. La plataforma había evolucionado enormemente desde sus humildes orígenes como herramienta de blogging en 2003, convirtiéndose en un Sistema de Gestión de Contenidos (CMS) completo utilizado por empresas, medios de comunicación, gobiernos y organizaciónes de todo el mundo.

El ecosistema de WordPress en ese momento era vibrante y maduro. Miles de temas y plugins estaban disponibles, y una comunidad global de desarrolladores contribuía activamente al core. Sin embargo, el editor de contenido no había cambiado fundamentalmente desde los primeros días de WordPress. Seguía siendo un editor WYSIWYG basado en TinyMCE que, aunque funcional, no reflejaba las expectativas modernas de los usuarios en cuanto a interfaces de edición de contenido.

Por qué 4.9 importa:

• Fue la versión final del editor “clásico” de WordPress
• Introdujo herramientas para desarrolladores que seguimos usando hoy
• Sentó las bases para la revolución del editor de bloques
• Marcó la transición de WordPress de “plataforma de blogging” a “CMS completo”

La versión 4.9 fue liderada por Weston Ruter y Mel Choyce, y contó con contribuciones de más de 400 desarrolladores de todo el mundo. Fue un esfuerzo colaborativo que perfeccionó las herramientas existentes en lugar de intentar reinventar la rueda - una filosofía que contrastaba marcadamente con lo que vendría después con Gutenberg.

#Lo que trajo WordPress 4.9: perspectiva de un desarrollador

#1. Borradores y cambios programados del Personalizador

La función: Por primera vez, podíamos hacer cambios de diseño (colores, CSS), guardarlos como “Borrador” y enviar un enlace de vista previa a un clientes - sin publicar los cambios en vivo.

Por qué fue importante: Antes de 4.9, hacer cambios de diseño significaba:

• Editar el sitio en vivo (arriesgado)
• Usar entornos de staging (complejo)
• Inyección manual de CSS (chapucero)

Estos métodos eran problemáticos por diferentes razones. Editar el sitio en vivo significaba que cualquier error sería visible instantáneamente para todos los visitantes. Los entornos de staging, aunque más seguros, requerían configuración técnica que muchos propietarios de sitios no podían gestionar por sí mismos. Y la inyección manual de CSS era propensa a errores y difícil de revertir.

Cómo funcionaba:

// El Personalizador ahora soporta cambios en borrador
$wp_customize->add_setting('header_color', array(
    'default' => '#0073aa',
    'transport' => 'postMessage',
    'type' => 'theme_mod',
));

// Los cambios se guardan como borradores, no se publican inmediatamente

El sistema de borradores del Personalizador funcionaba creando “changesets” - conjuntos de cambios que se almacenaban como entradas de tipo personalizado en la base de datos. Estos changesets podían tener diferentes estados: borrador, programado o publicado. Esto significaba que podías trabajar en múltiples conjuntos de cambios de diseño simultáneamente sin que ninguno afectara al sitio en vivo.

La funcionalidad de programación permitía establecer una fecha y hora futuras para que los cambios se aplicaran automáticamente. Esto era especialmente útil para lanzamientos de campaña, cambios estacionales en el diseño o actualizaciones de branding coordinadas.

Impacto:

• El flujo de aprobación del clientes se convirtió en estándar
• Se redujeron los errores de “ups, publiqué demasiado pronto”
• Proceso de diseño profesional
• Mayor confianza para experimentar con cambios de diseño

Perspectiva 2026: Aunque Gutenberg reemplazó gran parte de la funcionalidad del Personalizador, el concepto de borrador/programación vive en el sistema de revisiones del editor de bloques. La idea de poder preparar cambios, revisarlos y programar su publicación se ha convertido en una expectativa fundamental de cualquier CMS moderno.

#2. Integración de CodeMirror

La función: Los editores de código en el panel de administración (por ejemplo, en el “Editor de temas” o “CSS adicional”) finalmente recibieron resaltado de sintaxis y numeración de líneas. Se acabó romper el sitio por un punto y coma que faltaba.

Por qué fue importante: Antes de 4.9, editar código en WordPress significaba:

• Editores de texto plano (sin resaltado de sintaxis)
• Sin números de línea (difícil depurar)
• Sin detección de errores
• Alto riesgo de romper sitios

Para los desarrolladores que trabajaban directamente en el panel de administración de WordPress, esta era una experiencia frustrante. Un simple error tipográfico en un archivo de tema podía hacer que todo el sitio dejara de funcionar, y sin resaltado de sintaxis ni detección de errores, encontrar el problema podía llevar horas.

Lo que añadió CodeMirror:

• Resaltado de sintaxis: PHP, CSS, JavaScript, HTML - cada lenguaje con su propio esquema de colores que facilitaba la lectura y comprensión del código.
• Números de línea: Fácilidad para reportar errores y navegar archivos grandes.
• Plegado de código: Colapsar funciones y bloques para obtener una vista general del archivo.
• Coincidencia de paréntesis: Encontrar paréntesis coincidentes visualmente, evitando errores comunes de sintaxis.
• Autoindentación: Formato de código adecuado que se aplicaba automáticamente al escribir.
• Buscar y reemplazar: Encontrar código rápidamente dentro del editor.

Ejemplo:

// Antes de 4.9: Editor de texto plano
function my_function() {
return 'hello';
}

// Después de 4.9: CodeMirror muestra errores de sintaxis
function my_function() {
    return 'hello'; // Indentación adecuada resaltada
}

Además del resaltado visual, CodeMirror incorporaba una función de seguridad crucial: la detección de errores de sintaxis antes de guardar. Si el código contenía un error que podría romper el sitio, WordPress mostraba una advertencia y ofrecía la opción de no guardar los cambios. Esta característica por sí sola salvó probablemente miles de sitios de quedar inaccesibles por errores de código.

Impacto:

• Se redujeron los errores de código en el panel
• WordPress se volvió más amigable para desarrolladores
• Se estableció un estándar para la edición de código en CMS

Perspectiva 2026: CodeMirror sigue utilizándose en WordPress 6.x para la edición de temas y plugins, aunque el editor de bloques de Gutenberg ha reducido la dependencia de la edición directa de código. La versión de CodeMirror se ha actualizado varias veces, mejorando el rendimiento y añadiendo soporte para nuevas características de los lenguajes.

#3. Mejoras del widget de galería

La función: Añadir galerías de fotos a la barra lateral se convirtió en algo nativo y más intuitivo. Antes de esta versión, crear una galería en un widget requería plugins adicionales o conocimientos de HTML.

Antes de 4.9:

• Se necesitaban plugins para galerías avanzadas
• Opciones de personalización limitadas
• Interfaz torpe y poco intuitiva

Después de 4.9:

• Widget de galería nativo integrado en el core
• Selección de imágenes con arrastrar y soltar
• Mejor soporte móvil
• Rendimiento mejorado
• Integración completa con la Biblioteca de Medios

Impacto:

• Las galerías se hicieron accesibles para no desarrolladores
• Se redujo la necesidad de plugins de galería para funcionalidades básicas
• La experiencia de usuario mejoró significativamente

Perspectiva 2026: Los widgets de galería han sido reemplazados por los bloques de galería de Gutenberg, pero las mejoras de 4.9 prepararon el camino para una mejor gestión de medios. La filosofía de hacer que las funcionalidades comunes sean accesibles sin plugins se mantiene como un principio central del desarrollo de WordPress.

#Características adicionales de WordPress 4.9

#4. Instalación de temas mejorada

Qué cambió:

• Mejor vista previa de temas con información más detallada
• Funcionalidad de búsqueda mejorada con filtros más granulares
• Visualización de información de temas más completa, incluyendo compatibilidad con versiones de PHP y WordPress

La mejora en la instalación de temas reflejaba el reconocimiento de WordPress de que la selección de un tema es una de las decisiones más importantes que toma un propietario de sitio. Al hacer que este proceso fuera más informado y visual, se reducían las probabilidades de elegir un tema inadecuado.

#5. Mejoras en widgets

Qué cambió:

• Mejor gestión de widgets con una interfaz más clara
• Vista previa mejorada que mostraba los cambios en tiempo real
• Opciones de personalización ampliadas

Los widgets eran en 2017 una parte fundamental de la personalización de un sitio WordPress. Las mejoras en 4.9 los hicieron más potentes y fáciles de usar, aunque irónicamente estarían destinados a ser reemplazados por bloques pocos años después.

#6. Mejoras de seguridad

Qué cambió:

• Detección mejorada de tipos de archivo que prevenía la subida de archivos potencialmente maliciosos
• Mejor sanitización de datos de entrada
• Headers de seguridad mejorados

La seguridad fue una prioridad constante para el equipo de desarrollo de WordPress, y cada versión incorporaba mejoras incrementales. Las mejoras de 4.9 eran especialmente relevantes dado que WordPress, como el CMS más popular del mundo, era un objetivo constante de ataques.

#El camino a WordPress 5.0: la revolución Gutenberg

#Línea temporal

La transición de WordPress 4.9 a 5.0 fue uno de los momentos más significativos en la historia de la plataforma. Para entenderla completamente, es útil ver la línea temporal completa:

2017 (4.9):

• Última versión “clásica” de WordPress
• Fundamentos para Gutenberg ya se estaban desarrollando en paralelo
• La comunidad se preparaba para el cambio, aunque con opiniones divididas

2018 (5.0):

• El editor Gutenberg fue introducido como el editor predeterminado
• El plugin Classic Editor fue lanzado inmediatamente como alternativa
• La comunidad se dividió entre entusiastas y escépticos

2019-2021:

• Gutenberg maduró con cada actualización
• Los patrones de bloques fueron introducidos, ampliando las posibilidades de diseño
• El desarrollo de Full Site Editing (FSE) comenzó a tomar forma

2022-2026:

• FSE se convirtió en estándar para nuevos temas
• Los temas de bloques dominaron el directorio de temas
• El uso del Classic Editor comenzó a declinar, aunque se mantuvo significativo

#La división de la comunidad

Apenas un año después de 4.9, WordPress 5.0 llegó con Gutenberg. La comunidad se dividió en dos campos, una división que en muchos aspectos persiste hasta hoy:

Tradicionalistas:

• Se mantuvieron con el plugin “Classic Editor”
• Continuaron usando temas basados en PHP
• Prefirieron constructores de páginas (Elementor, Divi, WPBakery)
• El plugin Classic Editor todavía tiene millones de instalaciones activas

Los tradicionalistas argumentaban que Gutenberg fue lanzado prematuramente, que rompía flujos de trabajo establecidos y que añadía complejidad innecesaria para sitios simples. Muchos desarrolladores de temas y plugins se resistieron inicialmente a la migración, y algunos continúan manteniendo productos basados exclusivamente en el editor clásico.

Creadores modernos:

• Abrazaron el modelo de Full Site Editing (FSE)
• Todo - incluyendo cabecera y pie de página - construido con bloques
• Adoptaron temas de bloques como Twenty Twenty-Three y Twenty Twenty-Four
• Aprovecharon los patrones de bloques y las plantillas

Los creadores modernos vieron en Gutenberg una oportunidad para democratizar el diseño web, permitiendo a los usuarios crear diseños complejos sin necesidad de código o plugins de terceros. La visión de largo plazo de Matt Mullenweg era que Gutenberg eventualmente reemplazaría todos los aspectos de la personalización del sitio.

Los números (2026):

• ~40% de los sitios aún usan el plugin Classic Editor
• ~60% han adoptado Gutenberg en algún grado
• Temás de bloques: ~15% de cuota de mercado (en crecimiento)
• Temás clásicos: ~85% de cuota de mercado (en declive)

Estos números revelan que la transición, aunque inevitable, es más lenta de lo que muchos predijeron. La inercia de millones de sitios existentes, la inversión en temas y plugins clásicos, y la curva de aprendizaje de Gutenberg han contribuido a esta gradualidad.

#El legado de WordPress 4.9

#Lo que aprendimos

1. Las mejoras incrementales importan 4.9 demostró que las mejoras pequeñas y enfocadas pueden tener un gran impacto. La integración de CodeMirror, aunque aparentemente menor, hizo que WordPress fuera significativamente más amigable para desarrolladores. No siempre se necesitan revoluciones para avanzar.

2. La experiencia del desarrollador es importante Características como los borradores del Personalizador y CodeMirror mostraron que WordPress se preocupaba por los desarrolladores, no solo por los usuarios finales. Este enfoque dual ha sido clave para el éxito continuo de la plataforma.

3. Fundamentos para el cambio Las mejoras de 4.9 sentaron las bases para Gutenberg. El sistema de borrador/programación en el Personalizador influyó en el sistema de revisiones de Gutenberg. La filosofía de hacer las cosas más seguras y más fáciles de previsualizar se trasladó directamente al nuevo editor.

#Lo que sigue importando hoy

CodeMirror:

• Sigue utilizándose en los editores de temas y plugins
• Sigue siendo el estándar para la edición de código en WordPress
• Mejorado en versiones posteriores con mejor rendimiento y más funcionalidades

Borradores del Personalizador:

• El concepto vive en las revisiones de Gutenberg
• Los cambios programados siguen disponibles
• Los enlaces de vista previa siguen utilizándose para aprobación de clientes

Herramientas para desarrolladores:

• El enfoque de 4.9 en la experiencia del desarrollador continúa
• WordPress moderno prioriza las herramientas para desarrolladores
• Mejor depuración, mejores APIs, mejor documentación

#Comparando WordPress 4.9 con WordPress moderno (2026)

#Entonces (4.9) vs Ahora (6.x)

Desarrollo de temas:

• 4.9: Plantillas PHP, functions.php, hooks y filtros
• 2026: Temás de bloques, theme.json, Full Site Editing

La diferencia es fundamental. En la era de 4.9, construir un tema requería profundos conocimientos de PHP, la jerarquía de plantillas de WordPress y el sistema de hooks. En 2026, los temas de bloques se definen principalmente a través de archivos JSON y plantillas HTML, con PHP relegado a funcionalidades específicas.

Edición de contenido:

• 4.9: Editor clásico, shortcodes, widgets
• 2026: Bloques Gutenberg, patrones, plantillas reutilizables

Los shortcodes, que eran la principal forma de añadir funcionalidad rica al contenido en la era 4.9, han sido en gran parte reemplazados por bloques nativos que ofrecen edición visual en tiempo real.

Personalización:

• 4.9: Personalizador, opciones de tema, páginas de configuración personalizadas
• 2026: Editor de Sitio, configuración de bloques, theme.json

Herramientas para desarrolladores:

• 4.9: CodeMirror, depuración básica con WP_DEBUG
• 2026: Depuración avanzada, React DevTools, herramientas de desarrollo de bloques, wp-scripts

#Lo que ha cambiado

Eliminado (u opcional):

• Editor clásico (disponible como plugin opcional)
• Muchas funciones del Personalizador (reemplazadas por el Editor de Sitio)
• Sistema de widgets (reemplazado por bloques en áreas de widgets)

Mejorado:

• Edición de código (sigue siendo CodeMirror, pero mejorado)
• APIs para desarrolladores (más hooks, mejor documentación, REST API más completa)
• Rendimiento (más rápido, más eficiente, mejor manejo de caché)

Nuevo:

• Editor de bloques Gutenberg
• Full Site Editing
• Patrones de bloques
• Theme.json para configuración de temas
• Desarrollo basado en React para el editor

#Lecciones para desarrolladores

#1. Abraza el cambio

La transición de WordPress 4.9 a 5.0 demostró que los cambios importantes son posibles y, a veces, necesarios. Como desarrollador, mantenerse actualizado es esencial. Los que se adaptaron temprano a Gutenberg se posicionaron como expertos cuando la demanda creció.

#2. La compatibilidad hacia atrás importa

WordPress mantuvo la compatibilidad hacia atrás incluso a través de cambios importantes. El plugin Classic Editor asegura que los sitios antiguos sigan funcionando. Esta filosofía de no romper lo existente mientras se avanza hacia lo nuevo es una lección valiosa para cualquier proyecto de software.

#3. Las herramientas para desarrolladores son esenciales

La integración de CodeMirror demostró que la experiencia del desarrollador importa. WordPress moderno continúa esta tendencia con mejores herramientas de depuración, documentación más completa y APIs más potentes.

#4. La retroalimentación de la comunidad moldea WordPress

La división entre tradicionalistas y creadores modernos demuestra que WordPress escucha a su comunidad, incluso cuando toma decisiones controvertidas. El mantenimiento del plugin Classic Editor durante años después de Gutenberg es prueba de este compromiso.

#El futuro: qué viene después de los bloques

Tendencias actuales (2026):

• Integración de IA en WordPress para generación de contenido y diseño asistido
• Crecimiento del WordPress headless para aplicaciones modernas
• Enfoque en optimización de rendimiento con Core Web Vitals
• Mejoras de accesibilidad como prioridad de desarrollo

Lo que podemos aprender de 4.9:

• Las mejoras incrementales se acumulan para producir cambios importantes
• Las herramientas para desarrolladores importan tanto como las funciones para usuarios
• La experiencia del usuario es primordial en cada decisión de diseño
• La compatibilidad hacia atrás es crucial para una plataforma con millones de usuarios

#Resumen: el lugar de WordPress 4.9 en la historia

WordPress 4.9 “Tipton” fue más que otra versión - fue la última versión del WordPress “clásico” antes de la revolución Gutenberg.

Logros clave:

• Introdujo borradores del Personalizador (flujo de trabajo con clientes)
• Integró CodeMirror (experiencia del desarrollador)
• Mejoró los widgets de galería (experiencia del usuario)
• Sentó las bases para Gutenberg

Significado histórico:

• Última versión importante antes del editor de bloques
• Culminación de la era clásica de WordPress
• Puente entre el WordPress antiguo y el nuevo
• Prueba de que las mejoras incrementales importan

Perspectiva 2026: Hoy, en 2026, el debate entre clásico y bloques es en gran parte historia. Los bloques ganaron. Pero vale la pena recordar la versión 4.9 como el “último bastión” del enfoque clásico de construcción de temas PHP - una versión que perfeccionó la forma antigua antes de que la nueva forma tomara el relevo.

Para desarrolladores:

• Estudia 4.9 para entender el WordPress clásico
• Aprecia las mejoras que trajo
• Aprende de la transición a Gutenberg
• Aplica las lecciones a futuros cambios de WordPress

WordPress 4.9 representa un momento en el tiempo - la calma antes de la tormenta, la perfección de lo antiguo antes de la introducción de lo nuevo. Es una versión que vale la pena estudiar, no solo por el contexto histórico, sino para entender cómo evoluciona WordPress y cómo se gestionan los cambios importantes en una plataforma global.