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 WordPress 5.0, que convirtió a Gutenberg en el editor predeterminado.

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

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. Esta retrospectiva se limita a lo que dicen el anuncio oficial, la guía de campo de 4.9 en make.wordpress.org y la página de la versión en la documentación de WordPress, con enlaces para que puedas comprobar cada punto.

#Cuándo salió WordPress 4.9 y quién lo lideró

WordPress 4.9 “Tipton”, nombrado en honor al músico y director de banda de jazz Billy Tipton, se anunció el 16 de noviembre de 2017 en el anuncio oficial. La página de la versión en la documentación de WordPress fecha el lanzamiento el 15 de noviembre, que es el mismo momento visto desde un huso horario de Estados Unidos. Fue la última versión importante en la que el editor clásico era el predeterminado.

Según el anuncio, la versión fue liderada por Mel Choyce y Weston Ruter. Acredita a 443 colaboradores, 185 de ellos por primera vez, y salió traducida por completo a 43 idiomas. La página de documentación añade dos datos útiles cuando inspeccionas una instalación antigua: la versión de la base de datos se mantuvo en 38590 y la versión corresponde a la revisión 42195 de Trac.

La guía de campo de 4.9, publicada antes del lanzamiento, cuenta unos 400 errores, 181 mejoras, 7 peticiones de funcionalidad y 42 tareas cerradas en el ciclo.

Por qué 4.9 importa visto en retrospectiva:

• fue la última versión con el editor clásico como predeterminado,
• llevó CodeMirror al core, y esa biblioteca sigue detrás de los campos de código del panel,
• terminó el trabajo de changesets del Personalizador iniciado en 4.7,
• su propio anuncio se escribió en Gutenberg y pedía a los lectores que probaran el nuevo editor.

#Qué cambió en el Personalizador de WordPress 4.9

#Borradores y cambios programados del Personalizador

Por primera vez podías hacer cambios de diseño (colores, CSS, widgets, menús), guardarlos como borrador y volver más tarde, sin publicar nada en vivo.

La base técnica era anterior al botón. Los changesets, una forma de guardar los cambios pendientes del Personalizador como una entrada customize_changeset identificada por un UUID, llegaron en WordPress 4.7. Como explica Weston Ruter en la nota para desarrolladores sobre changesets en 4.9, 4.7 no tenía interfaz para ellos. Un changeset vivía en una entrada auto-draft que se eliminaba al cabo de una semana salvo que volvieras a tocarla.

WordPress 4.9 añadió la interfaz. Tras el primer cambio aparece un botón con un engranaje junto al botón de publicar, que abre los ajustes de publicación: publicar, guardar borrador o programar. Un enlace para descartar cambios devuelve el Personalizador a su último estado publicado.

Antes de 4.9, hacer cambios de diseño significaba:

• editar el sitio en vivo (arriesgado),
• usar un entorno de staging (más configuración),
• pegar CSS a mano (difícil de revertir).

La programación funciona porque un changeset se publica cuando su entrada pasa al estado publish. La nota muestra que el mecanismo existía incluso antes de la interfaz, con un comando de WP-CLI que programa un cambio del título del sitio:

wp post create \
    --post_type=customize_changeset \
    --post_name=$( uuidgen ) \
    --post_status=future \
    --post_date="2018-01-01 00:00:00" \
    --post_content='{"blogname":{"value":"Happy New Year!"}}'

Una advertencia práctica de la misma nota sigue vigente. Los changesets programados se publican a través de WP-Cron, normalmente en el minuto siguiente a la hora fijada. En un sitio con pocas visitas el cron puede no ejecutarse a tiempo, y la nota recomienda una tarea cron del sistema que llame a wp-cron.php cada minuto cuando la hora exacta importa.

#Enlaces de vista previa para clientes

Previsualizar un changeset es una operación de solo lectura, así que cualquiera con el UUID puede ver el sitio con los cambios pendientes aplicados, haya iniciado sesión o no. WordPress 4.9 lo convirtió en un enlace de vista previa que puedes enviar a compañeros y clientes. El anuncio lo presenta como una forma de recoger opiniones antes de programar la publicación, y así lo usaban las agencias.

#Bloqueo de diseño y autoguardado en el Personalizador

Como un borrador guardado ahora se carga para cualquier usuario que abra el Personalizador, dos personas podían pisarse el trabajo. La respuesta de 4.9 fue el bloqueo de changesets, inspirado en el bloqueo de entradas: un segundo usuario ve un aviso de bloqueo y puede volver atrás o tomar el control, y el Personalizador usa WP Heartbeat para mantener el bloqueo activo.

El autoguardado también mejoró. Si cerrabas el navegador por error, el Personalizador te ofrecía restaurar tu último auto-draft la siguiente vez que lo abrías, y las páginas o entradas creadas desde el Personalizador durante un borrador aparecían marcadas como borradores de personalización en la lista del administrador.

#Changesets en modo lineal y en modo ramificado

El core funciona en lo que la nota llama modo lineal: solo puede haber un changeset guardado como borrador o programado a la vez. Si programas un cambio de título para la semana que viene, no puedes publicar hoy un cambio independiente del lema sin descartar o publicar ambos. Cambiar de tema también queda bloqueado mientras exista un changeset en borrador o programado.

Los sitios con varios usuarios intensivos del Personalizador pueden recuperar el comportamiento anterior, en el que cada sesión tiene su propio changeset, con un filtro:

add_filter( 'customize_changeset_branching', '__return_true' );

#Explorar y cambiar temas desde el Personalizador

El Personalizador estrenó un explorador de temas. El anuncio dice que podías buscar, explorar y previsualizar más de 2600 temas sin salir del Personalizador, con filtros por tema, características y diseño, y la guía de campo señala que por primera vez podías instalar temas de WordPress.org en el mismo flujo.

Cambiar de tema también se volvió menos destructivo. La documentación menciona una asignación por aproximación de menús y widgets (Trac #39692), de modo que los menús y widgets tenían más probabilidades de quedar en un lugar razonable en el tema nuevo. El flujo de creación de menús en el Personalizador también se rehízo, con nuevas instrucciones para crear un menú y asignarlo a una ubicación.

#Cómo cambió CodeMirror la edición de código en WordPress 4.9

Los editores de código del panel por fin recibieron resaltado de sintaxis, linting y autocompletado. La nota sobre edición de código enumera cuatro lugares que recibieron CodeMirror: CSS adicional en el Personalizador, el widget de HTML personalizado y los editores de archivos de temas y plugins.

Era un segundo intento. El resaltado de sintaxis en los editores de archivos apareció en WordPress 2.8 con una biblioteca llamada CodePress y se retiró en 2.8.1 por problemas de compatibilidad con navegadores. La función se volvió a proponer en el ticket #12423 de Trac y tardó ocho años en volver.

Lo que añadió CodeMirror en 4.9:

• Resaltado de sintaxis con modos incluidos como css, htmlmixed, javascript, php, sql, markdown y yaml.
• Cierre automático y emparejado de corchetes, llaves y etiquetas.
• Linting con CSSLint, JSHint, HTMLHint y JSONLint.
• Autocompletado de propiedades CSS, etiquetas HTML y objetos DOM de JavaScript.

Cuando un linter encuentra un error, WordPress te pide corregirlo antes de guardar. En CSS adicional y en el widget de HTML personalizado no se puede guardar hasta que el código sea válido; en los editores de archivos puedes ignorar el aviso y guardar igualmente. En 4.7, CSS adicional solo contaba llaves y corchetes, lo que daba falsos positivos cuando una llave estaba dentro de un comentario. Esa comprobación en el servidor se eliminó en favor de CSSLint.

Dos detalles muestran el cuidado con que se acotó el cambio. CodeMirror no se añadió a la pestaña de texto del editor de entradas, por las dudas de accesibilidad para usuarios de lectores de pantalla y porque Gutenberg iba a reemplazar ese editor. Y cada usuario recibió en su perfil una opción para desactivar el resaltado de sintaxis.

#Ediciones PHP protegidas en los editores de temas y plugins

El anuncio lo resume como evitar la temida pantalla blanca. El mecanismo, del ticket #21622 de Trac, es una reversión. Al guardar un archivo PHP en el editor de temas o de plugins, WordPress guarda una copia del contenido anterior, escribe tu cambio y hace una petición loopback a la pantalla del editor con tus cookies. Si esa petición da un error fatal, se restaura el archivo anterior. Si no, una segunda petición loopback comprueba la portada. Ante cualquier error fatal recibes el mensaje y tu cambio se queda en el editor para corregirlo. Si las peticiones loopback no pueden completarse, el cambio se revierte y se te indica que uses SFTP.

Los guardados pasan a hacerse por Ajax, y salir de la página con cambios sin guardar abre un diálogo de confirmación. Antes de 4.9, el editor de plugins intentaba detectar errores fatales desactivando y reactivando el plugin, lo que podía dejar desactivado un plugin crítico, y los temas no tenían ninguna protección.

Los editores también cambiaron en los detalles. La primera visita muestra un aviso de que editar archivos directamente es arriesgado, y el editor de temas te remite a CSS adicional. Se pueden editar más tipos de archivo (entre ellos js, json, scss, md, svg y yml), se pueden abrir archivos a más de dos directorios de profundidad y la lista de archivos pasó a ser un árbol desplegable.

#Usar el editor de código de WordPress en tu propio plugin

CodeMirror en 4.9 también es una API. La función wp_enqueue_code_editor() acepta un type de archivo, un nombre de file o un array de ajustes codemirror, elige valores por defecto adecuados para el lenguaje y devuelve los ajustes, o false si el usuario ha desactivado el resaltado de sintaxis. El ejemplo de la nota convierte el campo de biografía del perfil en un editor HTML:

add_action( 'admin_enqueue_scripts', function() {
	if ( 'profile' !== get_current_screen()->id ) {
		return;
	}

	// Carga el editor de código y los ajustes para HTML.
	$settings = wp_enqueue_code_editor( array( 'type' => 'text/html' ) );

	// Sal si el usuario ha desactivado CodeMirror.
	if ( false === $settings ) {
		return;
	}

	wp_add_inline_script(
		'code-editor',
		sprintf(
			'jQuery( function() { wp.codeEditor.initialize( "description", %s ); } );',
			wp_json_encode( $settings )
		)
	);
} );

Antes de devolverse, los ajustes pasan por el filtro wp_code_editor_settings, que puedes usar para cambiar opciones como lineWrapping de forma global. El core registra la biblioteca con el identificador wp-codemirror y la expone como wp.CodeMirror en lugar de un objeto global CodeMirror, así no choca con plugins que incluyen su propia copia. En el Personalizador, el mismo editor está disponible como control mediante WP_Customize_Code_Editor_Control.

#Cambios en los widgets de WordPress 4.9

#Widget de galería y medios en el widget de texto

Añadir galerías de fotos a la barra lateral se volvió nativo. El widget de galería siguió a los widgets de imagen y de medios añadidos en WordPress 4.8, y la documentación lo registra como el ticket #41914 de Trac.

El widget de texto también cambió. Ganó un botón para añadir medios (imágenes, vídeo y audio) y empezó a ejecutar shortcodes. Esa petición (Trac #10457) llevaba abierta más de ocho años, y significó que plugins y temas ya no necesitaban add_filter( 'widget_text', 'do_shortcode' ). Los widgets de texto aceptan además oEmbeds, así que una URL de YouTube pegada en el widget se convierte en un reproductor incrustado, y el widget de vídeo aprendió a manejar proveedores distintos de YouTube y Vimeo.

En la pantalla de widgets del administrador, un nuevo estado de cambios pendientes indica cuándo se ha guardado un widget y pide confirmación si intentas salir sin guardar.

#Seguridad, roles y cambios para desarrolladores en WordPress 4.9

#Nuevas capacidades y seguridad de la cuenta

La página de documentación y la guía de campo recogen varios cambios que importan a quien gestiona usuarios:

• las capacidades singulares activate_plugin y deactivate_plugin, comprobadas contra un plugin concreto, de modo que un rol puede activar unos plugins y otros no,
• capacidades propias para instalar y actualizar archivos de idioma,
• un enlace de confirmación por correo cuando un usuario intenta cambiar su dirección de email (Trac #16470),
• una inicialización más fiable de roles y capacidades cuando el código cambia de sitio en multisitio, además de la nueva función get_site_by().

#API JS del Personalizador, MediaElement y retiradas

Para desarrolladores, la API JavaScript del Personalizador eliminó muchos puntos de fricción enumerados en la guía de campo: parámetros por defecto para los constructores, plantillas base para controles, un control de fecha y hora, y notificaciones a nivel global, de panel y de sección. MediaElement.js se actualizó a la 4.2.6, que según el anuncio elimina la dependencia de jQuery, mejora la accesibilidad y corrige muchos errores.

Algunas cosas salieron del core. Se eliminó SWFUpload y Press This pasó a ser un plugin aparte. La API REST empezó a exigir parámetros con nombre en las expresiones regulares de las rutas, de modo que las coincidencias numéricas ya no funcionan. La documentación también indica que el core y su batería de pruebas unitarias eran totalmente compatibles con el entonces próximo PHP 7.2.

#De WordPress 4.9 a 5.0 con Gutenberg

#Cronología de WordPress de la 4.9 a la 6.x

2017 (4.9):

• Última versión con el editor clásico como predeterminado
• Gutenberg en desarrollo como plugin, con el anuncio pidiendo probadores
• CodeMirror fuera del editor de entradas porque Gutenberg iba a sustituirlo

2018 (5.0):

• El editor Gutenberg fue introducido como el editor predeterminado
• El plugin Classic Editor quedó disponible para los sitios que querían la pantalla antigua

2019 a 2021:

• Gutenberg maduró con cada actualización
• Los patrones de bloques fueron introducidos
• El desarrollo de Full Site Editing (FSE) comenzó a tomar forma

De 2022 en adelante:

• Temas de bloques y Editor del sitio en el core
• Los temas clásicos y el Personalizador siguen siendo compatibles

#Classic Editor y Gutenberg después de 4.9

Apenas un año después de 4.9, WordPress 5.0 llegó con Gutenberg. La comunidad se dividió en dos campos:

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

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

#Qué funciones de WordPress 4.9 siguen vigentes

#CodeMirror y borradores del Personalizador hoy

CodeMirror:

• Sigue utilizándose en los editores de archivos de temas y plugins y en CSS adicional
• Sigue disponible para plugins mediante wp_enqueue_code_editor()

Borradores del Personalizador:

• Siguen disponibles en los temas clásicos que usan el Personalizador
• La programación sigue dependiendo de WP-Cron, así que el consejo sobre cron de 2017 sigue valiendo
• Los temas de bloques usan el Editor del sitio, con sus propias revisiones y vista previa

Seguridad del editor de archivos:

• La reversión por loopback de 4.9 sigue siendo la razón por la que una edición PHP rota en el panel no suele tumbar el sitio
• La constante DISALLOW_FILE_EDIT en wp-config.php sigue desactivando por completo los editores de archivos en producción

#Diferencias entre WordPress 4.9 y WordPress 6.x

#Cómo cambió el desarrollo de temas desde WordPress 4.9

Desarrollo de temas:

• 4.9: Plantillas PHP, functions.php, hooks y filtros
• 6.x: Temas de bloques, theme.json, Editor del sitio

En la era de 4.9, construir un tema requería conocer bien PHP, la jerarquía de plantillas de WordPress y el sistema de hooks. Los temas de bloques se definen sobre todo mediante theme.json y plantillas HTML, con PHP reservado para funcionalidades concretas.

Edición de contenido:

• 4.9: Editor clásico, shortcodes, widgets
• 6.x: Bloques Gutenberg, patrones, plantillas

Personalización:

• 4.9: Personalizador, opciones de tema
• 6.x: Editor del sitio, ajustes de bloques

Herramientas para desarrolladores:

• 4.9: CodeMirror, WP_DEBUG
• 6.x: Herramientas de desarrollo de bloques como @wordpress/scripts

#Funciones sustituidas y añadidas desde WordPress 4.9

Sustituido u opcional:

• Editor clásico (disponible como plugin opcional)
• Muchas funciones del Personalizador (sustituidas por el Editor del sitio en los temas de bloques)
• Pantallas de widgets (áreas de widgets basadas en bloques)

Sigue ahí:

• CodeMirror en los campos de código
• Ediciones PHP protegidas en los editores de archivos

Nuevo:

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

#Qué aprender de WordPress 4.9 como desarrollador

#1. Primero la infraestructura, después la interfaz

Los changesets llegaron en 4.7 sin interfaz, y 4.9 añadió encima borradores, programación y bloqueo. Separar el almacenamiento de la interfaz permitió entregar la función en dos versiones sin romper los sitios existentes.

#2. Compatibilidad con versiones anteriores en WordPress

WordPress mantuvo la compatibilidad hacia atrás incluso a través de cambios importantes. El plugin Classic Editor mantuvo funcionando los sitios antiguos después de 5.0, y el soporte de shortcodes en el widget de texto eliminó un filtro que temas y plugins añadían a mano.

#3. Redes de seguridad para quien edita en producción

La reversión por loopback, el linting que impide guardar y el aviso en los editores de archivos parten de que la gente editará sitios en vivo. Prepararse para eso resultó más útil que fingir que no ocurriría.

#Resumen de WordPress 4.9 y sus logros clave

WordPress 4.9 “Tipton” fue la última versión del WordPress “clásico” antes del editor Gutenberg.

Logros clave:

• Borradores, programación, bloqueo y enlaces de vista previa en el Personalizador
• CodeMirror con linting en CSS adicional, el widget de HTML personalizado y los editores de archivos
• Ediciones PHP protegidas que revierten los errores fatales
• Widget de galería, shortcodes y medios en el widget de texto
• Nuevas capacidades y confirmación del cambio de email

Para desarrolladores:

• Lee la guía de campo de 4.9 si mantienes un tema clásico, porque buena parte de la API del Personalizador y del editor de código que usas viene de ahí
• Usa wp_enqueue_code_editor() en lugar de incluir tu propia copia de CodeMirror
• Configura un cron real si dependes de changesets programados