Bloques de Gutenberg: registrar más de un bloque con `register_block_type_from_metadata()` arroja errores en la consola

5 minutos de lectura

avatar de usuario
Laloptk

Estoy practicando cómo crear el complemento de bloques de Gutenberg. yo suelo @wordpress/crear-bloque para crear un complemento de bloques.

Editar: No usé el andamio wp-cli como dije inicialmente, lo que quise escribir es que usé @wordpress/create-block.

El andamio está hecho para tener solo un bloque, por lo que, si desea más de un bloque, debe modificar la estructura, lo cual no es tan difícil, pero quiero que los bloques usen block.json para registrar bloques con register_block_type_from_metadata()lo cual logré, pero el problema es que si uso este código (register_block_type_from_metadata dos veces) en el archivo PHP del complemento principal:

function blocks_boilerplate_block_init() {
    register_block_type_from_metadata( __DIR__ . '/src/blocks/example');
    register_block_type_from_metadata( __DIR__ . '/src/blocks/example2');
}
add_action( 'init', 'blocks_boilerplate_block_init' );

Para registrar los bloques, los bloques se registran y funcionan sin problemas, pero la consola de Chrome muestra dos errores.

El bloque “create-block/boilerplate-example” ya está registrado.

El bloque “create-block/guten-block-example2” ya está registrado.

si uso register_block_type_from_metadata() sólo una vezel error desaparece.

¿Alguna idea sobre cómo hacer que los errores desaparezcan?

avatar de usuario
Laloptk

El problema era que cuando usas @wordpress/create-block para crear un complemento con un bloque en él, y luego usas npm start para ejecutar todo, webpack compila todos los bloques de código JavaScript en un solo archivo, lo cual está bien y en realidad es deseable, de esa manera no tiene que poner en cola un montón de archivos. El archivo block.json incluye una línea "editorScript": "file:../build/index.js" (o algo similar) para poner en cola el archivo JS compilado principal, y si solo tiene un bloque, esa línea está bien en el archivo block.json, pero cuando modifica la estructura del complemento para incluir más bloques y cada bloque tiene su propio archivo block.json, incluido el editorScript línea, luego los bloques se registran varias veces, uno por cada archivo block.json que tenga, así que, como solución temporal, eliminé el editorScript línea de todos block.json archivos excepto uno, y los errores desaparecieron, no me gustó esa solución porque rompe la consistencia, así que coloqué el siguiente código en el archivo php principal del complemento:

function qas_enqueue_blocks_scripts() {
    $asset_file = require plugin_dir_path( __FILE__ ) . 'build/index.asset.php';
    wp_enqueue_script( 'qas-main', plugins_url( '/build/index.js', __FILE__ ), $asset_file['dependencies'], 1.0, false);
}
add_action( 'enqueue_block_editor_assets', 'qas_enqueue_blocks_scripts');

El código anterior pone en cola el principal index.js file al editor de bloques y obtiene las dependencias del archivo de /build/index.asset.php que se genera automáticamente cuando ejecuta los comandos iniciales para crear el complemento y el bloque inicial. Usando ese código, no necesita usar el editorScript línea en cualquier lugar, para que pueda eliminarlo de todos los archivos block.json.

Otra forma de resolver esto es modificar la configuración del paquete web para compilar solo el código para el bloque específico en el archivo JS principal y luego seguir usando editorScript en cada block.jsonpero no lo he probado todavía.

Después de configurar su proyecto de bloque de Gutenberg con andamio wp-cli y agregando los dos nuevos bloques, la estructura de su proyecto puede ser algo como:

- myblockname
    > build
    > node_modules
    - src
        - blocks
             - example1
                  - index.js
                  - block.json
             > example2
        index.js
myblockname.php

Un enfoque para tener varios bloques cargados sin conflicto mientras se usa block.json es importar cada bloque a través de la principal src/index.jsque wp-cli creado por ejemplo:

src/index.js:

import './blocks/example1/';
import './blocks/example2/';

Cada uno de tus bloques, (Ejemplo 1 y ejemplo2) debe tener un index.js y block.json archivo para definir el bloque, por ejemplo:

src/blocks/ejemplo1/index.js:

import { registerBlockType } from '@wordpress/blocks';
import metadata from './block.json';
const { title } = metadata;

registerBlockType(name, {
    title, // required
    edit(){...}
    save(){...}
});

Ahora, cuando crea su proyecto, cada uno de los bloques de ejemplo se compila en un único build/index.js y activos relacionados.

Si luego usa el archivo PHP principal original creado a partir de wp-cli scaffold (por ejemplo, myblockname.php), cargará el único construido esperado index.js, index.asset.php, index.css, etc. y le permite agrupar muchos bloques en uno.

He usado este enfoque para algunos proyectos anteriores de Gutenberg que comenzaron desde wp-cli para agrupar múltiples bloques rápidamente. También miré cómo WordPress Gutenberg carga la biblioteca de bloques y encontró la actualizada recientemente Documentación de la API de bloques de WordPress útil para trabajar este enfoque.

Nota:
Existe una desventaja potencial en este método de agrupar todos sus bloques en un archivo javascript: todos se cargan incluso si no se usan. En mi proyecto, mis bloques eran dependencias entre sí (innerBlocks), por lo que fue beneficioso. El tamaño del archivo y el tiempo de carga pueden ser una preocupación según la cantidad de bloques que empaque.

Para muchos bloques, un mejor enfoque sería que cada bloque creara su propio archivo de activos y luego agrupara esos activos a través de “editorScript” y “script” en block.json pero aún uso el principal index.js como punto de entrada.

Si aún ve el error de que el nombre ya está registrado, verifique que cada bloque de “ejemplo” tenga un único “nombre” en block.json

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad