Historia de WordPress, de la versión 4.9 a la era Gutenberg

#WordPress 4.9 Tipton, lanzamiento de 2017

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

WordPress 4.9 “Tipton”, lanzado en noviembre de 2017, ocupa un lugar único en la historia de WordPress como la última versión principal antes del importante WordPress 5.0, que introdujo el editor de bloques Gutenberg. Esta versión represento un momento de madurez para WordPress como plataforma de desarrollo, introduciendo comodidades que ahora consideramos estándar pero que fueron innovadoras en su momento. El repaso función por función de la versión está en qué trajo WordPress 4.9; este artículo sigue lo que vino después.

Mirando desde nuestra perspectiva de 2026, la versión 4.9 se erige como un fascinante artefacto histórico - una instantánea de WordPress al borde de su transformación más significativa desde la creación de la plataforma. Los desarrolladores y diseñadores que construyeron sitios en 4.9 presenciaron una era donde los archivos de plantillas PHP todavía reinaban supremos, donde las áreas de widgets se gestionaban a través de interfaces de arrastrar y soltar, y donde el concepto de “bloques” se asociaba principalmente con bloques multimedia en el contenido en lugar del elemento fundamental de construcción de páginas enteras.

El ciclo de desarrollo de WordPress 4.9 introdujo varias mejoras clave que aumentaron el atractivo de la plataforma tanto para desarrolladores como para administradores de sitios. El enfoque en la calidad del código, la optimización del rendimiento y los refinamientos en la experiencia del usuario demostraron el compromiso de WordPress con la mejora continua incluso mientras el equipo se preparaba para la enorme empresa que se convertiría en Gutenberg.

#Novedades de WordPress 4.9

WordPress 4.9 trajo varias características transformadoras que moldearon el panorama del desarrollo durante años. Las mejoras más significativas se centraron en el Customizer, las capacidades de edición de código y la gestión de widgets, cada una abordando puntos de dolor que desarrolladores y administradores de sitios habían expresado frustración durante mucho tiempo.

Las mejoras del Customizer en 4.9 representaron un gran paso adelante en el viaje de la plataforma hacia una experiencia de edición de sitios más dinámica y amigable para el usuario. Estas mejoras sentaron bases importantes para la vision de Full Site Editing que surgiría en versiones posteriores, demostrando el compromiso del equipo de WordPress con la evolución del Customizer como centro principal de personalización del sitio.

// Ejemplo de mejoras del Customizer en WordPress 4.9
// Agregando un nuevo control con vista previa en tiempo real
$wp_customize->add_setting('theme_options[accent_color]', array(
    'default'   => '#0073aa',
    'transport' => 'postMessage',
    'sanitize_callback' => 'sanitize_hex_color',
));

$wp_customize->add_control(new WP_Customize_Color_Control(
    $wp_customize,
    'theme_options[accent_color]',
    array(
        'label'    => __('Color de acento', 'my-theme'),
        'section'  => 'colors',
        'priority' => 5,
    )
));

La integración de CodeMirror en el núcleo de WordPress para la edición de temas y plugins fue otra mejora histórica. Antes de 4.9, editar archivos de temas o agregar CSS personalizado significaba trabajar con un textarea básico que no ofrecía resaltado de sintaxis, números de línea o detección de errores. Los desarrolladores que accidentalmente introducían errores de sintaxis a menudo rompían sus sitios, llevando a la infame “pantalla blanca de la muerte” y requiriendo acceso FTP para solucionar el problema.

#Editor de código CodeMirror en WordPress 4.9

La introducción de editores basados en CodeMirror en WordPress 4.9 cambio fundamentalmente como los desarrolladores interactúaban con las capacidades de edición de código de la plataforma. El resaltado de sintaxis, la numeración de líneas, la coincidencia de paréntesis y la detección de errores se convirtieron en características estándar, reduciendo dramáticamente la probabilidad de errores que rompieran sitios y mejorando la productividad general del desarrollador.

Esta mejora fue particularmente significativa para los administradores de sitios que frecuentemente necesitaban agregar CSS personalizado o modificar archivos de temas. La retroalimentación visual proporcionada por el resaltado de sintaxis facilitó mucho la identificación de errores tipográficos, puntos y comas faltantes y otros errores de codificación comunes antes de que pudieran causar problemas en el sitio en vivo. Los números de línea también facilitaron la colaboración al trabajar con equipos de desarrollo o al buscar ayuda de la comunidad de WordPress.

/* Ejemplo de CSS con resaltado de sintaxis - soporte CodeMirror en WordPress 4.9 */
.site-header {
    background-color: #ffffff;
    padding: 20px 0;
    box-shadow: 0 2px 10px rgba(0, 0, 0, 0.1);
    transition: all 0.3s ease;
}

.site-header.scrolled {
    padding: 10px 0;
    background-color: #f8f9fa;
}

/* Diseño responsive con media queries */
@media screen and (max-width: 768px) {
    .site-header {
        padding: 15px 0;
    }

    .main-navigation {
        display: none;
    }
}

La integración de CodeMirror también mejoro la sección “CSS Adicional” en el Customizer, convirtiéndola en una opción más viable para almacenar reglas CSS personalizadas. La nota de lanzamiento de 4.9 enumera dos salvaguardas que llegaron con ella: WordPress avisa antes de guardar código con un error y advierte de que editar archivos de temas y plugins directamente desde el administrador es una práctica peligrosa. Según la nota para desarrolladores sobre edición de código, los linters incluidos eran CSSLint, JSHint, HTMLHint y JSONLint; el PHP tenía resaltado de sintaxis, pero no linting.

#Widget de galería en WordPress 4.9

WordPress 4.9 introdujo soporte nativo de galerías para widgets, abordando una necesidad común entre los administradores de sitios que querían mostrar galerías fotográficas en barras laterales y otras áreas de widgets sin requerir código personalizado o soluciones de terceros. Esta característica se basó en los widgets multimedia de imagen, vídeo y audio que WordPress 4.8 había añadido una versión antes.

El widget de texto también cambió. Según la guía de campo de WordPress 4.9, pasó a admitir shortcodes, imágenes, galerías, vídeo, audio e incrustaciones, y la nota de lanzamiento añade que la ubicación de menús y widgets se conservaba mejor al cambiar de tema. Fueron cambios graduales frente a lo que traería el editor de bloques, pero acercaron los widgets al contenido de las entradas.

#Por qué los widgets de WordPress 4.9 se llamaban protobloques

El widget de galería parece una función menor de la barra lateral, pero la nota que lo presentó lo vincula directamente con Gutenberg. En Introducing the Gallery widget, publicada en make.wordpress.org el 25 de septiembre de 2017, Weston Ruter escribió:

“Los widgets multimedia se están desarrollando pensando en Gutenberg, porque los widgets son en esencia protobloques.” (Weston Ruter, make.wordpress.org, traducción propia)

La misma nota dice que, a medida que Gutenberg madurara, estaba previsto que los widgets pasaran a usar bloques y que los widgets de imagen, vídeo, audio y galería se migrarían en ese momento. También recoge el movimiento contrario: Gutenberg ya había convertido los widgets Categorías y Entradas recientes en bloques dinámicos, de modo que contenido antes limitado a las barras laterales podía colocarse dentro de las entradas.

Ese plan se cumplió casi cuatro años después. WordPress 5.8 “Tatum” (nota de lanzamiento, 20 de julio de 2021) llevó los bloques tanto al editor de widgets como al Customizer. Los sitios que no estaban preparados pueden volver a las pantallas anteriores con Classic Widgets, un plugin oficial mantenido por el equipo de WordPress que el directorio de plugins sitúa en más de 2 millones de instalaciones activas. Para quien mantiene un tema de la época de 4.9, las áreas de widgets construidas con widgets de texto y multimedia son la parte del sitio que cambia primero cuando se activa el editor de widgets por bloques.

#Qué cambió en WordPress 4.9.6 y 4.9.8 antes de Gutenberg

La versión 4.9 siguió siendo la rama vigente durante más de un año, y dos de sus versiones de mantenimiento cambiaron algo más que errores.

WordPress 4.9.6 (nota de lanzamiento, 17 de mayo de 2018) fue una versión de privacidad. Añadió:

• un ajuste para designar la página de política de privacidad, que después se muestra en las páginas de acceso y de registro;
• una herramienta de exportación que genera un archivo ZIP con los datos personales de un usuario, incluidos los recogidos por plugins participantes;
• una herramienta de borrado de esos mismos datos;
• un método por correo electrónico para confirmar las solicitudes de exportación y de borrado;
• una casilla en el formulario de comentarios que permite a quien comenta sin iniciar sesión decidir si su nombre, correo y web se guardan en el navegador.

WordPress 4.9.8 (nota de lanzamiento, 2 de agosto de 2018) añadió al escritorio el aviso “Try Gutenberg”, que la nota describe como una oportunidad para usar el editor de bloques antes de su publicación en WordPress 5.0. Quién lo veía dependía del sitio:

• con Gutenberg ni instalado ni activado: administradores de sitios individuales y superadministradores de multisitio;
• con Gutenberg instalado y activado: usuarios con rol de Colaborador o superior;
• con el plugin Classic Editor activo: nadie.

La misma versión incluyó 18 correcciones de privacidad para las herramientas añadidas en 4.9.6. El orden importa al leer registros de cambios antiguos: el editor de bloques nunca formó parte de 4.9. Era un plugin aparte, y 4.9.8 fue la primera versión del núcleo que remitía a él.

#WordPress 5.0 Gutenberg contra Classic Editor

WordPress 5.0 “Bebo”, lanzado el 6 de diciembre de 2018, introdujo el editor de bloques Gutenberg y cambio fundamentalmente como los usuarios crean y editan contenido en WordPress. La reacción de la comunidad ante este cambio fue, por decirlo suavemente, polarizada. La transición del editor clásico basado en TinyMCE a un enfoque basado en bloques represento el cambio más significativo en la experiencia de edición de WordPress en la historia de la plataforma.

La comunidad se dividió en dos campos distintos tras la introducción de Gutenberg. Los tradicionalistas, incluyendo muchos desarrolladores experimentados y administradores de sitios, expresaron preocupación por la curva de aprendizaje, las implicaciones de rendimiento y la pérdida de flujos de trabajo familiares. Este grupo adoptó el plugin “Classic Editor”, que sigue teniendo millones de instalaciones activas y continúa recibiendo actualizaciones para los usuarios que prefieren la experiencia de edición tradicional.

// Plugin Classic Editor - manteniendo la experiencia tradicional de WordPress
// El plugin ha sido instalado por millones que prefieren el enfoque clasico
// Caracteristicas clave preservadas:
// - Edicion de contenido basada en TinyMCE
// - No se requieren bloques
// - Atajos de teclado familiares
// - Flujo de trabajo de metabox tradicional

Los creadores modernos, por otro lado, abrazaron el enfoque basado en bloques, reconociendo su potencial para la flexibilidad del contenido y la consistencia del diseño. El editor de bloques introdujo un nuevo paradigma donde el contenido se construye a partir de componentes reutilizables y configurables en lugar de un único campo de texto enriquecido. Este enfoque se alineo con tendencias más amplias de la industria hacia la arquitectura basada en componentes e hizo más fácil crear diseños consistentes y responsivos sin código personalizado.

#Qué incluyó WordPress 5.0 Bebo

La nota de lanzamiento de 5.0 nombra tres piezas. El editor de bloques, que describe como el primer paso hacia una experiencia de edición simplificada en todo el sitio. Twenty Nineteen, un nuevo tema por defecto cuyos estilos coinciden con los bloques por defecto, para que lo que se ve en el editor coincida con el sitio publicado. Y un camino de vuelta con soporte: los sitios podían instalar el plugin Classic Editor desde la pantalla de plugins para recuperar el editor anterior. La nota registra 423 colaboradores con reconocimiento en la versión, dirigida por Matt Mullenweg junto con once codirectores.

#Hasta cuándo tiene soporte el plugin Classic Editor

El 7 de noviembre de 2018, un mes antes de 5.0, Gary Pendergast publicó en make.wordpress.org la ventana de soporte del plugin Classic Editor:

“El plugin Classic Editor tendrá soporte oficial hasta el 31 de diciembre de 2021.” (Gary Pendergast, make.wordpress.org, traducción propia)

La nota definía el soporte oficial como funcionar correctamente en la última versión mayor de WordPress y en la anterior, y dejaba la continuidad del mantenimiento después de 2021 a una evaluación según el uso. La respuesta está en la página del propio plugin, que hoy indica que tendrá soporte y mantenimiento completos hasta 2024 o durante el tiempo que sea necesario. En octubre de 2026 el directorio de plugins muestra la versión 1.7.0, actualizada por última vez en mayo de 2026, con más de 8 millones de instalaciones activas. Esa es la cláusula del tiempo que sea necesario en funcionamiento, y es la cifra a tener presente antes de dar por muerto el editor clásico.

#Cómo evolucionó el Full Site Editing después de WordPress 5.0

Tras la introducción del editor de bloques, el equipo de WordPress continuo empujando los limites de lo posible con bloques. El concepto de Full Site Editing (FSE) surgió como la siguiente evolución lógica, extendiendo el paradigma de bloques desde la edición de contenido hasta la personalización de temas. Con FSE, todo - desde encabezados y pies de página hasta barras laterales y partes de plantillas - podía construirse con bloques.

WordPress 5.8, lanzado en 2021, marco un hito significativo en el viaje FSE al introducir widgets basados en bloques. Este cambio reemplazo el sistema tradicional de widgets con un enfoque basado en bloques, permitiendo a los usuarios agregar y configurar widgets usando la misma interfaz que usaban para el contenido. Aunque este cambio inicialmente encontró resistencia de usuarios acostumbrados al sistema clásico de widgets, represento un paso crucial hacia la vision de edición completa del sitio.

// Ejemplo de plantilla de bloques - WordPress 5.0+
// Definiendo un patron de bloques personalizado para un tema
function my_theme_register_block_patterns() {
    register_block_pattern(
        'my-theme/hero-section',
        array(
            'title' => __('Seccion Hero', 'my-theme'),
            'description' => __('Una sección hero de ancho completo con título y boton', 'my-theme'),
            'categories' => array('featured'),
            'content' => '<!-- wp:cover {"overlayColor":"primary","minHeight":600,"isDark":true} -->
                <div class="wp-block-cover is-dark" style="min-height:600px">
                    <span aria-hidden="true" class="wp-block-cover__background has-primary-background-color has-background-dim-100 has-background-dim"></span>
                    <div class="wp-block-cover__inner-container">
                        <!-- wp:heading {"level":1,"style":{"typography":{"fontSize":48}}} -->
                        <h1 class="wp-block-heading" style="font-size:48px">Bienvenido a nuestro sitio</h1>
                        <!-- /wp:heading -->
                        <!-- wp:paragraph {"style":{"typography":{"fontSize":20}}} -->
                        <p style="font-size:20px">Descubre contenido y servicios increibles.</p>
                        <!-- /wp:paragraph -->
                        <!-- wp:button {"backgroundColor":"secondary"} -->
                        <div class="wp-block-button"><a class="wp-block-button__link has-secondary-background-color has-background">Comenzar</a></div>
                        <!-- /wp:button -->
                    </div>
                </div>
                <!-- /wp:cover -->',
        )
    );
}
add_action('init', 'my_theme_register_block_patterns');

El Editor del sitio, introducido en WordPress 5.9, represento la culminación de la vision FSE hasta ese punto. Esta característica proporcionaba una interfaz unificada para editar cada aspecto de un sitio usando bloques, incluyendo plantillas, partes de plantillas y estilos globales. Para los desarrolladores de temas, esto significo aprender nuevos enfoques para el desarrollo de temas, incluyendo temas de bloques que aprovechan el archivo de configuración theme.json para estilos y configuraciones.

#Hitos de WordPress de 5.8 a 6.3 y las fases de Gutenberg

El paso de 5.0 a un sitio construido por completo con bloques llevó cuatro años más. Las notas de lanzamiento marcan los puntos de avance:

theme.json llegó en 5.8, una versión antes que el Editor del sitio, y por eso un tema clásico puede adoptarlo sin convertirse en tema de bloques. La nota de 5.9 llega a decir que con los temas de bloques ya no se necesita el Customizer, la herramienta a la que 4.9 dedicó una versión entera.

La hoja de ruta de WordPress agrupa estas versiones en fases del proyecto Gutenberg. La fase 1 introdujo el editor de bloques en WordPress 5.0. La fase 2 se centró en la edición del sitio y culminó en WordPress 6.3, que su nota de lanzamiento describe como el remate de la fase 2. La fase 3, en curso, gira en torno a la edición colaborativa y los flujos de trabajo, y los objetivos de la hoja de ruta para 2026 prevén que WordPress 7.0 haga avanzar las funciones de colaboración de esa fase. La línea con 4.9 es directa: los borradores del Customizer, los enlaces de vista previa y el bloqueo de diseños fueron el primer intento de que varias personas trabajaran en un cambio antes de publicarlo, limitado al Customizer. La fase 3 lleva ese mismo problema a todo el editor.

#Qué son los temas de bloques y theme.json en WordPress

Avanzando rápido a 2026, la disputa entre la edición clásica y basada en bloques se ha resuelto en gran medida a favor de los bloques, aunque el plugin Classic Editor mantiene una base de usuarios significativa para casos de uso específicos. El ecosistema WordPress ha evolucionado dramáticamente, con los temas de bloques convirtiéndose en el estándar para el nuevo desarrollo de temas, y el proyecto Gutenberg continuando introduciendo nuevas características y mejoras.

Los patrones de bloques han surgido como una herramienta poderosa para los constructores de sitios, permitiendo diseños de página reutilizables que pueden insertarse y personalizarse fácilmente. El Directorio de Patrones, integrado directamente en el administrador de WordPress, proporciona un repositorio centralizado de patrones contribuidos por la comunidad que cubren todo, desde secciones hero hasta cuadriculas de testimonios y tablas de precios.

El Editor del sitio ha madurado hasta convertirse en una herramienta madura de creación de sitios, permitiendo a los usuarios construir sitios completos sin escribir una sola línea de código PHP. Theme.json se ha convertido en el mecanismo estándar para definir configuraciones y estilos de temas, proporcionando una alternativa más mantenible y eficiente a la personalización tradicional de temas basada en PHP.

// Ejemplo de theme.json - WordPress 5.9+
// Configuración centralizada del tema
{
    "version": 2,
    "settings": {
        "color": {
            "palette": [
                {
                    "slug": "primary",
                    "color": "#0073aa",
                    "name": "Primario"
                },
                {
                    "slug": "secondary",
                    "color": "#23282d",
                    "name": "Secundario"
                }
            ],
            "duotone": [
                {
                    "colors": ["#000000", "#ffffff"],
                    "slug": "escala-de-grises"
                }
            ]
        },
        "typography": {
            "fontFamilies": [
                {
                    "fontFamily": "-apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen-Sans, Ubuntu, Cantarell, 'Helvetica Neue', sans-serif",
                    "slug": "system"
                }
            ]
        },
        "spacing": {
            "units": ["px", "em", "rem", "%", "vw"]
        }
    },
    "styles": {
        "color": {
            "background": "#ffffff",
            "text": "#333333"
        }
    }
}

#Por qué WordPress 4.9 sigue importando en temas clásicos

A medida que la plataforma WordPress continúa evolucionando, vale la pena recordar la versión 4.9 como el “último bastion” del enfoque clásico de construcción de temas PHP. Para los desarrolladores y diseñadores que construyeron sus carreras trabajando con jerarquías de plantillas, personalización de functions.php y la API del Customizer, 4.9 representa un panorama familiar que en gran parte ha dado paso a nuevos paradigmas.

La transición de WordPress 4.9 a la era Gutenberg no estuvo exenta de desafíos y controversias. Los problemas de compatibilidad de plugins, los requisitos de adaptación de temas y las necesidades de capacitación de usuarios demandaron atención de la comunidad WordPress. Sin embargo, los beneficios a largo plazo del enfoque basado en bloques - consistencia del contenido, flexibilidad de diseño y reducción de la dependencia del código personalizado - han demostrado ser ventajas significativas para la plataforma.

Para contexto histórico y propósitos educativos, comprender WordPress 4.9 sigue siendo valioso. Muchos sitios existentes continúan funcionando con temas construidos usando plantillas PHP tradicionales, y las habilidades requeridas para mantener y extender estos sitios siguen siendo relevantes. Además, comprender la arquitectura pre-Gutenberg ayuda a los desarrolladores a apreciar las decisiones de diseño que dieron forma al editor de bloques y las capacidades de Full Site Editing.

#Conclusión

El viaje de WordPress 4.9 a la era Gutenberg representa una de las transiciones más significativas en la historia de la plataforma. Aunque el cambio fue recibido inicialmente con resistencia y división, la comunidad WordPress ha abrazado en gran medida el enfoque basado en bloques, reconociendo su potencial para la flexibilidad del contenido, la consistencia del diseño y la reducción de la complejidad del desarrollo.

WordPress 4.9 será recordado como un momento pivotal - una plataforma sofisticada que había alcanzado un alto nivel de madurez mientras se encontraba en el umbral de la transformación. Las características introducidas en esa versión, desde la integración de CodeMirror hasta las mejoras del Customizer, representaron la culminación de años de mejora incremental que habían convertido a WordPress en el sistema de gestión de contenidos más popular del mundo.

A medida que WordPress continúa evolucionando, con el proyecto Gutenberg introduciendo regularmente nuevas características y mejoras, la plataforma mantiene su compromiso con el empoderamiento del usuario y la flexibilidad del desarrollador. Ya sea construyendo sitios usando temas PHP tradicionales, enfoques híbridos o temas de bloques completos, los desarrolladores y diseñadores continúan teniendo opciones que se adaptan a sus necesidades y preferencias.

El legado de WordPress 4.9 vive no solo en los sitios que continúan funcionando sobre su base, sino en las lecciones aprendidas durante la transición a la era de bloques - lecciones sobre comunidad, cambio y la búsqueda continua de democratizar la publicación en la web.