Vamos reconhecer que desenvolver para WordPress é estranho agora. Se você é novo no WordPress ou já trabalhou com ele por eras, a introdução de recursos de “Edição de site completo” (FSE), incluindo o Editor de Bloco (WordPress 5.0) e o Editor de Site (WordPress 5.9), mudaram a maneira tradicional de construir temas e plugins do WordPress.
Apesar de já terem se passado cinco anos desde que conhecemos o Block Editor pela primeira vez, desenvolver para ele é difícil porque a documentação está faltando ou desatualizada. Isso é mais uma declaração sobre a velocidade com que os recursos do FSE estão se movendo, algo Geoff lamentou em um post recente.
Caso em questão: em 2018, um série introdutória sobre como entrar no desenvolvimento do Gutenberg foi publicado aqui em CSS-tricks. Os tempos mudaram desde então e, embora esse estilo de desenvolvimento ainda funcione, é não recomendado mais (além disso, o create-guten-block projeto em que se baseia também não é mais mantido).
Neste artigo, pretendo ajudá-lo a iniciar o desenvolvimento de blocos do WordPress de uma maneira que siga a metodologia atual. Então, sim, as coisas podem muito bem mudar depois que isso for publicado. Mas vou tentar focar nisso de uma maneira que, espero, capture a essência do desenvolvimento de blocos, porque mesmo que as ferramentas possam evoluir com o tempo, as ideias principais provavelmente permanecerão as mesmas.
O Editor Gutenberg: (1) O bloco de inserção, (2) a área de conteúdo e (3) a barra lateral de configurações Crédito: Manual do Editor de Blocos WordPress
O que são blocos do WordPress, exatamente?
Vamos começar por esclarecer alguma confusão com o que queremos dizer com termos como blocos. Todo o desenvolvimento que entrou nesses recursos que levaram ao WordPress 5.0 foi codinome “Gutenberg” – você sabe, o inventor do prelo.
Desde então, “Gutenberg” tem sido usado para descrever tudo relacionado a blocos, incluindo o Editor de Blocos e o Editor de Site, então ficou complicado na medida em que algumas pessoas desprezar o nome. Para completar, há um Plugin Gutenberg onde os recursos experimentais são testados para possível inclusão. E se você acha que chamar tudo isso de "Edição de site completo" resolveria o problema, há preocupações com isso também.
Portanto, quando nos referimos a “blocos” neste artigo, queremos dizer componentes para criar conteúdo no WordPress Block Editor. Os blocos são inseridos em uma página ou post e fornecem a estrutura para um determinado tipo de conteúdo. O WordPress vem com um punhado de blocos “principais” para tipos de conteúdo comuns, como Parágrafo, Lista, Imagem, Vídeo e Áudio, para nomear alguns.
Além desses blocos principais, também podemos criar blocos personalizados. É disso que se trata o desenvolvimento de blocos do WordPress (também há filtragem de blocos principais para modificar sua funcionalidade, mas você provavelmente não precisará disso ainda).
O que os blocos fazem
Antes de mergulharmos na criação de blocos, devemos primeiro ter uma noção de como os blocos funcionam internamente. Isso definitivamente nos poupará uma tonelada de frustração mais tarde.
A maneira como gosto de pensar sobre um bloco é bastante abstrata: para mim, um bloco é uma entidade, com algumas propriedades (chamadas de atributos), que representam algum conteúdo. Eu sei que isso soa muito vago, mas fique comigo. Um bloco se manifesta basicamente de duas maneiras: como uma interface gráfica no editor de blocos ou como um bloco de dados no banco de dados.
Quando você abre o WordPress Block Editor e insere um bloco, digamos um bloco Pullquote, você obtém uma interface agradável. Você pode clicar nessa interface e editar o texto citado. O painel Configurações à direita da IU do Editor de Blocos oferece opções para ajustar o texto e definir a aparência do bloco.
Quando você terminar de criar sua citação extravagante e clicar em Publicar, a postagem inteira será armazenada no banco de dados no wp_posts tabela. Isso não é novidade por causa de Gutenberg. É assim que as coisas sempre funcionaram – o WordPress armazena conteúdo de postagem em uma tabela designada no banco de dados. Mas o que há de novo é que uma representação do bloco Pullquote faz parte do conteúdo que é armazenado em post_content campo do wp_posts tabela.
Como é essa representação? Dar uma olhada:
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 simples, certo?! Este, no jargão técnico, é o bloco “serializado”. Observe os dados JSON no comentário HTML, "textAlign": "right". Isso é um atributo — uma propriedade associada ao bloco.
Digamos que você feche o Block Editor e, algum tempo depois, abra-o novamente. O conteúdo do relevante post_content campo é recuperado pelo Editor de Blocos. O editor então analisa o conteúdo recuperado e onde quer que encontre isso:
...
…diz em voz alta para si mesmo:
OK, isso parece um bloco Pullquote para mim. Hmm.. tem um atributo também... Eu tenho um arquivo JavaScript que me diz como construir a interface gráfica para um bloco Pullquote no editor de seus atributos. Eu deveria fazer isso agora para tornar este bloco em toda a sua glória.
Como desenvolvedor de blocos, seu trabalho é:
Diga ao WordPress que você deseja registrar um tipo específico de bloco, com detalhes de fulano de tal.
Forneça o arquivo JavaScript para o Editor de Blocos que o ajudará a renderizar o bloco no editor ao mesmo tempo em que o “serializa” para salvá-lo no banco de dados.
Forneça quaisquer recursos adicionais que o bloco precise para sua funcionalidade adequada, por exemplo, estilos e fontes.
Uma coisa a notar é que toda essa conversão de dados serializados para interface gráfica – e vice-versa – ocorre apenas no Editor de Blocos. No front-end, o conteúdo é exibido exatamente da forma como está armazenado. Portanto, em certo sentido, os blocos são uma maneira elegante de colocar dados no banco de dados.
Espero que isso lhe dê alguma clareza sobre como um bloco funciona.
Começando com o desenvolvimento de blocos do WordPress
Blocos são apenas plugins
Blocos são apenas plugins. Bem, tecnicamente, você pode coloque blocos em temas e você pode colocar vários blocos em um plugin. Mas, na maioria das vezes, se você quiser fazer um bloco, você fará um plugin. Então, se você já criou um plugin WordPress, então você já está no meio do caminho para fazer um bloco WordPress.
Mas vamos supor por um momento que você nunca configurou um plugin WordPress, muito menos um bloco. Onde você começa mesmo?
Configurando um bloco
Nós cobrimos o que são blocos. Vamos começar a configurar as coisas para fazer um.
Certifique-se de ter o Node instalado
Isso lhe dará acesso a npm e npx comandos, onde npm instala as dependências do seu bloco e ajuda a compilar coisas, enquanto npx executa comandos em pacotes sem instalá-los. Se você estiver no macOS, provavelmente já tem o Node e pode usar nvm para atualizar as versões. Se você estiver no Windows, precisará baixe e instale o Node.
Criar uma pasta de projeto
Agora, você pode encontrar outros tutoriais que vão direto para a linha de comando e o instruem a instalar um pacote chamado @wordpress/create-block. Este pacote é ótimo porque gera uma pasta de projeto totalmente formada com todas as dependências e ferramentas que você precisa para começar a desenvolver.
Pessoalmente, sigo esse caminho ao configurar meus próprios blocos, mas me divirto por um momento porque quero cortar as coisas opinativas que ele introduz e me concentrar apenas nas partes necessárias para entender o ambiente de desenvolvimento básico.
Estes são os arquivos que eu gostaria de chamar especificamente:
readme.txt: é como a face frontal do diretório do plugin, normalmente usado para descrever o plugin e fornecer detalhes adicionais sobre uso e instalação. Se você enviar seu bloco para o Diretório do plugin do WordPress, este arquivo ajuda a preencher a página do plugin. Se você planeja criar um repositório do GitHub para seu plug-in de bloco, também pode considerar um README.md arquivo com as mesmas informações para que ele seja exibido bem lá.
package.json: define os pacotes Node necessários para o desenvolvimento. Vamos abri-lo quando chegarmos à instalação. No desenvolvimento clássico de plugins do WordPress, você pode estar acostumado a trabalhar com o Composer e um composer.json arquivo em vez disso. Este é o equivalente a isso.
plugin.php: Este é o arquivo de plugin principal e, sim, é o PHP clássico! Vamos colocar nosso cabeçalho e metadados do plugin aqui e usá-los para registrar o plugin.
Além desses arquivos, há também o src diretório, que deve conter o código fonte do nosso bloco.
Tendo esses arquivos e o src diretório é tudo que você precisa para começar. Fora desse grupo, observe que tecnicamente só precisamos de um arquivo (plugin.php) para fazer o plug-in. O restante fornece informações ou é usado para gerenciar o ambiente de desenvolvimento.
O referido @wordpress/create-block pacote scaffolds esses arquivos (e mais) para nós. Você pode pensar nisso como uma ferramenta de automação em vez de uma necessidade. Independentemente disso, torna o trabalho mais fácil, então você pode tomar a liberdade de montar um bloco com ele executando:
npx @wordpress/create-block
Instalar dependências de bloco
Supondo que você tenha os três arquivos mencionados na seção anterior prontos, é hora de instalar as dependências. Primeiro, precisamos especificar as dependências que precisaremos. Fazemos isso editando o package.json. Ao usar o @wordpress/create-block utilitário, o seguinte é gerado para nós (comentários adicionados; JSON não suporta comentários, então remova os comentários se você estiver copiando o 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"
}
}
A @wordpress/scripts package é a principal dependência aqui. Como você pode ver, é um devDependency o que significa que ajuda no desenvolvimento. Como assim? Ele expõe o wp-scripts binário que podemos usar para compilar nosso código, desde o src diretório para o build diretório, entre outras coisas.
Existem vários outros pacotes que o WordPress mantém para vários propósitos. Por exemplo, o @wordpress/components pacote fornece vários pré-fabricados UI componentes para o WordPress Block Editor que pode ser usado para criar experiências de usuário consistentes para o seu bloco que se alinham com os padrões de design do WordPress.
Você na verdade não necessidade para instalar esses pacotes, mesmo se você quiser usá-los. Isso porque esses @wordpress dependências não são empacotadas com seu código de bloco. Em vez disso, qualquer import declarações referenciando código de pacotes de utilitários - como @wordpress/components — são usados para construir um arquivo de “ativos”, durante a compilação. Além disso, essas instruções de importação são convertidas em instruções que mapeiam as importações para propriedades de um objeto global. Por exemplo, import { __ } from "@wordpress/i18n" é convertido para uma versão minificada de const __ = window.wp.i18n.__. (window.wp.i18n sendo um objeto com garantia de disponibilidade no escopo global, uma vez que o i18n arquivo de pacote é enfileirado).
Durante o registro do bloco no arquivo do plugin, o arquivo “assets” é usado implicitamente para informar ao WordPress as dependências do pacote para o bloco. Essas dependências são enfileiradas automaticamente. Tudo isso é cuidado nos bastidores, desde que você esteja usando o scripts pacote. Dito isto, você ainda pode optar por instalar localmente dependências para conclusão de código e informações de parâmetro em seu package.json arquivo:
Agora que package.json estiver configurado, devemos ser capazes de instalar todas essas dependências navegando até a pasta do projeto na linha de comando e executando npm install.
Começando com o desenvolvimento de blocos do WordPress
Adicione o cabeçalho do plug-in
Se você vem do desenvolvimento clássico de plug-ins do WordPress, provavelmente sabe que todos os plug-ins têm um bloco de informações no arquivo de plug-in principal que ajuda o WordPress a reconhecer o plug-in e exibir informações sobre ele na tela de plug-ins do administrador do WordPress.
Aqui está o que @wordpress/create-block gerado para mim em um plugin chamado "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
*/
Isso está no arquivo principal do plugin, que você pode chamar como quiser. Você pode chamá-lo de algo genérico como index.php or plugin.php. O create-block pacote automaticamente o chama qualquer coisa que você fornecer como o nome do projeto ao instalá-lo. Como chamei este exemplo de “Block Example”, o pacote nos deu um block-example.php arquivo com todas essas coisas.
Você vai querer mudar alguns detalhes, como se tornar o autor e outros enfeites. E nem tudo isso é necessário. Se eu estivesse rolando isso do “zero”, então poderia parecer algo mais próximo a isso:
<?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
*/
Já analisamos os arquivos necessários para o nosso bloco. Mas se você estiver usando @wordpress/create-block, você verá vários outros arquivos na pasta do projeto.
build/: esta pasta recebeu os ativos compilados ao processar os arquivos para uso em produção.
node_modules: Isso contém todas as dependências de desenvolvimento que instalamos ao executar npm install.
src/: esta pasta contém o código-fonte do plugin que é compilado e enviado para o build diretório. Veremos cada um dos arquivos daqui a pouco.
.editorconfig: contém configurações para adaptar seu editor de código para consistência de código.
.gitignore: este é um arquivo de repositório padrão que identifica arquivos locais que devem ser excluídos do rastreamento de controle de versão. Sua node_modules definitivamente deve ser incluído aqui.
package-lock.json: Este é um arquivo gerado automaticamente contendo atualizações de rastreamento para os pacotes necessários que instalamos com npm install.
Bloquear metadados
Eu quero cavar no src diretório com você, mas focará primeiro em apenas um arquivo nele: block.json. Se você já usou create-block , já está disponível para você; se não, vá em frente e crie-o. O WordPress está se esforçando para tornar esta a maneira padrão e canônica de registrar um bloco, fornecendo metadados que fornecem contexto ao WordPress para reconhecer o bloco e renderizá-lo no Editor de bloco.
Aqui está o que @wordpress/create-block gerado para mim:
Existe na verdade um monte de informações diferentes podemos incluir aqui, mas tudo o que é realmente necessário é name e title. Uma versão super mínima pode ser assim:
$schema define a formatação do esquema usada para validar o conteúdo no arquivo. Parece uma coisa obrigatória, mas é totalmente opcional, pois permite que editores de código de suporte validem a sintaxe e forneçam outros recursos adicionais, como dicas de dicas de ferramentas e preenchimento automático.
apiVersion refere-se a qual versão do API de bloco o plug-in usa. Hoje, a versão 2 é a mais recente.
name é uma string exclusiva necessária que ajuda a identificar o plug-in. Observe que eu prefixei isso com css-tricks/ que estou usando como um namespace para ajudar a evitar conflitos com outros plugins que possam ter o mesmo nome. Você pode optar por usar algo como suas iniciais (por exemplo, as/block-example).
version é alguma coisa WordPress sugere usar como um mecanismo de bloqueio de cache quando novas versões são lançadas.
title é o outro campo obrigatório e define o nome usado onde quer que o plug-in seja exibido.
category agrupa o bloco com outros blocos e os exibe juntos no Editor de blocos. As categorias existentes atuais incluem text, media, design, widgets, theme e embed, e você pode até criar categorias personalizadas.
icon permite que você escolha algo do Biblioteca de Dashicons para representar visualmente seu bloco no Editor de Blocos. estou usando o format-quote icon](https://developer.wordpress.org/resource/dashicons/#format-quote) já que estamos fazendo nosso próprio tipo de pullquote neste exemplo. É bom podermos aproveitar os ícones existentes em vez de ter que criar nossos próprios, embora isso seja certamente possível.
editorScript é onde está o arquivo JavaScript principal, index.js, vidas.
Registre o bloco
Uma última coisa antes de chegarmos ao código real, e isso é registrar o plugin. Acabamos de configurar todos esses metadados e precisamos de uma maneira para o WordPress consumi-los. Dessa forma, o WordPress sabe onde encontrar todos os ativos do plug-in para que possam ser enfileirados para uso no Block Editor.
O registro do bloco é um processo duplo. Precisamos registrá-lo tanto em PHP quanto em JavaScript. Para o lado do PHP, abra o arquivo de plugin principal (block-example.php neste caso) e adicione o seguinte logo após o cabeçalho do plugin:
Isto é o que o create-block utilitário gerado para mim, então é por isso que a função é nomeada do jeito que é. Podemos usar um nome diferente. A chave, novamente, é evitar conflitos com outros plugins, então é uma boa ideia usar seu namespace aqui para torná-lo o mais exclusivo possível:
Por que estamos apontando para o build diretório se o block.json com todos os metadados do bloco está em src? Isso porque nosso código ainda precisa ser compilado. o scripts pacote processa o código de arquivos no src diretório e coloca os arquivos compilados usados na produção no build diretório, enquanto também copiando oblock.jsonlima no processo.
Tudo bem, vamos passar para o lado JavaScript do registro do bloco. Abra src/index.js e verifique se está assim:
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 na terra do React e JSX! Isso diz ao WordPress para:
Importe o registerBlockType módulo do @wordpress/blocks pacote.
Importar metadados de block.json.
Importe o Edit e Save componentes de seus arquivos correspondentes. Nós estaremos colocando código nesses arquivos mais tarde.
Registre o bloco e use o Edit e Save componentes para renderizar o bloco e salvar seu conteúdo no banco de dados.
O que há com o edit e save funções? Uma das nuances do desenvolvimento de blocos do WordPress é diferenciar o “back end” do “front end” e essas funções são usadas para renderizar o conteúdo do bloco nesses contextos, onde edit lida com renderização de back-end e save grava o conteúdo do Editor de Blocos no banco de dados para renderizar o conteúdo no front-end do site.
Um teste rápido
Podemos fazer um trabalho rápido para ver nosso bloco funcionando no Editor de Blocos e renderizado no front-end. Vamos abrir index.js novamente e use o edit e save funções para retornar algum conteúdo básico que ilustra como elas funcionam:
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 é basicamente uma versão simplificada do mesmo código que tínhamos antes, só que estamos apontando diretamente para os metadados em block.json para buscar o nome do bloco e deixou de fora o Edit e Save componentes já que estamos executando as funções diretamente daqui.
Podemos compilar isso executando npm run build na linha de comando. Depois disso, temos acesso a um bloco chamado “Block Example” no Block Editor:
Se soltarmos o bloco na área de conteúdo, recebemos a mensagem que retornamos do edit função:
Começando com o desenvolvimento de blocos do WordPress
Se salvarmos e publicarmos a postagem, devemos receber a mensagem que retornamos do save função ao visualizá-lo no front-end:
Começando com o desenvolvimento de blocos do WordPress
Criando um bloco
Parece que está tudo ligado! Podemos voltar ao que tínhamos em index.js antes do teste agora que confirmamos que as coisas estão funcionando:
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 o edit e save funções estão vinculadas a dois arquivos existentes no src diretório que @wordpress/create-block gerado para nós e inclui todas as importações adicionais que precisamos em cada arquivo. Mais importante, porém, esses arquivos estabelecem a Edit e Save componentes que contêm a marcação do bloco.
Marcação 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")}
);
}
Veja o que fizemos lá? Estamos importando adereços do @wordpress/block-editor pacote que nos permite gerar classes que podemos usar mais tarde para estilizar. Também estamos importando o __ função de internacionalização, para lidar com traduções.
Começando com o desenvolvimento de blocos do WordPress
Marcação de front-end (src/save.js)
Isso cria um Save componente e vamos usar praticamente a mesma coisa que src/edit.js com texto ligeiramente diferente:
import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";
export default function Save() {
return (
{__("Hello from the front end", "block-example")}
);
}
Novamente, obtemos uma boa classe que podemos usar em nosso CSS:
Começando com o desenvolvimento de blocos do WordPress
Blocos de estilo
Acabamos de abordar como usar adereços de bloco para criar classes. Você está lendo este artigo em um site sobre CSS, então sinto que estaria perdendo algo se não abordassemos especificamente como escrever estilos de bloco.
Diferenciando estilos front e back-end
Se você der uma olhada no block.json no src você encontrará dois campos relacionados a estilos:
editorStyle fornece o caminho para os estilos aplicados ao back-end.
style é o caminho para estilos compartilhados que são aplicados ao front-end e ao back-end.
Kev Quirk tem um artigo detalhado que mostra sua abordagem para fazer o editor de back-end parecer com a interface do usuário do front-end.
Lembre-se de que @wordpress/scripts pacote copia o block.json arquivo quando ele processa o código no /src diretório e coloca os ativos compilados no /build diretório. É o build/block.json arquivo que é usado para registrar o bloco. Isso significa que qualquer caminho que fornecemos em src/block.json deve ser escrito em relação a build/block.json.
Usando Sass
Poderíamos soltar alguns arquivos CSS no build diretório, faça referência aos caminhos em src/block.json, execute a compilação e encerre um dia. Mas isso não aproveita todo o poder do @wordpress/scripts processo de compilação, que é capaz de compilar Sass em CSS. Em vez disso, colocamos nossos arquivos de estilo no src diretório e importá-los em JavaScript.
Ao fazer isso, precisamos estar atentos a como @wordpress/scripts estilos de processos:
Um arquivo chamado style.css or style.scss or style.sass, importado para o código JavaScript, é compilado para style-index.css.
Todos os outros arquivos de estilo são compilados e agrupados em index.css.
A @wordpress/scripts pacote usa webpack para empacotamento e @wordpress/scripts utiliza o Plugin PostCSS para trabalhar com estilos de processamento. PostCSS pode ser estendido com plugins adicionais. o scripts O pacote usa os de Sass, SCSS e Autoprefixer, todos disponíveis para uso sem a instalação de pacotes adicionais.
Na verdade, quando você gira seu bloco inicial com @wordpress/create-block, você obtém uma boa vantagem inicial com arquivos SCSS que você pode usar para começar a trabalhar:
editor.scss contém todos os estilos que são aplicados ao editor de back-end.
style.scss contém todos os estilos compartilhados pelo front e back end.
Vamos agora ver essa abordagem em ação escrevendo um pequeno Sass que compilaremos no CSS do nosso bloco. Mesmo que os exemplos não sejam muito atrevidos, ainda estou gravando-os nos arquivos SCSS para demonstrar o processo de compilação.
Frente e estilos de back-end
OK, vamos começar com os estilos que são aplicados tanto no front-end quanto no back-end. Primeiro, precisamos criar src/style.scss (já está lá se você estiver usando @wordpress/create-block) e certifique-se de importá-lo, o que podemos fazer em index.js:
import "./style.scss";
Abrir src/style.scss e coloque alguns estilos básicos lá usando a classe que foi gerada para nós a partir dos adereços do bloco:
Por enquanto é isso! Quando executamos a compilação, isso é compilado em build/style.css e é referenciado pelo Editor de Blocos e pelo front-end.
Estilos de back-end
Pode ser necessário escrever estilos específicos para o Editor de Blocos. Para isso, crie src/editor.scss (novamente, @wordpress/create-block faz isso por você) e coloque alguns estilos lá:
Em seguida, importe-o em edit.js, que é o arquivo que contém nosso Edit componente (podemos importá-lo para onde quisermos, mas como esses estilos são para o editor, é mais lógico importar o componente aqui):
import "./editor.scss";
Agora quando corremos npm run build, os estilos são aplicados ao bloco em ambos os contextos:
Começando com o desenvolvimento de blocos do WordPressComeçando com o desenvolvimento de blocos do WordPress
Referenciando estilos em block.json
Importamos os arquivos de estilo no edit.js e index.js, mas lembre-se de que a etapa de compilação gera dois arquivos CSS para nós no build diretório: index.css e style-index.css respectivamente. Precisamos referenciar esses arquivos gerados nos metadados do bloco.
Vamos adicionar algumas declarações ao block.json metadados:
Execute npm run build mais uma vez, instale e ative o plugin em seu site WordPress e você estará pronto para usá-lo!
Você pode usar npm run start para executar sua compilação no modo de observação, compilando automaticamente seu código toda vez que você fizer uma alteração em seu código e salvá-lo.
Estamos arranhando a superfície
Blocos reais fazem uso da barra lateral Configurações do Editor de Blocos e outros recursos que o WordPress fornece para criar experiências de usuário ricas. Além disso, o fato de haver essencialmente duas versões do nosso bloco — edit e save — você também precisa pensar em como organizar seu código para evitar a duplicação de código.
Mas espero que isso ajude a desmistificar o processo geral de criação de blocos do WordPress. Esta é realmente uma nova era no desenvolvimento do WordPress. É difícil aprender novas maneiras de fazer as coisas, mas estou ansioso para ver como isso evolui. Ferramentas como @wordpress/create-block ajuda, mas mesmo assim é bom saber exatamente o que está fazendo e por quê.
As coisas que abordamos aqui vão mudar? Provavelmente! Mas pelo menos você tem uma linha de base para trabalhar enquanto continuamos observando os blocos do WordPress amadurecendo, incluindo as melhores práticas para criá-los.
Referências
Novamente, meu objetivo aqui é mapear um caminho eficiente para entrar no desenvolvimento de blocos nesta temporada, onde as coisas estão evoluindo rapidamente e a documentação do WordPress está tendo um pouco de dificuldade em acompanhar. Aqui estão alguns recursos que usei para reunir isso:
