Tag: WordPress

Categorias
WordPress

Por que instalar um plugin de cache WordPress nem sempre resolve o seu problema.

Performance WordPress vs. Plugins de cache

Um dos assuntos mais populares no Youtube são os vídeos que ensinam como deixar o seu site WordPress “rápido”. Muitas vezes a ação se resume a instalar um plugin de cache WordPress. Essa é uma solução super simples que ajuda muita gente mas…

Qual é o problema com plugins de cache?

Não existe nenhum problema eles só criam um falso positivo. Não vou falar de um plugin específico, mas plugins de cache 99% trabalham dois pontos cache no browser e cache no servidor. Ambos demandam atenção mas para esse post vamos falar sobre:

Cache de assets no Browser

O cache de arquivos estáticos no browser é algo já utilizado desde os primórdios da web e continua muito útil. Ele funciona da seguinte forma quando o usuário acessa nossa aplicação a primeira vez uma lista de arquivos são armazenados no cache para quando o usuário retornar para sua aplicação não precisa ir na rede requisitar esses arquivos novamente, assim criando a sensação do carregamento rápido.

Esse carregamento “Rápido” cria uma falsa ilusão que está tudo bem, vamos pegar um exemplo um dos vídeos que assisti tem um site de uma imobiliária, a homepage carrega 5.1 megabytes, testando em uma conexão de fibra página carrega a primeira vez em 10 segundos sem o cache. Com o cache habilitado 5 segundos. Maravilha uma redução de 50% que é verdade.

Mas temos dois problemas:

  • Primeiro minha conexão é 5o mbps não é uma conexão média para os usuários, no Brasil a conexão média gira em torne de 6,8mbps mas particularmente não acredito nessa média, quando testamos simulando uma conexão 3G lenta esse tempo de carregamento vai para mais 60 segundos.
  • O segundo problema o cache funciona quando usuário retorna a nossa aplicação e você acha que um usuário que carregou o seu site em mais de 60 segundos irá retornar?

Vale apenas lembrar que um site de 5.1mb não é um problema do plugin de cache WordPress. Baseado nesse exemplo que é muito comum na maioria das aplicações web, vou falar de alguns items que demandam atenção para melhoria da performance da sua aplicação web. Vou tentar entrar nesses assuntos de forma não muito técnica porque esse é um assunto válido para todos os tipos de usuários.

Imagens

Como vimos no exemplo anterior o site utilizado no teste, dos 5.1 megabytes 4.5 megabytes são imagens isso representa 88% do tamanho total da aplicação. Estudos apontam que na média imagens representam 80% do tamanho total da aplicação. Muito comum encontrar aplicações WordPress com thumbnails de 300×300 em alta resolução e mais de 1mb. Antes de realizar o upload das imagens reduza a dimensão das imagens de acordo com a área que será exibida. WordPress também disponibiliza uma série de resoluções por padrão e você pode incluir tamanhos personalizados em seu tema.

Falando em optimização também temos uma série de ferramentas(aplicações web, desktop e plugins) que reduzem o tamanho da imagem sem comprometer a resolução, mas temos um bom exemplo que é a Progressive web app squoosh com essas ferramentas conseguimos ter uma redução de mais de 60% sem alterar o formato e a resolução das imagens.

Tela inicial do squoosh
Tela inicial do squoosh

Squoosh é uma aplicação web você não precisa baixar nenhum software para utilizar a ferramenta. Como podemos ver na imagem a segui, podemos ter antes e depois da imagem, assim conseguimos ter preview de como a imagem irá ficar após as alterações.

Um test realizado com squoosh
Tela de preview do squoosh

O ideal é que a otimização seja feita antes de realizar o upload das imagens, para não utilizar recursos do seu servidor para processamento de imagens.

Além disso temos uma variedades de formatos que são aplicadas para cada caso. Imagens sem transparência o ideal é a utilização de JPEG temos outros formatos que são ainda melhores que JPEG que é o caso do WEBP mas ainda não possui suporte para todos os browsers mas você consegue criar um fallback para esses casos.

Se você quiser ir além em otimização de imagens pesquise sobre:

  • Lazy loading
  • Imagens responsiva
  • CDN para imagens

Hospedagem

Fator decisivo na entrega do seu conteúdo é a hospedagem responsável por administrar uma série de serviços que determinam a velocidade da sua aplicação, por exemplo, especificações dos servidores, processamento e memória, dedicado ou compartilhado. Além do fator importante chamado: suporte, se algo der errado e caso você não domine devops como 99% da população global você precisará uma ação eficiente do suporte de sua hospedagem. Isso pode ser crucial para reparar danos de um eventual problema.

Caso você um perfil mais técnico minha sugestão é ir para Cloud e ter um maior controle dos recursos de sua aplicação e muitas vezes sai mais barato a contratação de um serviço de Cloud gringo.

Versão do PHP

Ainda relacionado com a item hospedagem, a versão do PHP precisa ser levado em consideração antes de contratar o serviço, verifique qual a versão PHP que a hospedagem fornece, lançado em 2016 com uma série de melhorias o PHP 7 tinha uma melhora significativa para execução de requisições da sua aplicação por incrível que pareça algumas hospedagens ainda não fornecem a versão 7 ou superior.

Um estudo realizado pela empresa Kinsta mostra que o desempenho de aplicações WordPress utilizando PHP 7.4 é 300% superior a versão 5.6, enquanto a versão 5.6 executa 97.7 requisições por segundo a versão consegue executar 313.4 requisições por segundo.

Versão do mySQL

Vou falar especificamente de mySQL por que é um dos bancos mais populares entre as hospedagens. Banco de dados é um dos pilares de um CMS, ele é responsável por armazenar seus posts e retornar as consultas quando o usuário pesquisa uma palavra chave. Quando o número de posts atravessa a barreira dos mil posts isso fica mais visível. A última versão 8.0 em alguns tipos de operações como consulta a melhoria de desempenho pode chegar a 200%.

Eu comentei a barreira de 1000 post caso tenha um site popular onde consultas são realizadas com frequência e você consegue ver a lentidão dentro do admin isso significa que chegou a hora de utilizar o serviço para melhorar as consulta dentro do WP, não vou fazer propaganda mas você pode pesquisar sobre que irá achar uma série de serviços.

Outra alternativa ao mySQL é o mariaDB banco de dados que possui bons feedbacks da comunidade.

CDN

Comentando sobre o último item, CDN é um fator que otimiza a entrega de arquivos como imagens, css, javascript e fonts. Esse serviço aumenta o valor de sua hospedagem mas alguns plugins e serviços dentro da plataforma WordPress fornecem esse serviço com um valor atrativo.

Como a CDN ou Content Delivery Network funciona? É um sistema otimizado de entrega de conteúdo, seus arquivos serão distribuídos entre servidores ao redor de mundo e quando o usuário requisitar esses arquivos eles serão entregues pelos servidores mais próximos. Além disso CDN podem oferecer funcionalidades como compressão de arquivos.

Compressão de arquivos

Um dos dos algoritmos de compressão mais utilizado é gzip ele tem a capacidade de comprimir e descomprimir arquivos rapidamente, assim reduzindo a taxa de transferencia de arquivos em alguns casos a redução do tamanho dos arquivos pode chegar a 72%, alguns plugins disponibilizam esse recurso. Mas isso pode impactar no uso de CPU dependendo da implementação porque existem diversas formas de implementar gzip, antes de habilitar esse recurso em produção teste o seu plugin de cache WordPress.

Minificação de arquivos.

Minificação é um recursos simples que pode reduzir bastante o tamanho dos seus arquivos de texto: JavaScript, CSS e HTML. Esse é um recurso básico em um plugin de cache WordPress, sempre deixe ele habilitado. Só tenha cuidado alguns plugins realizam uma minificação bem agressiva e podem quebrar o seu tema, então realize teste em diferentes páginas antes de utilizar esse recurso.

Conclusão

Existe uma série de outros recursos que otimizam o desempenho de sua aplicação, mas esse itens listados são baseados na minha experiência. Mas o ponto que quero mostrar é: Plugin de cache WordPress ajudam bastante mas somente a sua instalação não irão resolver todos os seus problemas relacionados a performance.

Performance é um trabalho amplo que nunca tem um ponto final, sempre fique acompanhando as métricas da sua aplicação e analisando os pontos em que você pode melhorar. Se gostou deste assunto dê uma conferida na categoria WordPress no blog e deixe o comentário caso queira saber mais e até o próximo post.

Categorias
Tutoriais WordPress

Criando páginas single para cada categoria (Single templates) no WordPress – 2019

Esse post originalmente era de 2011, dei uma atualizada no conteúdo com alguns novos recursos e correções. Trabalhando com WordPress você tem um arquivo para cada situação específica, por exemplo, o arquivo responsável pela página de categoria é o arquivo category.php, ou page.php para uma página, ou 404.php quando o conteúdo não for encontrado, assim como para página single.

Quando tratamos de post o arquivo mais específico é o single.php, por que o mais específico? Caso o single.php não exista o index.php será responsável por exibir o conteúdo da single ou o mais novo arquivo de template singular.php ele foi introduzido na versão 4.3 do WordPress para exibir o conteúdo de um post ou uma página. A imagem abaixo representa a ordem de carregamento:

estrutura de template wordpress para conteúdo único

Mas além dessas opções também podemos criar uma arquivo para a single de cada categoria, mas isso só é possível com trabalhando com três métodos diferentes: trabalhando com filtros , trabalhando com plugin ou trabalhando com condicional tags.

Carregando diferentes templates com add_filter

A primeira forma é adicionando um filtro para isso devemos adicionar-lo dentro do functions.php, o código ficará da seguinte forma:

add_filter('single_template', 'create_single_template');

function create_single_template( $template ) {
	global $post;

	$categories = get_the_category();
	// caso não tenhamos categoria retornamos o template default.
	if ( ! $categories )
			return $template; 

	//resgatando o post type
	$post_type = get_post_type( $post->ID );

	$templates = array();

	foreach ( $categories as $category ) {
			// adicionando templates por id e slug
			$templates[] = "single-{$post_type}-{$category->slug}.php";
			$templates[] = "single-{$post_type}-{$category->term_id}.php";
	}

	// adicionando os templates padrões
	$templates[] = "single-{$post_type}.php";
	$templates[] = 'single.php';
	$templates[] = 'singular.php';
	$templates[] = 'index.php';

	return locate_template( $templates );
}

Code language: PHP (php)

Explicando código acima, aplicamos um filtro quando o WordPress chama o template para exibir um post, esse código é maior que a versão anterior desse post(2011), por duas razões continuamos retornando uma comportamento padrão e segundo realizamos um tratamento para não sobrescrever a single de um post type, exemplo, caso tenhamos uma categoria filme e um post type filme não termos conflito pois a single da categoria ‘filmes’ será single-post-filmes.php e a single do post type ‘filmes’ será single-filmes.php.

Carregando diferentes templates com Plugin

Alterar functions.php de forma errada pode afetar o funcionamento do todo o seu tema, para evitar problemas caso não domine muito programação a segunda forma é utilizando plugin, ainda sim você precisará de noções de programação para criar o novo template a diferença que qualquer erro afetará somente a página single que você estará criando.

Temos várias opções de plugins os passos serão bem parecidos, vou listar o plugin com atualizações mais recentes o Custom Post Template By Templatic:

  1. Baixe o plugin e instale o plugin em sua aplicação.
  2. Ative o plugin
  3. Crie um novo template para sua página single com um comentário no início do seu arquivo:
<?php
/*
PostType Page Template: [Nome para descrever seu template]
Description: [Essa parte é opcional]
*/
?>

Code language: HTML, XML (xml)

Esse comportamento é bem parecido como template pages, nesse caso o nome do arquivo é irrelevante pode ser qualquer um. Feito isso se tudo ocorrer bem um dropdown irá aparecer na sua página de edição de posts para selecionar o template desejado.

drop down mostrando com utilizar o plugin de template para página single

A terceira forma é trabalhando com tags condicionais, elas são funções que funcionam como perguntas lógicas que retornam true ou false, para nossa solução iremos trabalhar com “in_category()”, para o nosso código não ficar extenso podemos dentro de nosso loop utilizar get_template_part como no exemplo abaixo: 

// dentro do loop
if ( in_category( 'filmes' ) ) {
	get_template_part( 'template-parts/content', 'filmes' );
} else {
	get_template_part( 'template-parts/content', 'post' );
}

Code language: JavaScript (javascript)

O código acima inserimos dentro de nosso single.php não criamos um template novo para toda nossa single e sim um pequeno bloco que será incluído pela função get_template_part, caso o post seja da categoria “filmes” ele ira buscar dentro da pasta template-parts o arquivo “content-filmes.php” nele você irá realizar a customização que você deseja, caso contrário carregamos o arquivo content-post.php um trecho genérico para outras categorias.

Mais infos sobre conditional tags : http://codex.wordpress.org/Conditional_Tags

Qualquer dúvida só deixar um comentário para mais tutoriais sobre WordPress acesse a página da categoria Até o próximo post pessoal!

Categorias
Eventos Geral WordPress

Work smart with Gutenberg

Hi folks, last weekend I’ve done my first talk in 2019, at WordCamp Prague it was a pleasure to be again in Prague, one of my favourite city in Europe and my presentation it was about Gutenberg, I have created a small project with a few examples using static blocks, editable and dynamic blocks, follow the slides:

[slideshare id=134127640&doc=worksmartwithgutenberg-190302142811]

The repository with the examples from my presentation you can find here: https://github.com/fellyph/digital-agency-block-kit

Categorias
WordPress

Criando seu próprio bloco Gutenberg: Parte 2

No post anterior vimos como trabalhar com blocos customizados, conceitos básicos de como registrar nosso bloco Gutenberg como um plugin e criar um markup básico com JavaScript. Nesse post vamos evoluir o nosso bloco todo código está disponível no Github. Primeiro passo vamos ver como os blocos trabalham com estilo externo.

Carregando estilo externo

Primeiro passo será criar nossos arquivos CSS, um arquivo para o front-end de nossa aplicação e o segundo para nosso editor.

style.css(front-end e editor):

.wp-block-fellyph-tutorial-02 {
  background: linear-gradient(45deg, #12c2e9, #c471ed, #f64f59);
  padding: 2em;
  color: white;
  font-size: 20px;
  box-sizing: border-box;
  transform: rotate3d(0, 0, 0, 0);
  transition: all 200ms ease-out;
  box-shadow: 3px 3px 3px #666;
  text-align: center;
}

.wp-block-fellyph-tutorial-02:hover {
  transform: rotate3d(1, 1, 1, -4deg);
}

Code language: CSS (css)

editor-style.css(somente editor)

.wp-block-fellyph-tutorial-02 {
  background: #12c2e9;
  border: 3px solid #666;
  box-shadow: 0 0 0 #666;
}

.wp-block-fellyph-tutorial-02:hover {
  transform: rotate3d(0, 0, 0, 0);
}

Code language: CSS (css)

Temos acima os dois códigos que iremos carregar em nossa aplicação, dois pontos importantes, um o nome da classe ela sempre irá iniciar com ‘wp-block-‘ mais o nome que registramos o nosso bloco Gutenberg, nesse caso o ‘fellyph/tutorial-02‘ irá se transformar em fellyph-tutorial-02, assim temos a classe wp-block-fellyph-tutorial-02.

Segundo ponto, quando trabalhamos com a função register_block_type ela espera 4 parâmetros:

  • style
  • script
  • editor_style
  • editor_script

As propriedades script e style representam os arquivos que serão carregados no editor e front-end da aplicação, enquanto editor_style e editor_script serão carregados apenas no editor do WordPress. Nesse caso o estilo no arquivo editor-style irá sobrescrever o estilo do arquivo style.css. Para ficar mais claro vamos ver o print do resultado desses dois estilos:

front-end de nossa aplicação com o primeiro bloco gutenberg
Estilo aplicado em nosso front-end
tela de edição com um bloco gutenberg
Estilo aplicado em nosso editor

Temos um spoiler de como ficará esse nosso bloco, mas como podemos observar, o bloco no editor herda todas as propriedades do bloco do front-end, por exemplo, alinhamento, padding e a cor da fonte, essas características foram de no arquivo style.css.

index.php

Agora vamos dar uma olhada em nosso arquivo principal:

<?php

/**
 * Plugin Name: Gutenberg tutorial
 * Plugin URI: https://github.com/fellyph/Gutenberg-tutorials
 * Description: Este tutorial ensina como criar um bloco gutenberg https://blog.fellyph.com.br/wordpress-2/criando-seu-proprio-bloco-gutenberg/.
 * Version: 1.2
 * Author: fellyph
 */

defined( 'ABSPATH' ) || exit;

/**
 * 1 - Criando nosso primeiro bloco: Parte 02
 *    - Carregando arquivo externo para nosso estilo
 */
function meu_primeiro_bloco_gutenberg_parte_02 () {

	if ( ! function_exists( 'register_block_type' ) ) {
		// Checamos se temos suporte a função register_block_type antes de tudo.
		return;
	}

	wp_register_script(
		'tutorial-02',
		plugins_url( 'script.js', __FILE__ ),
		array( 'wp-blocks', 'wp-element' ),
		filemtime( plugin_dir_path( __FILE__ ) . 'script.js' )
	);

	wp_register_style(
		'style-editor',
		plugins_url( 'editor-style.css', __FILE__ ),
		array('wp-edit-blocks'),
		filemtime( plugin_dir_path( __FILE__ ) . 'editor-style.css' )
	);

	wp_register_style(
		'style-frontend',
		plugins_url( 'style.css', __FILE__ ),
		filemtime( plugin_dir_path( __FILE__ ) . 'style.css' )
	);

	register_block_type( 'fellyph/tutorial-02', array(
		'style' => 'style-frontend',
		'editor_script' => 'tutorial-02',
		'editor_style' => 'style-editor'
	) );
}

add_action( 'init', 'meu_primeiro_bloco_gutenberg_parte_02' );

Code language: HTML, XML (xml)

Não vamos abordar todas as partes desse código caso não tenha visto a primeira parte dessa séria aqui está o link: https://blog.fellyph.com.br/wordpress-2/criando-seu-proprio-bloco-gutenberg.

Comparado ao tutorial anterior, acrescentamos duas funções wp_register_style, uma para estilo geral e outra para o estilo do nosso editor e por fim passamos como parâmetro na função register_block_type.

script.js

Em nosso script agora temos o seguinte código:

( function( blocks, element ) {
	var el = element.createElement;


	blocks.registerBlockType( 'fellyph/tutorial-02', {
		title: 'Primeiro bloco Gutenberg: Parte 02',
		icon: 'smiley',
    category: 'layout',
  
		edit: function(props) {
			return el(
				'p',
				{ className: props.className },
				'Este conteúdo será exibido no editor.'
			);
		},
		save: function(props) {
			return el(
				'p',
				{ className: props.className },
				'Este conteúdo será exibido para o usuário final.'
			);
		},
	} );
}(
	window.wp.blocks,
	window.wp.element
) );


Code language: JavaScript (javascript)

Comparado a versão anterior passamos nas funções dentro das propriedades edit e save uma propriedade chamada props, ela contém informações referente ao nosso bloco e uma delas é o nome dessa classe, não obrigatório passar o className dinamicamente poderíamos passar um valor estático, mas para facilitar a manutenção e evitar conflitos com outros blocos utilizamos o nome de classe dinamicamente.

Uma observação sobre a propriedade “icon” caso queira saber os ícones disponíveis dentro do WordPress, só acessar o link: https://developer.wordpress.org/resource/dashicons/#smiley lá você irá encontrar uma série de ícones separados por categoria.

lista de ícones do gutenberg
Na página de dashicons você pode conferir o id para cada ícone

No meu caso eu selecionei o ícone smiley, como podemos ver na imagem abaixo, quando clico no ícone temos seu id e como utiliza-lo em nosso CSS ou HTML, mas eu só irei precisar do id ‘dashincons-smiley’ em nosso script usamos ‘dashicons-‘ apenas smiley.

Tela de icones do WordPress

A nível de curiosidade eu alterei a função edit para ver quais são os valores passados dentro de props(você não precisa implementar isso).

edit: function(props) {
	var test = 'Este conteúdo será exibido no editor. / ';
	for(var key in props) {
		test += key + " : " + props[key] + ' / ';
	}

	return el(
		'p',
		{ className: props.className },
		test
		);
	},

Code language: JavaScript (javascript)

O resultado foi o seguinte:

Scree shot do bloco gutenberg

Dentro do objeto props temos as seguintes propriedades e funções:

  • name
  • isSelected
  • attributes
  • setAttributes (function)
  • insertBlocksAfter (function)
  • onReplace (function)
  • mergeBlocks (function)
  • clientId
  • isSelectionEnabled
  • toggleSelection (function)
  • className

Para a estilização de nosso bloco poderíamos trabalhar com atributos dinâmicos, mas esse será assunto para um próximo post. Caso queira saber mais sobre como trabalhar com estilo em blocos customizados só deixar um comentário.

O código desse tutorial você irá encontrar na branch(tutorais/gutenberg-02) do repositório: https://github.com/fellyph/Gutenberg-tutorials/tree/tutoriais/gutenberg-02

Categorias
WordPress

Teoria sobre blocos no Gutenberg

Gutenberg está transformando o modo de se trabalhar com WordPress , onde você utiliza blocos para compor o seu conteúdo atualmente temos uma série de diferentes elementos para compor nosso conteúdo: títulos, parágrafos, conteúdo embedado, HTML, listas, images, galeria de imagem entre outros elementos.

A otimização do Gutenberg foi realizado de forma progressiva, isso significa que temos compatibilidade com o formato de conteúdo anterior com o novo editor. O Gutenberg oferece uma nova forma de se trabalhar com conteúdo distribuído em blocos e com um simples clique e arraste podemos alterar a ordem do conteúdo a qual será apresentado para os nosso usuários. Criando uma real experiencia WYSIWYG.

Blocos

Bloco é a unidade abstrata para organização do conteúdo, com um grupo de blocos montamos o nosso post. Podemos criar hierarquia de blocos, isso significa, podemos ter blocos com blocos filhos. Por exemplo, um bloco de duas colunas possuem um bloco filho pra cada coluna.

Para manter compatibilidade com versões anteriores armazenamos os blocos no banco de dados dentro da coluna wp_content como o WordPress armazena normalmente, com uma pequena diferença os blocos são representados por comentários em um formato entendido pelo back-end do WP se o site desativar o Gutenberg o conteúdo não será exposto para o usuário final. Um exemplo de bloco de paragrafo:

Por exemplo:

<!– wp:paragraph {“key” : “value”} –>
<p>Este é um bloco do gutenberg.</p>
<! — /wp:paragraph –>

No código acima quando o Gutenberg estiver ativado ele vai reconhecer como um bloco, caso não esteja ele será renderizado como um comentário HTML normal.

Blocos possuem duas categorias estáticos e dinâmicos, por exemplo, blocos estáticos apenas exibem um markup sem nenhuma edição no editor, apenas conseguimos definir a ordem dos elementos. Já os blocos dinâmicos exigem dados do banco e renderiza os elementos dinamicamente.

Cada Bloco contém seus atributos ou configurações, cada elemento pode ser alimentado por HTML puro, meta data ou diferentes origens. Uma feature do Gutenberg é a possibilidade criar blocos e copias dos tais, preservando o conteúdo ou apenas o markup. Mas podemos também limitar a quantidade de blocos que serão utilizados nos posts ou fixa-los em uma região específica.

Categorias de blocos

Quando acionamos o Block Inserter, abrimos um pop up com os blocos disponiveis, cada bloco terá um titulo e uma categoria. Podemos ter blocos nativos ou blocos customizados por plugins ou tema.

Blocos Reutilizáveis

Nos da a possibilidade de reutilizar blocos e repetir partes de um determinado conteúdo. Qualquer edição feita em um bloco reutilizável será replicado em todas suas cópias.

Templates

O Gutenberg tenta abstrair a estrutura HTML e permitir que o usuário foque apenas no conteúdo a nível técnico sua estrutura abstrai toda estrutura de um template único no formato clássico para uma coleção de elementos reutilizáveis e independentes.

Para entender como os blocos operam a nível de estrutura de dados, precisamos pensar na prensa de impressão de Johannes Gutenberg. A página era montada a partir de caracteres individuais até montar um texto, após a finalização do página os caracteres eram armazenados para serem utilizados em uma nova página.

fonte: https://infograph.venngage.com/p/148195/renaissance-innovations-project-the-first-printing-press-johannes-gutenberg

Nessa estrutura o conteúdo final não está atrelado a impressora, é só uma ferramenta base criação do conteúdo o resultado final não importa. Por muito tempo no desenvolvimento do temas clássico os templates eram páginas completas, agora esse paradigma mudou estamos em estruturas mais unitárias. Podemos recriar um tipo de layout sem precisar rescrever o template do zero.

O ponto principal dos blocos não é definir o resultado final mas sim agilizar o processo de criação de conteúdo.

Árvore de blocos

Além do conteúdo armazenado dentro da coluna post_content para manter a estrutura de correta dos blocos o WordPress criar uma descrição semântica em JSON chamada Tree of blocks ou árvore de blocos. Durante a execução, os blocos são mantidos na memória. Nesse momento, uma postagem do Gutenberg não é HTML, mas uma árvore de objetos e atributos associados. O Gutenberg se baseia em um modelo de dados que preserva a estrutura, de modo que os editores e visualizações para tipos específicos de blocos possam permanecer independentes do HTML final renderizado.

Exemplo:

[
{
type: “core/cover-image”,
attributes: {
url: “my-hero.jpg”,
align: “full”,
hasParallax: false,
hasBackgroundDim: true
},
children: [“Gutenberg posts aren’t HTML”]
},
{
type: “core/paragraph”,
children: [“Lately I’ve been hearing plen…”]
}
];

Como podemos ver existe muita coisa por trás do novo editor uma arquitetura complexa, mas que irá trazer um ganho muito grande para a plataforma. Espero detalhar mais pontos sobre o Gutenberg. Para não ficar uma leitura longa vamos finalizando por aqui nos próximos posts irei trazer mais conceitos chaves dentro do Gutenberg.

Esse post tomou como referencia o Handbook do WordPress leitura extremamente recomendada para você que trabalha com desenvolvimento de temas e plugins na plataforma.