WordPress 5.6: Guía para desarrolladores

8 dic. 2020
·
  • What is code
  • WordPress
·

Al igual que WordPress 5.5 resultó ser una versión muy completa, aparentemente no podemos decir lo mismo de la 5.6. La nueva pantalla de widgets programada para esta versión se vino abajo allá por octubre debido a la dificultad de integrar el Personalizador con el Editor. Queda trabajo por hacer así que esperamos que esté lista para la 5.7.

Pero no nos engañemos, aunque los esfuerzos se centren en Gutenberg (a veces demasiado), WordPress sigue avanzando a buen ritmo.

No me escondo, la mayoría de las cosas que ves aquí las saco del post Field Guide en Core.

Actualización a jQuery 3

La librería jQuery se actualiza a la 3.5.1, junto con jQuery Migrate. Si tiennes temas o plugins en el repositorio de .org se recomienda activar la constante SCRIPT_DEBUG y hacer pruebas con la nueva versión con la consola de JS bien abierta. Si quieres más detalles, como una guía de migración, aquí tienes más.

Salud Del Sitio

A nivel visual no hay nada pero hay algunos cambios a nivel de validación asícrona de datos que resuelve un problema que paraba la ejecución de JavaScript. Esta pantalla también empieza a moverse (como todo el wp-admin, esperemos) de usar llamadas a wp-admin/admin-ajax.php a utilizar peticiones a la REST API (a través de la ruta /wp-json/wp-site-health/v1). Todo mucho más estandarizado y elegante.

Contraseñas de Aplicaciones (Application Passwords)

Cambio que llega sin hacer ruido pero puede que importantísimo para grandes sitios o One Page Applications. Hasta ahora, la autenticación de usuarios a través de la REST API era nula, no hay nada en core que permita la autenticación sin cookies y desde un sitio externo (por ejemplo, una aplicación móvil) pero eso se ha acabado.

El origen de todo esto está en este plugin que ha sido aprobado para su adopción en Core. Los usuarios de un sitio podrán ahora generar contraseñas para autenticarse a través de la REST API. En este caso, una contraseña es una cadena de 24 caracteres exclusivamente formado por números y letras (sin caracteres raritos). El proceso para autenticarse sigue varios pasos que son difíciles de resumir (lo dejaré para otra entrada) pero el proceso completo está en este post de Core.

Actualizaciones automáticas para versiones mayores

Ahí abajo hay un checkbox

La versión 5.6 introduce un nuevo interfaz para activar o desactivar las actualizaciones automáticas para versiones mayores (5.6, 5.7, 5.8…). Por defecto, esta casilla está desactivada pero ahora podemos activarla manualmente en lugar de usar la constante WP_AUTO_UPDATE_CORE o el filtro allow_major_auto_core_updates.

Esta versión también añade una nueva acción para añadir más campos en esa sección. En el post de Make Core ponen un ejemplo para hacer aparecer otro checkbox para habilitar o deshabilitar las actualizaciones menores:

function my_plugin_after_core_auto_updates_settings_fields( $auto_update_settings ) {
    if ( isset( $_POST['core-auto-updates-settings'] ) && wp_verify_nonce( $_POST['set_core_auto_updates_settings'], 'core-auto-updates-nonce' ) ) {
        if ( isset( $_POST['my-plugin-core-auto-updates-minor'] ) && 1 === (int) $_POST['my-plugin-core-auto-updates-minor'] ) {
            update_site_option( 'my_plugin_auto_update_core_minor', 1 );
        } else {
            update_site_option( 'my_plugin_auto_update_core_minor', 0 );
        }
    }
    $minor_auto_updates_settings = get_site_option( 'my_plugin_auto_update_core_minor' );
    ?>
    <p>
        <input type="checkbox" name="my-plugin-core-auto-updates-minor" id="my-plugin-core-auto-updates-minor" value="1" <?php checked( $minor_auto_updates_settings, 1 ); ?> />
        <label for="my-plugin-core-auto-updates-minor">
            <?php _e( 'Automatically keep this site up-to-date with minor updates.', 'my-plugin' ); ?>
        </label>
    </p>
    <?php
}
add_action( 'after_core_auto_updates_settings_fields', 'my_plugin_after_core_auto_updates_settings_fields', 10, 1 );

PHP 8

WordPress 5.6 trae soporte para PHP 8 pero tendrás que verificar si los temas y plugins que usas también lo soportan.

Nueva acción: wp_after_insert_post

La 5.6 incluye más filtros y acciones pero este es el más interesante. Hasta ahora se usaba la acción save_post para ejecutar algo cuando un post se insertaba en Base de Datos pero esto acarreaba algunos problemas como que las taxonomías o incluso los metadatos no estaban asignados cuando dicho hook se ejecutaba. Desde la 5.6 se introduce el nuevo hook, wp_after_insert_post para este propósito.

Cambios en WP_Error

Los cambios en esta clase incluyen la posibilidad de unir dos instancias distintas de esta clase y recuperar y exportar los distintos errores de una misma instancia.

$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 );

Nuevo parámetro en wp_send_json*

Las funciones wp_send_json, wp_send_json_error y wp_send_json_success aceptan ahora un parámetro de opciones, $options, para pasar flags a la función json_encode.

Gutenberg

La versión 9.2 es la que ha terminado entrando en WordPress 5.6. Hay montones de mejoras a nivel de interfaz o visuales y aunque no voy a entrar en los detalles de las mismas sí quería hacer una lista al menos:

Hay muchísimo más pero creo que quizás esas son las que más destacan a los ojos del usuario más común. En temas de desarrollo, hay más…

Versión 2 de al API de bloques

La nueva API para registrar bloques en Gutenberg ya está disponible. El cambio viene dado por la necesidad de conseguir a largo plazo que el HTML del editor y del frontend coincidan. Esto quiere decir que dar estilo a los bloques será cada vez más fácil. Aquí tenemos un ejemplo completo:

const { useBlockProps } = wp.blockEditor;

registerBlockType( name, {
	attributes: {
		content: {
			type: 'string',
			default: '',
		}
	},
	apiVersion: 2,
	edit: ( props ) => {
		const { attributes } = props;

		const wrapperProps = useBlockProps( {
			className: 'mi-clase-edit',
			style: { color: 'blue' },
		} );
		return <div { ...wrapperProps }>{ attributes.content }</div>;
	},
	save: () => {
		const wrapperProps = useBlockProps.save( {
			className: 'mi-clase-save',
			style: { color: 'blue' },
		} );
		return <div { ...wrapperProps }>{ attributes.content }</div>;
	}
} );

Las dos grandes diferencias son:

  • Registrar el bloque con el campo apiVersion: 2
  • El uso del hookuseBlockProps (recordemos que los hooks en React no tienen nada que ver con las acciones o filtros en WordPress) en las funciones edit y save del bloque. Este hook es necesario usarlo en el nodo principal del bloque, el nodo que envuelve al resto del HTML. El hook añadirá además una serie de atributos especiales necesarios para habilitar el nuevo comportamiento del bloque.

    Nótese que mientras en edit, el hook es useBlockProps, en el método save, el hook es useBlockProps.save.

Aquí tienes algunas recomendaciones más como el uso de ambas versiones.

createBlocksFromInnerBlocksTemplate

Una nueva función en la API de bloques para transformar una lista de InnerBlocks en bloques. Aunque puede llegar a ser útil, encuentro algo confuso la forma de explicarlo en el post de Core. Si no me equivoco, el origen de la función viene de la necesidad de convertir varios bloques seleccionados en columnas. Aquí uso el mismo ejemplo que en el post anterior:

import { InnerBlocks } from '@wordpress/block-editor';
import { useDispatch } from '@wordpress/data';
import { __ } from '@wordpress/i18n';
import { Button, ToolbarGroup, ToolbarButton } from '@wordpress/components';
import { BlockControls, useBlockProps } from '@wordpress/block-editor';
import { createBlocksFromInnerBlocksTemplate } from '@wordpress/blocks';
 
function MyEditBlock( { clientId } ) {
    const { replaceInnerBlocks } = useDispatch( 'core/block-editor' );
    const variation = {
        name: 'my-variation',
        title: __( 'My variation' ),
        innerBlocks: [
            [ 'core/paragraph', { content: 'Hello' } ],
            [ 'core/paragraph', { placeholder: __( 'Write title…' ) } ],
        ],
    };
    const onClick = () => {
        replaceInnerBlocks(
            clientId,
            createBlocksFromInnerBlocksTemplate( variation.innerBlocks )
        );
    };
    return (
        <div { ...useBlockProps() }>
            <BlockControls>
                <ToolbarGroup>
                    <ToolbarButton onClick={ onClick }>
                        <span>Change InnerBlocks</span>
                    </ToolbarButton>
                </ToolbarGroup>
            </BlockControls>
            <InnerBlocks />
        </div>
    );
}

Al hacer click sobre el botón, InnerBlocks se transformará en una variación distinta compuesta por dos párrafos. Es algo que me gustaría probar más para ver su potencial porque de momento no lo tengo tan claro y no he tenido la oportunidad de echarle un ojo.

Nuevas características de estilo en los bloques

A partir de la 5.6, Gutenberg facilita mucho el añadir controles de colores o tamaño de fuente en nuestros bloques. Hasta ahora teníamos que crear las opciones manualmente (y en el caso del tamaño de fuente podía no ser nada fácil) pero ahora, al registrar el bloque, tenemos la posibilidad de definir algunos controles dentro del atributo supports:

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.
}

Si quieres más información sobre el uso de las clases CSS y de cómo gestionar los nuevos atributos de estilo, puedes leer el post en Core.