Reconozcamos que desarrollar para WordPress es raro en este momento. Ya sea que sea nuevo en WordPress o haya trabajado con él durante eones, la introducción de las funciones de "Edición de sitio completo" (FSE), incluida la Editor de bloques (WordPress 5.0) y el Editor del sitio (WordPress 5.9), han revolucionado la forma tradicional en que construimos temas y complementos de WordPress.
Aunque han pasado cinco años desde que conocimos el Editor de bloques por primera vez, desarrollarlo es difícil porque falta documentación o está desactualizada. Eso es más una declaración sobre qué tan rápido se mueven las características de FSE, algo Geoff se lamentó en una publicación reciente.
Caso en cuestión: en 2018, un serie introductoria sobre entrar en el desarrollo de Gutenberg se publicó aquí mismo en CSS-tricks. Los tiempos han cambiado desde entonces y, aunque ese estilo de desarrollo todavía funciona, es no se recomienda más (además, el create-guten-block el proyecto en el que se basa tampoco se mantiene).
En este artículo, tengo la intención de ayudarlo a comenzar con el desarrollo de bloques de WordPress de una manera que siga la metodología actual. Entonces, sí, las cosas podrían cambiar muy bien después de que esto se publique. Pero voy a tratar de centrarme en él de una manera que, con suerte, capture la esencia del desarrollo de bloques, porque aunque las herramientas pueden evolucionar con el tiempo, es probable que las ideas centrales sigan siendo las mismas.
El Editor de Gutenberg: (1) El insertador de bloques, (2) el área de contenido y (3) la barra lateral de configuración Créditos: Manual del editor de bloques de WordPress
¿Qué son exactamente los bloques de WordPress?
Comencemos ventilando cierta confusión con lo que queremos decir con términos como bloques. Todo el desarrollo que se dedicó a estas características que condujeron a WordPress 5.0 se denominó en código "Gutenberg"- ya sabes, el inventor de la imprenta.
Desde entonces, "Gutenberg" se ha utilizado para describir todo lo relacionado con los bloques, incluido el Editor de bloques y el Editor de sitios, por lo que se ha complicado hasta el punto de que algunas personas despreciar el nombre. Para colmo, hay un Complemento de Gutenberg donde se prueban las características experimentales para su posible inclusión. Y si cree que llamar a todo esto "Edición de sitio completo" resolvería el problema, también hay preocupaciones con eso.
Entonces, cuando nos referimos a "bloques" en este artículo, nos referimos a componentes para crear contenido en el Editor de bloques de WordPress. Los bloques se insertan en una página o publicación y proporcionan la estructura para un tipo particular de contenido. WordPress viene con un puñado de bloques "básicos" para tipos de contenido comunes, como Párrafo, Lista, Imagen, Video y Audio. para nombrar unos pocos.
Además de estos bloques principales, también podemos crear bloques personalizados. De eso se trata el desarrollo de bloques de WordPress (también hay filtros de bloques centrales para modificar su funcionalidad, pero es probable que todavía no los necesite).
que hacen los bloques
Antes de sumergirnos en la creación de bloques, primero debemos tener una idea de cómo funcionan internamente los bloques. Eso definitivamente nos ahorrará una tonelada de frustración más adelante.
La forma en que me gusta pensar en un bloque es bastante abstracta: para mí, un bloque es una entidad, con algunas propiedades (llamadas atributos), que representa algún contenido. Sé que esto suena bastante vago, pero quédate conmigo. Básicamente, un bloque se manifiesta de dos maneras: como una interfaz gráfica en el editor de bloques o como un fragmento de datos en la base de datos.
Cuando abre el Editor de bloques de WordPress e inserta un bloque, digamos un bloque Pullquote, obtiene una interfaz agradable. Puede hacer clic en esa interfaz y editar el texto citado. El panel Configuración en el lado derecho de la interfaz de usuario del Editor de bloques proporciona opciones para ajustar el texto y configurar la apariencia del bloque.
Cuando haya terminado de crear su elegante cita y presione Publicar, la publicación completa se almacena en la base de datos en el wp_posts mesa. Esto no es nada nuevo debido a Gutenberg. Así es como siempre han funcionado las cosas: WordPress almacena el contenido de las publicaciones en una tabla designada en la base de datos. Pero lo nuevo es que una representación del bloque Pullquote es parte del contenido que se almacena en post_content del objeto wp_posts mesa.
¿Cómo es esta representación? Echar un vistazo:
It is not an exaggeration to say that peas can be described as nothing less than perfect spheres of joy.
The Encyclopedia of world peas
Parece HTML simple, ¿verdad? Esto, en la jerga técnica, es el bloque "serializado". Observe los datos JSON en el comentario HTML, "textAlign": "right". eso es un atributo - una propiedad asociada con el bloque.
Supongamos que cierra el Editor de bloques y luego, algún tiempo después, lo abre de nuevo. El contenido de lo relevante post_content el campo es recuperado por el editor de bloques. Luego, el editor analiza el contenido recuperado, y dondequiera que encuentre esto:
...
…se dice en voz alta:
OK, eso me parece un bloque de Pullquote. Hmm... también tiene un atributo... Tengo un archivo JavaScript que me dice cómo construir la interfaz gráfica para un bloque Pullquote en el editor a partir de sus atributos. Debería hacer eso ahora para representar este bloque en todo su esplendor.
Como desarrollador de bloques, su trabajo es:
Dígale a WordPress que desea registrar un tipo específico de bloque, con detalles específicos.
Proporcione el archivo JavaScript al Editor de bloques que lo ayudará a representar el bloque en el editor mientras lo "serializa" para guardarlo en la base de datos.
Proporcione cualquier recurso adicional que el bloque necesite para su correcta funcionalidad, por ejemplo, estilos y fuentes.
Una cosa a tener en cuenta es que toda esta conversión de datos serializados a interfaz gráfica, y viceversa, se lleva a cabo solo en el Editor de bloques. En la parte frontal, el contenido se muestra exactamente de la forma en que se almacena. Por lo tanto, en cierto sentido, los bloques son una forma elegante de colocar datos en la base de datos.
Con suerte, esto le dará cierta claridad sobre cómo funciona un bloque.
Primeros pasos con el desarrollo de bloques de WordPress
Los bloques son solo complementos
Los bloques son solo complementos. Bueno, técnicamente, tú podemos pon bloques en temas y tu podemos poner varios bloques en un complemento. Pero, la mayoría de las veces, si quieres hacer un bloque, vas a hacer un complemento. Entonces, si alguna vez ha creado un complemento de WordPress, entonces ya está a medio camino de tener un control sobre cómo hacer un bloque de WordPress.
Pero supongamos por un momento que nunca ha configurado un complemento de WordPress, y mucho menos un bloque. ¿Por dónde empiezas?
Configuración de un bloque
Hemos cubierto lo que son los bloques. Comencemos a configurar las cosas para hacer uno.
Asegúrate de tener Node instalado
Esto le dará acceso a npm y npx comandos, donde npm instala las dependencias de su bloque y ayuda a compilar cosas, mientras que npx ejecuta comandos en paquetes sin instalarlos. Si está en macOS, probablemente ya tenga Node y pueda usar nvm para actualizar versiones. Si está en Windows, deberá descargar e instalar nodo.
Crear una carpeta de proyecto
Ahora, puede encontrarse con otros tutoriales que saltan directamente a la línea de comando y le indican que instale un paquete llamado @wordpress/create-block. Este paquete es excelente porque escupe una carpeta de proyecto completamente formada con todas las dependencias y herramientas que necesita para comenzar a desarrollar.
Personalmente, sigo esta ruta cuando configuro mis propios bloques, pero sigo la corriente por un momento porque quiero eliminar las cosas obstinadas que presenta y concentrarme solo en las partes necesarias para comprender el entorno de desarrollo de referencia.
Estos son los archivos que me gustaría mencionar específicamente:
readme.txt: Esto es algo así como la cara frontal del directorio de complementos, que generalmente se usa para describir el complemento y proporcionar detalles adicionales sobre el uso y la instalación. Si envía su bloque a la WordPress Plugin Directorio, este archivo ayuda a completar la página del complemento. Si planea crear un repositorio de GitHub para su complemento de bloque, entonces también podría considerar un README.md archivo con la misma información para que se muestre bien allí.
package.json: Esto define los paquetes de Nodo que se requieren para el desarrollo. Lo abriremos cuando lleguemos a la instalación. En el desarrollo clásico de complementos de WordPress, es posible que esté acostumbrado a trabajar con Composer y un composer.json archivo en su lugar. Este es el equivalente de eso.
plugin.php: Este es el archivo del complemento principal y, sí, ¡es PHP clásico! Pondremos el encabezado y los metadatos de nuestro complemento aquí y los usaremos para registrar el complemento.
Además de estos archivos, también está el src directorio, que se supone que contiene el código fuente de nuestro bloque.
Tener estos archivos y el src El directorio es todo lo que necesita para comenzar. Fuera de ese grupo, observe que técnicamente solo necesitamos un archivo (plugin.php) para hacer el complemento. El resto proporciona información o se utiliza para gestionar el entorno de desarrollo.
Lo anterior @wordpress/create-block El paquete crea andamios para estos archivos (y más). Puede pensar en ello como una herramienta de automatización en lugar de una necesidad. De todos modos, facilita el trabajo, por lo que puede tomarse la libertad de montar un bloque con él ejecutando:
npx @wordpress/create-block
Instalar dependencias de bloque
Suponiendo que tiene listos los tres archivos mencionados en la sección anterior, es hora de instalar las dependencias. Primero, necesitamos especificar las dependencias que necesitaremos. Lo hacemos editando el package.json. Mientras usa el @wordpress/create-block utilidad, se genera lo siguiente para nosotros (comentarios agregados; JSON no admite comentarios, así que elimine los comentarios si está copiando el código):
{
// Defines the name of the project
"name": "block-example",
// Sets the project version number using semantic versioning
"version": "0.1.0",
// A brief description of the project
"description": "Example block scaffolded with Create Block tool.",
// You could replace this with yourself
"author": "The WordPress Contributors",
// Standard licensing information
"license": "GPL-2.0-or-later",
// Defines the main JavaScript file
"main": "build/index.js",
// Everything we need for building and compiling the plugin during development
"scripts": {
"build": "wp-scripts build",
"format": "wp-scripts format",
"lint:css": "wp-scripts lint-style",
"lint:js": "wp-scripts lint-js",
"packages-update": "wp-scripts packages-update",
"plugin-zip": "wp-scripts plugin-zip",
"start": "wp-scripts start"
},
// Defines which version of the scripts packages are used (24.1.0 at time of writing)
// https://developer.wordpress.org/block-editor/reference-guides/packages/packages-scripts/
"devDependencies": {
"@wordpress/scripts": "^24.1.0"
}
}
La @wordpress/scripts El paquete es la dependencia principal aquí. Como puedes ver, es un devDependency lo que significa que ayuda en el desarrollo. ¿Cómo es eso? Expone el wp-scripts binario que podemos usar para compilar nuestro código, desde el src directorio a la build directorio, entre otras cosas.
Hay una serie de otros paquetes que WordPress mantiene para varios propósitos. por ejemplo, el @wordpress/components el paquete proporciona varios prefabricados UI componentes para el editor de bloques de WordPress que se puede usar para crear experiencias de usuario consistentes para su bloque que se alinea con los estándares de diseño de WordPress.
En realidad no necesite para instalar estos paquetes, incluso si desea utilizarlos. Esto se debe a que estos @wordpress las dependencias no se incluyen con su código de bloque. En cambio, cualquier import declaraciones que hacen referencia al código de los paquetes de utilidades, como @wordpress/components — se utilizan para construir un archivo de "activos", durante la compilación. Además, estas declaraciones de importación se convierten en declaraciones que asignan las importaciones a las propiedades de un objeto global. Por ejemplo, import { __ } from "@wordpress/i18n" se convierte en una versión reducida de const __ = window.wp.i18n.__ (window.wp.i18n siendo un objeto que se garantiza que estará disponible en el ámbito global, una vez que el correspondiente i18n el archivo del paquete está en cola).
Durante el registro del bloque en el archivo del complemento, el archivo de "activos" se usa implícitamente para decirle a WordPress las dependencias del paquete para el bloque. Estas dependencias se ponen en cola automáticamente. Todo esto se soluciona tras bambalinas, dado que está utilizando el scripts paquete. Dicho esto, aún puede elegir instalar dependencias localmente para completar el código e información de parámetros en su package.json archivo:
Ahora que package.json está configurado, deberíamos poder instalar todas esas dependencias navegando a la carpeta del proyecto en la línea de comando y ejecutando npm install.
Primeros pasos con el desarrollo de bloques de WordPress
Agregar el encabezado del complemento
Si viene del desarrollo clásico de complementos de WordPress, probablemente sepa que todos los complementos tienen un bloque de información en el archivo principal del complemento que ayuda a WordPress a reconocer el complemento y mostrar información sobre él en la pantalla Complementos del administrador de WordPress.
Esto es lo que @wordpress/create-block generado para mí en un complemento llamado creativamente "Hello World":
<?php
/**
* Plugin Name: Block Example
* Description: Example block scaffolded with Create Block tool.
* Requires at least: 5.9
* Requires PHP: 7.0
* Version: 0.1.0
* Author: The WordPress Contributors
* License: GPL-2.0-or-later
* License URI: https://www.gnu.org/licenses/gpl-2.0.html
* Text Domain: css-tricks
*
* @package create-block
*/
Eso está en el archivo principal del complemento, al que puede llamar como quiera. Podrías llamarlo algo genérico como index.php or plugin.php. create-block El paquete lo llama automáticamente lo que proporcione como nombre del proyecto al instalarlo. Como llamé a este ejemplo "Ejemplo de bloque", el paquete nos dio una block-example.php archivo con todas estas cosas.
Vas a querer cambiar algunos de los detalles, como convertirte en el autor y todo eso. Y no todo eso es necesario. Si estuviera rodando esto desde "cero", entonces podría verse algo más parecido a esto:
<?php
/**
* Plugin Name: Block Example
* Plugin URI: https://css-tricks.com
* Description: An example plugin for learning WordPress block development.
* Version: 1.0.0
* Author: Arjun Singh
* License: GPL-2.0-or-later
* License URI: https://www.gnu.org/licenses/gpl-2.0.html
* Text Domain: css-tricks
*/
Ya hemos visto los archivos necesarios para nuestro bloque. Pero si estás usando @wordpress/create-block, verá un montón de otros archivos en la carpeta del proyecto.
¡Uf, eso es mucho! Vamos a llamar a las cosas nuevas:
build/: esta carpeta recibió los activos compilados al procesar los archivos para su uso en producción.
node_modules: Esto contiene todas las dependencias de desarrollo que instalamos cuando ejecutamos npm install.
src/: Esta carpeta contiene el código fuente del complemento que se compila y se envía al build directorio. Veremos cada uno de los archivos aquí en un momento.
.editorconfig: Contiene configuraciones para adaptar su editor de código para la consistencia del código.
.gitignore: este es un archivo de repositorio estándar que identifica los archivos locales que deben excluirse del seguimiento del control de versiones. Su node_modules definitivamente debería incluirse aquí.
package-lock.json: Este es un archivo generado automáticamente que contiene para rastrear las actualizaciones de los paquetes requeridos que instalamos con npm install.
Bloquear metadatos
quiero profundizar en el src directorio con usted, pero se centrará primero en un solo archivo: block.json. Si has usado create-block , ya está ahí para ti; si no, adelante y créalo. WordPress se está esforzando mucho para hacer de esta la forma estándar y canónica de registrar un bloque al proporcionar metadatos que brindan contexto de WordPress para reconocer el bloque y representarlo en el Editor de bloques.
Esto es lo que @wordpress/create-block generado para mí:
De hecho, hay un montón de información diferente podemos incluir aquí, pero todo lo que realmente se requiere es name y title. Una versión súper mínima podría verse así:
$schema define el formato del esquema utilizado para validar el contenido del archivo. Suena como algo obligatorio, pero es totalmente opcional, ya que permite que los editores de código de soporte validen la sintaxis y proporcionen otras prestaciones adicionales, como sugerencias de información sobre herramientas y finalización automática.
apiVersion se refiere a qué versión del API de bloque utiliza el complemento. Hoy, la versión 2 es la última.
name es una cadena única requerida que ayuda a identificar el complemento. Tenga en cuenta que he prefijado esto con css-tricks/ que estoy usando como espacio de nombres para ayudar a evitar conflictos con otros complementos que puedan tener el mismo nombre. Puede optar por usar algo como sus iniciales en su lugar (p. ej. as/block-example).
version es algo WordPress sugiere usar como un mecanismo de prevención de caché cuando se lanzan nuevas versiones.
title es el otro campo obligatorio y establece el nombre que se usa donde se muestra el complemento.
category agrupa el bloque con otros bloques y los muestra juntos en el Editor de bloques. Las categorías existentes actuales incluyen text, media, design, widgets, themey embed, e incluso puedes crear categorías personalizadas.
icon te permite elegir algo de la biblioteca de dashicons para representar visualmente su bloque en el Editor de bloques. estoy usando el format-quote icon](https://developer.wordpress.org/resource/dashicons/#format-quote) ya que estamos haciendo nuestro propio tipo de cita extraída en este ejemplo. Es bueno que podamos aprovechar los íconos existentes en lugar de tener que crear los nuestros, aunque eso es ciertamente posible.
editorScript es donde se encuentra el archivo JavaScript principal, index.js, vive.
Registrar el bloque
Una última cosa antes de llegar al código real, y eso es registrar el complemento. Acabamos de configurar todos esos metadatos y necesitamos una forma de que WordPress los consuma. De esa forma, WordPress sabe dónde encontrar todos los activos del complemento para que puedan ponerse en cola para su uso en el Editor de bloques.
Registrar el bloque es un proceso doble. Necesitamos registrarlo tanto en PHP como en JavaScript. Para el lado de PHP, abra el archivo del complemento principal (block-example.php en este caso) y agregue lo siguiente justo después del encabezado del complemento:
Esto es lo que create-block utilidad generada para mí, por eso la función se llama así. Podemos usar un nombre diferente. La clave, nuevamente, es evitar conflictos con otros complementos, por lo que es una buena idea usar su espacio de nombres aquí para que sea lo más único posible:
¿Por qué estamos señalando a la build directorio si el block.json con todos los metadatos del bloque en src? Eso es porque nuestro código todavía necesita ser compilado. los scripts paquete procesa el código de los archivos en el src directorio y coloca los archivos compilados utilizados en producción en el build directorio, mientras que también copiando elblock.jsonpresentar después de la cura.
Muy bien, pasemos al lado de JavaScript para registrar el bloque. Abrir src/index.js y asegúrate de que se vea así:
import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";
import Edit from "./edit.js";
import Save from "./save.js";
const { name } = metadata;
registerBlockType(name, {
edit: Edit,
save: Save,
});
¡Estamos entrando en la tierra de React y JSX! Esto le dice a WordPress que:
Importar el registerBlockType módulo de la @wordpress/blocks paquete.
Importar metadatos de block.json.
Importar el Edit y Save componentes de sus archivos correspondientes. Estaremos poniendo código en esos archivos más tarde.
Registre el bloque y use el Edit y Save componentes para renderizar el bloque y guardar su contenido en la base de datos.
¿Qué pasa con el edit y save funciones? Uno de los matices del desarrollo de bloques de WordPress es diferenciar el "back-end" del "front-end" y estas funciones se utilizan para representar el contenido del bloque en esos contextos, donde edit maneja la renderización de back-end y save escribe el contenido del Editor de bloques en la base de datos para representar el contenido en la parte frontal del sitio.
Una prueba rápida
Podemos hacer un trabajo rápido para ver nuestro bloque funcionando en el Editor de bloques y renderizado en la interfaz. Vamos a abrir index.js de nuevo y usa el edit y save funciones para devolver contenido básico que ilustre cómo funcionan:
import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";
const { name } = metadata;
registerBlockType(name, {
edit: () => {
return (
"Hello from the Block Editor"
);
},
save: () => {
return (
"Hello from the front end"
);
}
});
Esta es básicamente una versión simplificada del mismo código que teníamos antes, solo que apuntamos directamente a los metadatos en block.json para buscar el nombre del bloque, y omitió el Edit y Save componentes ya que estamos ejecutando las funciones directamente desde aquí.
Podemos compilar esto ejecutando npm run build en la línea de comando. Después de eso, tenemos acceso a un bloque llamado "Ejemplo de bloque" en el Editor de bloques:
Si soltamos el bloque en el área de contenido, obtenemos el mensaje que devolvemos del edit función:
Primeros pasos con el desarrollo de bloques de WordPress
Si guardamos y publicamos la publicación, deberíamos recibir el mensaje que devolvemos del save función cuando se ve en la parte delantera:
Primeros pasos con el desarrollo de bloques de WordPress
Creando un bloque
¡Parece que todo está conectado! Podemos volver a lo que teníamos en index.js antes de la prueba ahora que hemos confirmado que todo funciona:
import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";
import Edit from "./edit.js";
import Save from "./save.js";
const { name } = metadata;
registerBlockType(name, {
edit: Edit,
save: Save,
});
Observe que el edit y save funciones están vinculadas a dos archivos existentes en el src directorio que @wordpress/create-block generado por nosotros e incluye todas las importaciones adicionales que necesitamos en cada archivo. Sin embargo, lo que es más importante, esos archivos establecen el Edit y Save componentes que contienen el marcado del bloque.
marcado de back-end (src/edit.js)
import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";
export default function Edit() {
return (
{__("Hello from the Block Editor", "block-example")}
);
}
Ves lo que hicimos allí? Estamos importando accesorios de la @wordpress/block-editor paquete que nos permite generar clases que podemos usar más tarde para diseñar. También estamos importando el __ función de internacionalización, para hacer frente a las traducciones.
Primeros pasos con el desarrollo de bloques de WordPress
Marcado de front-end (src/save.js)
Esto crea un Save componente y vamos a usar más o menos lo mismo que src/edit.js con un texto ligeramente diferente:
import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";
export default function Save() {
return (
{__("Hello from the front end", "block-example")}
);
}
Nuevamente, obtenemos una buena clase que podemos usar en nuestro CSS:
Primeros pasos con el desarrollo de bloques de WordPress
Bloques de estilo
Acabamos de cubrir cómo usar accesorios de bloque para crear clases. Estás leyendo este artículo en un sitio sobre CSS, así que siento que me perdería algo si no abordáramos específicamente cómo escribir estilos de bloque.
Diferenciar los estilos de front-end y back-end
Si echa un vistazo a la block.json existentes src directorio encontrará dos campos relacionados con los estilos:
editorStyle proporciona la ruta a los estilos aplicados al back-end.
style es la ruta de los estilos compartidos que se aplican tanto al front-end como al back-end.
Recuerde que el @wordpress/scripts el paquete copia el block.json archivo cuando procesa el código en el /src directorio y coloca los activos compilados en el /build directorio. Es el build/block.json archivo que se utiliza para registrar el bloque. Eso significa que cualquier ruta que proporcionemos en src/block.json debe escribirse en relación con build/block.json.
Usando Sass
Podríamos colocar un par de archivos CSS en el build directorio, haga referencia a las rutas en src/block.json, ejecute la compilación y llámelo por día. Pero eso no aprovecha todo el poder del @wordpress/scripts proceso de compilación, que es capaz de compilar Sass en CSS. En su lugar, colocamos nuestros archivos de estilo en el src e importarlos en JavaScript.
Al hacer eso, debemos ser conscientes de cómo @wordpress/scripts estilos de procesos:
Un archivo llamado style.css or style.scss or style.sass, importado en el código JavaScript, se compila para style-index.css.
Todos los demás archivos de estilo se compilan y empaquetan en index.css.
La @wordpress/scripts usos del paquete paquete web para agrupar y @wordpress/scripts utiliza el Complemento PostCSS para trabajar con estilos de procesamiento. PostCSS se puede ampliar con complementos adicionales. los scripts El paquete usa los de Sass, SCSS y Autoprefixer, todos los cuales están disponibles para usar sin instalar paquetes adicionales.
De hecho, cuando giras tu bloque inicial con @wordpress/create-block, obtiene una buena ventaja con los archivos SCSS que puede usar para comenzar a ejecutar:
editor.scss contiene todos los estilos que se aplican al editor de back-end.
style.scss contiene todos los estilos compartidos por la parte delantera y trasera.
Ahora veamos este enfoque en acción escribiendo un poco de Sass que compilaremos en el CSS para nuestro bloque. Aunque los ejemplos no van a ser muy atrevidos, todavía los estoy escribiendo en los archivos SCSS para demostrar el proceso de compilación.
Rueda delantera y estilos de fondo
Bien, comencemos con los estilos que se aplican tanto en la parte delantera como en la trasera. Primero, necesitamos crear src/style.scss (ya está allí si está usando @wordpress/create-block) y nos aseguramos de importarlo, lo cual podemos hacer en index.js:
import "./style.scss";
Abrir src/style.scss y suelte algunos estilos básicos allí usando la clase que se generó para nosotros a partir de los accesorios del bloque:
¡Eso es todo por ahora! Cuando ejecutamos la compilación, esto se compila en build/style.css y es referenciado tanto por el Editor de bloques como por el front-end.
estilos de fondo
Es posible que deba escribir estilos que sean específicos del Editor de bloques. Para eso crea src/editor.scss (otra vez, @wordpress/create-block hace esto por ti) y coloca algunos estilos allí:
Luego importarlo en edit.js, que es el archivo que contiene nuestro Edit componente (podemos importarlo donde queramos, pero como estos estilos son para el editor, es más lógico importar el componente aquí):
import "./editor.scss";
Ahora cuando corremos npm run build, los estilos se aplican al bloque en ambos contextos:
Primeros pasos con el desarrollo de bloques de WordPressPrimeros pasos con el desarrollo de bloques de WordPress
Estilos de referencia en block.json
Importamos los archivos de estilo en el edit.js y index.js, pero recuerde que el paso de compilación genera dos archivos CSS para nosotros en el build directorio: index.css y style-index.css respectivamente. Necesitamos hacer referencia a estos archivos generados en los metadatos del bloque.
Agreguemos un par de afirmaciones al block.json metadatos:
Ejecutar npm run build una vez más, instale y active el complemento en su sitio de WordPress, ¡y estará listo para usarlo!
Puedes usar npm run start para ejecutar su compilación en modo reloj, compilando automáticamente su código cada vez que realiza un cambio en su código y lo guarda.
Estamos arañando la superficie
Los bloques reales hacen uso de la barra lateral de configuración del editor de bloques y otras características que WordPress proporciona para crear experiencias de usuario ricas. Además, el hecho de que haya esencialmente dos versiones de nuestro bloque: edit y save — también debe pensar en cómo organiza su código para evitar la duplicación de código.
Pero espero que esto ayude a desmitificar el proceso general para crear bloques de WordPress. Esta es realmente una nueva era en el desarrollo de WordPress. Es difícil aprender nuevas formas de hacer las cosas, pero tengo muchas ganas de ver cómo evoluciona. Herramientas como @wordpress/create-block ayuda, pero incluso entonces es bueno saber exactamente lo que está haciendo y por qué.
¿Van a cambiar las cosas que cubrimos aquí? ¡Más probable! Pero al menos tiene una línea de base para trabajar a medida que seguimos viendo madurar los bloques de WordPress, incluidas las mejores prácticas para hacerlos.
Referencias
Una vez más, mi objetivo aquí es trazar un camino eficiente para entrar en el desarrollo de bloques en esta temporada en la que las cosas están evolucionando rápidamente y la documentación de WordPress está teniendo dificultades para ponerse al día. Aquí hay algunos recursos que usé para juntar esto:
