WordPress 5.6 «Simone» ha salido y estamos emocionados de sumergirnos con vosotros en las características y adiciones más interesantes fusionadas en el núcleo con la última versión de WordPress de 2020.
Como en las versiones anteriores, WordPress 5.6 incluye varias versiones del Editor de Bloques que mejoran la experiencia de edición para los usuarios de WordPress que aún no tienen el plugin de Gutenberg instalado y actualizado en sus sitios web.
Sin embargo, no todo es sobre el Editor de Bloques. Varias características han sido añadidas al núcleo de WordPress, como por ejemplo el nuevo tema por defectoTwenty Twenty-One, actualizaciones automáticas para las versiones más importantes, mejor soporte para PHP 8.0, contraseñas de aplicaciones para la autenticación de la API REST.
Y hay mucho más en WordPress 5.6. Repasaremos las mejoras de accesibilidad, las mejoras en la interfaz de usuario, toneladas de correcciones de errores y una enorme lista de cambios para los desarrolladores.
Si quieres leer más sobre el ciclo de desarrollo de WordPress 5.6, consulta los siguientes enlaces:
- 20 de octubre de 2020: Beta 1
- 27 de octubre de 2020: Beta 2
- 2 de noviembre de 2020: Beta 3
- 12 de noviembre de 2020: Beta 4
- 17 de noviembre de 2020: RC 1
- 7 de diciembre de 2020: Prueba de fuego para el lanzamiento de WordPress 5.6
- 8 de diciembre de 2020: Publicación de WordPress 5.6 «Simone»
¿Listo para sumergirte? Vamos a ello:
Cuáles son las novedades del Editor de Bloques
Varias versiones del plugin de Gutenberg se han fusionado en el núcleo con WordPress 5.6, por lo que los usuarios y escritores de WordPress deberían notar varias mejoras en el editor. Veremos patrones de bloque mejorados, recuento de palabras en el panel de información, navegación de teclado mejorada, interfaz de usuario de arrastrar y soltar mejorada, y muchos más.
Para una lista más completa con todas las mejoras y cambios añadidos al editor de bloques, mira los anuncios de lanzamiento: 8.6, 8.7, 8.8, 8.9, 9.0, 9.1 y 9.2. Las correcciones de errores y las mejoras de rendimiento implementadas en Gutenberg 9.3 y 9.4 también están incluidas en WordPress 5.6.
Vamos a sumergirnos en los cambios más interesantes que veremos en el editor de bloques.
- Bloques, patrones y mejoras de la interfaz de usuario
- API de Bloques V2
- Características adicionales y mejoras para los desarrolladores de bloques
Bloques, Patrones y Mejoras de la Interfaz de Usuario
Las nuevas características de los bloques, mejoras y correcciones de errores mejorarán la experiencia de edición en general. Además, se ha hecho un gran trabajo en cuanto a la accesibilidad. A continuación encontrarás nuestra cuidada selección de las características más interesantes que verás en el editor de bloques una vez que actualices tu sitio web a WordPress 5.6.
Controles de posición para los Videos en el Bloque de Fondo
Añadido al Bloque de Fondo desde Gutenberg 8.6, los controles de posición para los videos permiten a los usuarios mover el punto focal y establecer una posición personalizada para los videos. Esta funcionalidad solo estaba anteriormente disponible para las imágenes de fondo.
Los valores de posición se establecen haciendo clic en cualquier lugar del selector de puntos focales y/o utilizando las teclas de flecha del teclado. Puedes modificar los valores por 10 manteniendo pulsada la tecla shift (ver también #22531).
Actualizaciones de los Patrones de Bloque
WordPress 5.6 también incluye varias mejoras en los patrones de bloques añadidas con Gutenberg 8.6.
El diseño, el texto y el color del encabezado y el párrafo grande han sido actualizados (#23858)
El encabezado en Dos columnas de texto ha sido desplazado del bloque de texto y se ha colocado encima de las columnas (#23853)
El patrón de la Cita ahora incluye una imagen en la parte superior y un separador en la parte inferior.
Se ha añadido un nuevo patrón de encabezamiento y párrafo con Gutenberg 8.7 (#24143).
Una buena mejora de la usabilidad del insertador de bloques es el desplegable de categorías de patrones de bloques, que permite filtrar los patrones por categorías. Esto es extremadamente útil cuando tienes un montón de patrones entre los que elegir (#24954).
Soporte para Subtítulos de Video
Los bloques de video soportan los subtítulos de video.
Los editores y creadores de contenido deben proporcionar subtítulos de vídeo en formato WebVTT (Web Video Text Tracks Format), que es «un formato para mostrar pistas de texto cronometradas (como los subtítulos) utilizando el elemento <track>» (#25861).
Una vez que hayas cargado tus archivos .vtt, los visitantes del sitio podrán habilitar subtítulos en su idioma favorito.
Transformar Múltiples Bloques en un Bloque de Columnas
Una interesante mejora de la usabilidad es la capacidad de convertir múltiples bloques seleccionados en un bloque de columnas.
Solo tienes que seleccionar los bloques que quieres mostrar en las columnas y luego hacer clic en el botón superior derecho de la barra de herramientas de bloques.
Cada bloque seleccionado se convertirá en una columna de un bloque de columnas.
Patrones de Fondo en el Bloque de Fondo
Los bloques de fondo pueden mostrar patrones de fondo.
Para añadir un patrón de fondo, sube una imagen de patrón, y luego activa la opción Fondo repetido (aquí tienes todo lo que necesitas saber sobre la Biblioteca de Medios en WordPress).
Cuando termines, ajusta el selector de puntos focales según tus necesidades y prueba diferentes combinaciones con fondos fijos.
Control del Tamaño de la Imagen Añadido al Bloque Medios y Texto
Con Gutenberg 9.1, se ha incorporadoo un nuevo control del tamaño de las imágenes en el Bloque Medios y Texto.
Los usuarios pueden ahora elegir entre todos los tamaños de imagen disponibles (#24795).
API de Bloques V2
Una nueva versión de la API de bloques permite a los bloques renderizar su elemento de envoltura. El objetivo de la nueva versión de la API es aligerar el DOM del editor y hacer que coincida con el contenido de la página principal. Según Ella van Durpe:
El mayor beneficio de esto es que los temas y los plugins pueden estilizar más fácilmente los contenidos de los bloques si el marcado es el mismo en el editor.
La nueva versión requiere declarar la propiedad de la apiVersion en el registro del tipo de bloque:
registerBlockType( name, { apiVersion: 2 } );La nueva API también requiere el gancho useBlockProps en la función de Edit del bloque. Este gancho marca el elemento de envoltura de un bloque como un elemento de bloque.
Cualquier propiedad pasada a este gancho será fusionada y devuelta al elemento de envoltura. El siguiente ejemplo de las notas de desarrollo muestra un caso de uso simple:
import { useBlockProps } from '@wordpress/block-editor';
function Edit( { attributes } ) {
const blockProps = useBlockProps( {
className: someClassName,
style: { color: 'blue' },
} );
return <p { ...blockProps }>{ attributes.content }</p>;
}Para ver más ejemplos, consulta la versión 2 de la API de bloques.
Características Adicionales y Mejoras para los Desarrolladores de Bloques
Además de la Versión 2 de la API de bloques, aquí tenéis una lista de adiciones para que los desarrolladores la revisen.
El Bloque Soporta la API
La API de soporte de bloques permite a los desarrolladores de bloques agregar características a sus bloques. Los colores, los fondos, los tamaños de fuente son solo algunas de las muchas características que se pueden agregar a los bloques a través de la API de soporte de bloques.
WordPress 5.6 también introduce varios nuevos soportes de bloques «para aumentar la consistencia y facilitar la introducción de estas opciones en los bloques».
Los desarrolladores pueden utilizar los nuevos soportes de bloque añadiendo las claves correspondientes a la propiedad de los supports del archivo block.json o directamente en la función registerBlockType.
El siguiente ejemplo de Block Supports dev note muestra cómo funciona:
supports: {
color: {
background: true, // Enable background color UI control.
gradient: true, // Enable gradient color UI control.
text: true // Enable text color UI control.
},
fontSize: true, // Enable font size UI control.
lineHeight: true // Enable line height UI control.
}El valor de estilo se adjuntará automáticamente al elemento de la envoltura ya sea a través de la clase has-<value>-<preset-category> (para valores preestablecidos) o con un elemento de style (para valores personalizados).
Por esta razón, los soportes de bloque están pensados para ser usados con el nuevo API de bloques V2.
Los soportes de bloque pueden ser usados con bloques dinámicos también.
createBlocksFromInnerBlocksTemplate API
Los desarrolladores pueden utilizar el component eI InnerBlocks para crear bloques personalizados que contengan otros bloques. Ejemplos de ello son el bloque Columnas y el bloque Enlaces sociales.
El nuevo createBlocksFromInnerBlocksTemplate API de bloques permite crear bloques a partir de la plantilla de InnerBlocks.
Revisa las notas de desarrollo para una vista más detallada y un ejemplo de código.
Componentes de la Barra de Herramientas
Un par de cambios afectan también a los componentes de la barra de herramientas:
1. Componente ToolbarGroup
Antes de WordPress 5.6, el componente Toolbar permitía a los desarrolladores agrupar opciones relacionadas en un contenedor común. Ahora, se debería utilizar un nuevo componente ToolbarGroup en su lugar.
<BlockControls>
<ToolbarGroup>
<ToolbarButton />
</ToolbarGroup>
</BlockControls>2. Componentes de ToolbarButton y ToolbarItem
El uso de elementos tabulables directamente como elementos de la barra de herramientas (i.e. <button>) ha sido desaprobado. Con el fin de mejorar la accesibilidad, los elementos de la barra de herramientas pueden añadirse utilizando ToolbarButton para los botones y ToolbarItem para otros controles. En el ejemplo que figura a continuación se muestran un botón y un menú desplegable:
<BlockControls>
<ToolbarItem as="button" />
<ToolbarButton />
<ToolbarItem>
{ ( itemProps ) => ( <DropdownMenu toggleProps={ itemProps } /> ) }
</ToolbarItem>
</BlockControls>Desactivar los Patrones de los Bloques del núcleo
Los patrones de núcleo ahora pueden ser desactivados usando la bandera de soporte de los core-block-patterns (#24042)
Desactivar el Editor de Imágenes En Línea
Gutenberg 8.4 añadió una función de edición de imágenes en línea que permite a los usuarios editar imágenes directamente desde el Editor de Bloques.
Los desarrolladores pueden ahora deshabilitar el Editor de Imágenes usando el filtro block_editor_settings (#23966):
add_filter( 'block_editor_settings', function( $settings ) {
$settings['imageEditing'] = false;
return $settings;
} );
Los Bloques Reutilizables Fueron Trasladados a un Paquete Separado
Los bloques reutilizables, que antes formaban parte del paquete @wordpress/editor, se han trasladado al paquete @wordpress/reusable-blocks para que estén disponibles en otros editores.
Un nuevo Tema por Defecto: Twenty Twenty-One
WordPress 5.6 incluye un nuevo tema por defecto. Twenty Twenty-One es un tema de WordPress muy accesible y minimalista con un diseño de una sola columna y una barra lateral al pie de página.
El nuevo tema utiliza una pila de fuentes del sistema y una paleta de colores mínimalistas basada en colores de fondo pastel.
Puedes leer mucho más sobre el Twenty Twenty-One en nuestra entrada de blog en: Twenty Twenty-One: Una Inmersión Profunda en el Nuevo Tema por Defecto de WordPress.
Actualizaciones Automáticas de los Principales Lanzamientos
Las actualizaciones automáticas son una función fundamental introducida con WordPress 3.7 con el fin de mejorar la seguridad del sitio y facilitar a los administradores del mismo el mantenimiento de sus sitios web de WordPress al día.
Si bien en las versiones anteriores se han aplicado actualizaciones automáticas menores del núcleo, con WordPress 5.6 los administradores del sitio pueden ahora habilitar manualmente las actualizaciones automáticas para las versiones principales también (más sobre eso en unos segundos).
Desafortunadamente, esta crucial tarea de mantenimiento podría ser todavía un poco confusa para los no usuarios de tecnología. Puedes leer más acerca de cómo funcionan las actualizaciones automáticas en nuestra entrada del blog Una inmersión profunda en las actualizaciones automáticas de WordPress.
Así, WordPress 5.6 introduce una nueva interfaz que permite a los administradores del sitio habilitar actualizaciones automáticas para los principales lanzamientos del núcleo.
El alcance de esta función cambió durante el ciclo beta de WordPress 5.6 y la nota de desarrollo original ha sido reemplazada. En palabras de Jb Audras,
El alcance inicial de las actualizaciones automáticas del núcleo se ha trasladado a:
- Proporcionar algunas actualizaciones al diseño de la UI.
- Para las instalaciones existentes, el comportamiento seguirá siendo el mismo de hoy: las actualizaciones menores estarán activadas por defecto, pero el usuario debe activar las actualizaciones mayores (las constantes y los filtros que ya están en uso por los hosts o agencias seguirán teniendo prioridad).
- Para las nuevas instalaciones, el comportamiento por defecto cambiará: las actualizaciones menores y las actualizaciones mayores estarán activadas por defecto.
A partir de WordPress 5.6, puedes elegir las actualizaciones automáticas para las versiones principales en la pantalla Actualizaciones, donde una nueva interfaz de usuario proporciona una casilla de verificación que te permite Activar las actualizaciones automáticas para todas las nuevas versiones de WordPress.
Una vez que hayas activado las actualizaciones automáticas del núcleo para las versiones principales, puedes entonces habilitarlas para que se activen para el mantenimiento y la seguridad solamente haciendo clic en Cambiar a actualizaciones automáticas para las versiones de mantenimiento y seguridad solamente.
Principales Actualizaciones Automáticas del Núcleo para Desarrolladores
En primer lugar, cuando se habilitan las actualizaciones automáticas de los núcleos principales, la opción auto_update_core_major se almacena en la base de datos con la option_value habilitada. Por lo tanto, si get_site_option( 'auto_update_core_major' ) devuelve true, la casilla de verificación de actualizaciones automáticas está marcada.
Luego WordPress comprueba si las actualizaciones automáticas del núcleo principal están habilitadas a través de la constante WP_AUTO_UPDATE_CORE o el filtro allow_major_auto_core_updates y establece la casilla de verificación en consecuencia.
Los desarrolladores también pueden desactivar las principales actualizaciones automáticas del núcleo estableciendo la constante WP_AUTO_UPDATE_CORE en false o minor como se muestra a continuación (véase también Control de las actualizaciones de fondo a través de wp-config.php):
# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );
# Enables minor updates:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );Toma nota de que los posibles valores de WP_AUTO_UPDATE_CORE son true (todos), 'beta', 'rc', 'minor', false.
Otra opción para desactivar las actualizaciones automáticas de los principales núcleos por defecto es utilizar el nuevo filtro allow_major_auto_core_updates:
add_filter( 'allow_major_auto_core_updates', '_return_false' );Algunos Comentarios sobre la Incorporación de Actualizaciones Automáticas en el Núcleo
En diciembre de 2018, Matt Mullenweg compartió las nueve prioridades para 2019, en las que «Proporcionar una forma de que los usuarios se decidan por las actualizaciones automáticas de los principales lanzamientos de Núcleo» era la número 7. Tal vez un poco tarde, pero estamos llegando a eso.
Las principales actualizaciones automáticas del núcleo deberían tener un gran impacto en la seguridad y la experiencia general de WordPress. Una cosa parece estar clara: desde un punto de vista técnico, la función de las principales actualizaciones automáticas del núcleo es una tarea compleja que no se logra al 100% con el lanzamiento de WordPress 5.6.
Después de un reflexivo debate en Slack, Josepha Haden resumió las preocupaciones y preguntas de los colaboradores del Núcleo.
El principal objetivo a largo plazo es disponer de actualizaciones automáticas en la mayoría de los sitios web de WordPress para mejorar la seguridad en todo el ecosistema de WordPress (más del 30% de la web).
De todos modos, según Helen Hou-Sandí, desarrolladora principal del núcleo:
En mi mente hay algunas cosas técnicas muy difíciles de ejecutar y esto necesita una propiedad de producto técnico MUY disciplinada y enfocada.
Así que deberíamos ver cambios y mejoras adicionales en las principales actualizaciones automáticas del núcleo UI con el tiempo. Esto es lo que podemos esperar de ahora en adelante:
WordPress 5.6:
- En las instalaciones existentes, las actualizaciones importantes deben ser habilitadas por el usuario. Cualquier constante y filtro ya en uso tendrá prioridad. Las actualizaciones menores están habilitadas por defecto.
- En las nuevas instalaciones, tanto las actualizaciones menores como las mayores están habilitadas por defecto.
WordPress 5.6.1:
- Deberíamos ver algunos cambios en el núcleo de auto-actualización de la interfaz de usuario basados en la retroalimentación.
WordPress 5.7:
- Se debería incorporar un aviso en la pantalla de salud del sitio para cualquiera que opte por no recibir las principales actualizaciones automáticas.
- Se debe agregar una opción de actualización automática al proceso de instalación en WordPress 5.7.
Una gran preocupación con las actualizaciones automáticas del núcleo es la confianza de los usuarios. Según Helen:
Creo que todavía podemos hacer mucho trabajo para solicitar proactivamente la confianza de los usuarios, especialmente de aquellos que han tenido malas experiencias previas con WordPress y/o actualizaciones
Sin embargo, cada sitio web de WordPress es una mezcla de Núcleo, plugins y tema. En palabras de Helen:
Las actualizaciones del núcleo son bastante seguras y tienen algunas protecciones incorporadas, pero como los sitios pueden ejecutar cualquier código de cualquier fuente, no existe tal cosa como «100%» para «cada tipo de sitio web de WordPress».
Los usuarios que tengan habilitadas las actualizaciones automáticas básicas deberían hacer regularmente copias de seguridad de sus sitios web o elegir un web host que proporcione copias de seguridad automáticas en sus planes.
Las actualizaciones automáticas del núcleo también afectarán a la experiencia de actualización general, incluyendo las actualizaciones automáticas de los plugins y los temas. Joost de Valk señaló en un comentario:
Si activamos las actualizaciones automáticas del núcleo de WordPress de forma predeterminada, deberíamos hacer lo mismo con los plugins. De lo contrario, los plugins y los temas no pueden actualizarse para las cosas que necesitan arreglar debido a las actualizaciones del núcleo. Creo que los usuarios también esperan esto: si las actualizaciones de WordPress se hacen automáticamente, los plugins y los temas también deberían actualizarse automáticamente.
Cambios en la Salud del Sitio en WordPress 5.6
Junto con todas las características aquí discutidas, WordPress 5.6 también trae una versión mejorada de la herramienta de Salud del Sitio, que ahora se comporta de manera diferente en el background.
Validación de los Datos del Chequeo de Salud del Sitio
Un validador ahora comprueba las respuestas de emisión para las pruebas de salud del sitio. El validador descartará cualquier respuesta inválida, evitando que la herramienta de Salud del Sitio cause errores fatales y detenga cualquier otro control.
De ahora en adelante, las respuestas inválidas no afectarán al indicador de salud del sitio (#50145).
Comprobaciones Asincrónicas a través de REST Endpoind
La herramienta de salud del sitio es una poderosa herramienta de seguridad que permite a los propietarios del sitio conocer el estado de salud de sus sitios web.
Esta herramienta ejecuta una serie de pruebas de seguridad que proporcionan una visión general del estado de salud de tu sitio web.
Estas pruebas se dividen en dos categorías: pruebas directas, que se ejecutan en la carga de la página, y pruebas de sincronización, que pueden requerir algún tiempo para completarse, y se ejecutarán más tarde a través de llamadas de JavaScript.
Anteriormente, estas pruebas se ejecutaban con una llamada a admin-ajax.php. Con WordPress 5.6, las cosas se están alejando de admin-ajax.php y se usará un nuevo endpoint REST API en su lugar. A partir de WordPress 5.6, las pruebas asíncronas se pueden encontrar en el espacio de nombres /wp-json/wp-site-health/v1.
Gracias a la nueva mejora de la API de REST, los plugins y temas también pueden hacer uso de los puntos finales de REST y no se limitan a las acciones de Ajax para sus pruebas de salud.
Cada prueba asíncrona puede ahora declarar el argumento has_rest, que por defecto es false.
El siguiente código de wp-admin/includes/class-wp-site-health.php muestra el conjunto de pruebas asincrónicas en WordPress 5.6:
'async' => array(
'dotorg_communication' => array(
'label' => __( 'Communication with WordPress.org' ),
'test' => rest_url( 'wp-site-health/v1/tests/dotorg-communication' ),
'has_rest' => true,
'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_dotorg_communication' ),
),
'background_updates' => array(
'label' => __( 'Background updates' ),
'test' => rest_url( 'wp-site-health/v1/tests/background-updates' ),
'has_rest' => true,
'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_background_updates' ),
),
'loopback_requests' => array(
'label' => __( 'Loopback request' ),
'test' => rest_url( 'wp-site-health/v1/tests/loopback-requests' ),
'has_rest' => true,
'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_loopback_requests' ),
),
'authorization_header' => array(
'label' => __( 'Authorization header' ),
'test' => rest_url( 'wp-site-health/v1/tests/authorization-header' ),
'has_rest' => true,
'headers' => array( 'Authorization' => 'Basic ' . base64_encode( 'user:pwd' ) ),
'skip_cron' => true,
),
),Chequeos Programados de la Salud del Sitio:
Aunque se han implementado pruebas asincrónicas para evitar cargas lentas de páginas y tiempos de espera, tal preocupación no existe con las pruebas programadas.
Teniendo esto en cuenta, además del argumento has_rest que mencionamos anteriormente, las matrices de prueba también pueden declarar el argumento async_direct_test (usando el código anterior), que debería ser una instancia llamable de una prueba.
Si se ejecuta una prueba durante un evento programado, la prueba no utilizará el punto final de la API REST, sino que se ejecutará directamente.
Contraseñas de la Aplicación para la Autenticación de la API de REST
Application Passwords es un nuevo sistema para hacer solicitudes autenticadas a varias API de WordPress.
Las contraseñas tienen 24 caracteres y consisten en mayúsculas, minúsculas y números, que pueden ser generados manualmente o a través de la API REST.
Para generar manualmente una nueva contraseña de la aplicación, navega a la pantalla de tu perfil y desplázate hacia abajo en la página.
Elige un nombre para la contraseña de tu solicitud y confírmalo. WordPress mostrará tu nueva contraseña.
Las contraseñas de las aplicaciones se muestran en trozos de 4 caracteres, separados por espacios, como se muestra a continuación:
gsUc UhkU 0ScI gdRd TGoU vrW5Sin embargo, las contraseñas pueden ser usadas con o sin espacios:
Las contraseñas de la aplicación que se pasan por el flujo de autorización no incluyen espacios. Están estrictamente allí para facilitar que alguien que mira una larga cadena pueda mantener su lugar si la ingresa manualmente.
Se pueden usar en trozos, sin espacios, o – caray – si quisieras, probablemente podrías añadir un espacio después de cada caracter.
En la pantalla de perfil de usuario, puedes ver, crear y revocar las contraseñas de la aplicación. Las columnas «Last Used» y «Last IP» te permiten encontrar fácilmente las contraseñas que ya no se utilizan y que deben ser revocadas.
En el momento de redactar este documento, las contraseñas de las aplicaciones pueden utilizarse con las solicitudes autenticadas por la API REST y con la API XML-RPC heredada. Sin embargo, en el futuro deberíamos ver que las contraseñas de las aplicaciones se utilizan con otras API. George Stephanis nos lo explica:
El esquema de autenticación de contraseñas de la aplicación también puede aplicarse a futuras API para WordPress a medida que estén disponibles. Por ejemplo, si GraphQL u otros sistemas están habilitados en WordPress, las contraseñas de las aplicaciones les proporcionarán una infraestructura de autenticación sólida y establecida para construirse desde el principio.
No es posible utilizar las contraseñas de la aplicación en wp-login.php.
Para una visión más cercana de esta función y una mayor comprensión técnica, asegúrase de revisar los siguientes enlaces:
- Propuesta: Autenticación de la API de REST / Contraseñas de la aplicación
- Contraseñas de la aplicación: Guía de integración
- El plugin de contraseñas de la aplicación
Mejor Soporte para PHP 8
PHP 8.0 incluye toneladas de nuevas características y optimizaciones que lo convierten en un verdadero hito dentro de la evolución del lenguaje. La nueva versión de PHP introduce muchas actualizaciones rompiendo la compatibilidad con las versiones anteriores y muchas características obsoletas han sido oficialmente eliminadas. Por lo tanto, agregar soporte para PHP 8 en WordPress es un gran desafío.
De hecho, aunque los colaboradores del núcleo de WordPress pusieron grandes esfuerzos en hacer compatible WordPress 5.6 con PHP 8, no deberíamos esperar que se descubrieran todos los problemas posibles. El objetivo aquí es llegar a un punto en el que todo el ecosistema de WordPress sea compatible con PHP 8, lo cual parece ser un hueso duro de roer por el momento.
Además, un sitio web de WordPress incluye al menos un tema y un número variable de plugins. Por lo tanto, lo que podemos esperar es un buen soporte para PHP 8 en el núcleo de WordPress, pero es difícil de creer que los plugins y temas añadan rápidamente soporte para PHP 8.
Estamos de acuerdo con Jonathan Desrosiers cuando afirma:
El estado del soporte de PHP 8 dentro del ecosistema más amplio (plugins, temas, etc.) es imposible de conocer. Por esa razón, WordPress 5.6 debe ser considerado «compatible beta» con PHP 8.
«Beta compatible con PHP 8» parece una buena expresión para representar un proceso en curso que aún requiere mucho esfuerzo, pero al mismo tiempo reconoce el gran trabajo realizado hasta ahora.
Sin embargo,
Todos los desarrolladores de plugins y temas, así como las comunidades de alojamiento, están llamados a hacer su código compatible con PHP 8. Esto permitirá que WordPress logre una verdadera «compatibilidad total» más pronto, y sin que los usuarios finales tengan que llevar la carga.
Algunos Cambios en PHP 8 que se Deben Tener En Cuenta
Como mencionamos anteriormente, hacer que WordPress sea totalmente compatible con PHP 8 es un trabajo en progreso. Jonathan Desrosiers provee una lista de las características de PHP 8 y los cambios que los desarrolladores de WordPress deben tener en cuenta.
Parámetros Nombrados
Con los parámetros nombrados de PHP es ahora posible pasar argumentos a una función basada en el nombre del parámetro, en lugar de la posición del parámetro. Esto permite escribir código que se autodocumenta, los argumentos son independientes del orden, y los valores por defecto pueden ser omitidos arbitrariamente.
Desafortunadamente, los parámetros que se nombran actualmente pueden causar problemas de compatibilidad en WordPress. La razón principal es que los nombres de los parámetros están sujetos a cambios sin previo aviso hasta que se complete la auditoría actual. Así que, en el momento de escribir este artículo:
El uso de parámetros con nombre al llamar a las funciones y métodos de clase de WordPress no está explícitamente respaldado y se desaconseja en gran medida hasta que se pueda completar esta auditoría, ya que durante la misma los nombres de los parámetros están sujetos a cambios sin previo aviso. Cuando esta auditoría se haya completado, se anunciará en una futura nota de desarrollo.
Estrictas Validaciones de Tipo/Valor para las Funciones Internas
Al pasar un parámetro de tipo ilegal, las funciones internas y las definidas por el usuario se comportan de manera diferente. Las funciones definidas por el usuario arrojan un TypeError, pero las funciones internas se comportan de diversas maneras, dependiendo de varias condiciones.
Para eliminar estas inconsistencias, en PHP 8 las APIs internas de análisis de parámetros siempre generan un ThrowError en caso de una falta de coincidencia de tipo de parámetro.
La declaración de tipo estricto no se utiliza en WordPress Núcleo. Sin embargo, los colaboradores de núcleo están trabajando para evitar que los tipos inválidos se pasen a las funciones de núcleo. Hasta que ese trabajo sea completado, este cambio en PHP 8 puede conducir a TypeErrors, «especialmente si el tipo de un valor es cambiado incorrectamente a través de código enganchado a un filtro».
Chequeos Más Estrictos para los Operadores Aritméticos y de Bits
En versiones anteriores de PHP, se permitía el uso de operadores aritméticos y de bits para una matriz, recurso u objeto no sobrecargado, pero el comportamiento era inconsistente e incluso irrazonable a veces:
var_dump([] % [42]);
// int(0)Con PHP 8, el comportamiento es siempre el mismo y todos los operadores aritméticos y de bits arrojarán una excepción de TypeError cuando el operando sea un array, un recurso o un objeto no sobrecargado (ver el RFC).
Este es otro cambio que requiere un poco de trabajo extra de los contribuyentes del núcleo, como los muchos errores, advertencias y cambios de aviso.
De nuevo, debido a los varios problemas aún no resueltos, es muy recomendable realizar pruebas de compatibilidad en un entorno de staging o desarrollo antes de hacer el cambio a PHP 8 en tu sitio web en vivo. Lee más sobre WordPress y PHP 8.0.
Cambios Adicionales para los Desarrolladores
WordPress 5.6 introduce toneladas de cambios para los desarrolladores y no pudimos incluirlos todos en nuestra lista. Pero aquí están los tres primeros que creemos que vale la pena revisar:
1. wp_after_insert_post Action Hook
Antes de WordPress 5.6 podías usar save_posts o acciones similares para ejecutar código personalizado después de que un post fuera publicado. Ahora WordPress 5.6 introduce el nuevo gancho de acción wp_after_insert_post, que dispara solo una vez que los términos y metadatos hayan sido guardados.
Además, se han actualizado varias funciones para evitar que se disparen esos ganchos. El nuevo parámetro $fire_after_hooks ha sido agregado a las funciones wp_insert_posts(), wp_update_post() y wp_insert_attachment(). Si se establece como false, evita que los ganchos de after insert se disparen.
Mira la nota de desarrollo para una visión más profunda.
2. Tipografía
Las funciones de tipografía intval(), strval(), floatval() y boolval() han sido eliminadas del núcleo en favor de la tipografía directa:
intval()→(int)strval()→(string)floatval()→(float)
Este cambio tiene efectos directos en el rendimiento, ya que el encasillamiento directo es ~6 veces más rápido que las funciones de encasillamiento.
3. Objetos de WP_Error
La clase WP_Error ha sido mejorada para permitir la fusión de múltiples instancias de WP_Error en una sola. Anteriormente se podía hacer eso solo manualmente. Ahora, WordPress 5.6 introduce tres nuevos métodos para ayudar a manejar múltiples instancias de WP_Error. El siguiente código es un ejemplo de la nota de desarrollo:
<?php
$error_1 = new WP_Error(
'code1',
'This is my first error message.',
'Error_Data'
);
$error_2 = new WP_Error(
'code2',
'This is my second error message.',
'Error_Data2'
);
// Merge from another WP_Error.
$error_1->merge_from( $error_2 );
// Retrieve all error data, optionally for a specific error code.
$error_1->get_all_error_data( 'code2' );
// Export to another WP_Error
$error_1->export_to( $error_2 );Lecturas Adicionales para los Desarrolladores
Es imposible mencionar todos los cambios centrados en el desarrollo introducidos por WordPress 5.6, pero puedes leer más sobre ellos usando los siguientes enlaces:
- Actualizando la versión de jQuery enviada con WordPress
- Actualizando el núcleo jQuery a la versión 3 – parte 2
- WordPress y PHP 8.0
- REST API Batch Framework en WordPress 5.6
- Varios cambios enfocados en el desarrollador de WordPress 5.6
Resumen
WordPress 5.6 es un lanzamiento importante con toneladas de características y cambios tanto para los usuarios como para los desarrolladores. Siempre nos entusiasma ver cómo la evolución de las tecnologías web afecta directamente a la seguridad, el rendimiento, la usabilidad y la accesibilidad de WordPress.
Pero la evolución nunca se detiene y ya podemos echar un vistazo a las futuras fechas potenciales de lanzamiento.
Depende de ti ahora: ¿Qué es lo que más te gusta de WordPress 5.6? ¿Y qué características te gustaría que se añadieran a WordPress 5.7?
Deja una respuesta