Estoy practicando cómo crear el complemento de bloques de Gutenberg. Uso @wordpress/create-block 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 tanto, 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() solo una vez , el error desaparece.
¿Alguna idea sobre cómo hacer que los errores desaparezcan?
El problema fue que, cuando usa @wordpress/create-block para crear un complemento con un bloque, y luego usa npm start para ejecutar todo, el paquete web compila todos los bloques de código JavaScript en un solo archivo, lo cual está bien y en realidad se desea, 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, incluida la línea editorScript , los bloques se registran varias veces, uno para cada archivo block.json tiene, entonces, como una solución temporal, eliminé la línea editorScript de todos los archivos block.json 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 archivo index.js principal en el 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. Con ese código, no necesita usar la línea editorScript ninguna parte, por lo que puede 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.json , pero aún no lo he probado.
Después de configurar su proyecto de bloque de Gutenberg con andamio wp-cli y agregar 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 cargar múltiples bloques sin conflicto mientras se usa block.json es importar cada bloque a través de src/index.js principal, que wp-cli creó, por ejemplo:
src/index.js:
import './blocks/example1/'; import './blocks/example2/'; Cada uno de sus bloques ( ejemplo1 y ejemplo2 ) debe tener un archivo index.js y block.json 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 el build/index.js único y los activos relacionados.
Si luego usa el archivo PHP principal original creado a partir del andamio wp-cli (p. ej., myblockname.php), cargará el esperado index.js, index.asset.php, index.css, etc., y le permitirá agrupar muchos bloques en uno.
He usado este enfoque para algunos proyectos anteriores de Gutenberg que comenzaron desde wp-cli para agrupar varios bloques rápidamente. También observé cómo WordPress Gutenberg carga la biblioteca de bloques y descubrí que la documentación de la API de bloques de WordPress recientemente actualizada es útil para resolver 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 construya su propio archivo de activos y luego agrupe esos activos a través de "editorScript" y "script" en block.json pero aún use el index.js principal 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 "nombre" único en block.json