O Que há de Novo no WordPress 5.7 (lazy-loading, HTTPS, Atualizações UI, Novas APIs, e Muito Mais)

Estamos acostumados a ver pequenas e não tão pequenas mudanças e novas características adicionadas ao WordPress Core toda vez que uma nova versão é lançada. WordPress 5.7 não é exceção, e é ótimo ver como cada novo lançamento nos aproxima um pouco mais do Big Picture.

Com várias versões do Block Editor fundidas no Core, o novo lançamento melhora a experiência geral de edição e permite aos desenvolvedores construir blocos mais avançados e adicionar personalizações mais poderosas ao editor de blocos.

Além do editor, o WordPress 5.7 também introduz toneladas de mudanças e grandes recursos, incluindo iframes de carregamento preguiçoso, atualizações da interface de login e registro, redefinição de links de senha, um grande número de correções de bugs e muito mais.

Fizemos nossos testes no DevKinsta, e estamos prontos para compartilhar com você mudanças favoritas que estão vindo com o WordPress 5.7-completo, é claro, com toneladas de capturas de tela e trechos de código.

Se você quiser ir mais além no primeiro grande lançamento de 2021, confira o WordPress 5.7 Development Cycle, Planning Roundup, e o Field Guide.

Portanto, enquanto continuamos a esperar pela edição completa do site (em Core by WordPress 5.8), vamos ficar confortáveis e aproveitar o que há de novo no WordPress 5.7!

O que há de novo no editor de blocos

O WordPress 5.7 traz muitas versões do plugin Gutenberg para o Core. Seria impossível mencionar todas essas adições aqui em cima das muitas mudanças e correções de bugs adicionados ao editor, mas você pode visitar os seguintes links para se aprofundar em cada versão: 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 9.9.

As correções de erros e melhorias de desempenho do Gutenberg 10.0 e 10.1 também fazem parte do WordPress 5.7.

Dito isto, vamos percorrer nossa lista de características e mudanças escolhidas a dedo adicionadas ao editor de blocos com o WordPress 5.7:

Características de Variações de Bloco, Melhorias, e APIs

Introduzidas com o WordPress 5.4, as variações de blocos proporcionam uma forma de o usuário selecionar uma instância diferente do mesmo bloco.

Este recurso funciona em conjunto com a Variações de Blocos API s, uma ferramenta poderosa que permite aos desenvolvedores adicionar, gerenciar ou remover variações de blocos.

O WordPress 5.7 introduz várias melhorias, recursos e novas APIs para variações de blocos, fornecendo uma melhor interface de usuário e ferramentas mais poderosas para desenvolvedores. Vamos mergulhar.

Transformações de variação de blocos

Apresentado inicialmente com Gutenberg 9.4 e agora adicionado ao WordPress 5.7, um comutador de transformação para variação aparece abaixo do cartão de blocos para blocos que suportam este recurso.

Ao registrar uma nova variação de bloco, os desenvolvedores de blocos podem adicionar o comutador de variação ao inspetor de bloco, adicionando a nova opção de transform ao campo de scope variação de bloco, como mostrado no exemplo a seguir (somente código JS):

wp.blocks.registerBlockVariation( 'core/heading', { 
	name: 'green-text', 
	title: 'Green Text', 
	description: 'This block has green text. It overrides the default description.',  
	attributes: { 
		content: 'Green Text', 
		textColor: 'vivid-green-cyan' 
	}, 
	icon: 'palmtree', 
	scope: [ 'inserter', 'transform' ] 
} );

Neste exemplo, uma variação de bloco aparece em duas áreas da IU do editor – o inseridor de blocos e o inspetor de blocos.

Para uma visão aprofundada das Transformações de Variação de Bloco, veja também o PR #26687.

Informação de bloco agora combina com as variações de bloco

Desde o WordPress 5.7 (e Gutenberg 9.7), a IU mostra informações mais específicas sobre variações de blocos, enquanto anteriormente mostrava apenas informações genéricas.

Os blocos incorporados e os ícones sociais são construídos como variações de blocos; eles fornecem bons exemplos de correspondência entre as informações de blocos do WordPress e as variações de blocos.

Estas mudanças afetam o inspetor de bloco, a barra de navegação de bloco e o pão ralado. Desde Gutenberg 9.8, este aprimoramento da IU também se aplica ao interruptor de bloco.

Novas variações de blocos APIs

O WordPress 5.7 também introduz novas APIs que os desenvolvedores podem usar no registro de variação de bloco para mostrar as informações corretas de uma variação de bloco (Gutenberg 9.7).

A nova propriedade isActive é uma função que aceita os atributos de um bloco. Você pode usar os atributos da variação para determinar se uma variação está ativa (ver também Referência API do bloco).

Os desenvolvedores de blocos podem usar esta função para exibir informações de variação ao invés de informações de bloco. Um exemplo poderia ser o bloco embed, onde podemos alterar o valor do atributo providerNameSlug (um exemplo da nota do dev):

const variations = [
{
	name: 'wordpress',
	title: 'WordPress',
	keywords: [ __( 'post' ), __( 'blog' ) ],
	description: __( 'Embed a WordPress post.' ),
	attributes: { providerNameSlug: 'wordpress' },
	isActive: ( blockAttributes, variationAttributes ) =>
		blockAttributes.providerNameSlug === variationAttributes.providerNameSlug,
},
];

No exemplo a seguir, a propriedade isActive é utilizada para mudar o atributo de cor:

variations: [
{
	name: 'blue',
	title: __( 'Blue Quote' ),
	isDefault: true,
	attributes: { color: 'blue', className: 'is-style-blue-quote' },
	icon: 'format-quote',
	isActive: ( blockAttributes, variationAttributes ) =>
		blockAttributes.color === variationAttributes.color
},
],

O novo usoBlockDisplayInformation hook retorna informações sobre um determinado bloco. O novo hook leva em conta a propriedade isActive de uma variação de bloco e retorna o title, icon e description do bloco.

Estas mudanças afetam o Cartão de Bloco (Ferramentas do Inspetor), Vista da Lista de Navegação (barra superior), e Breadcrumbs (ver também PR #27469).

Características dos Novos Botões de Bloqueio

Algumas características novas melhoram a funcionalidade e a interface dos botões de bloqueio.

Dimensões dos botões

Um novo controle disponível em Settings Sidebar agora nos permite definir uma largura percentual para botões alojados em blocos de botões (Gutenberg 9.4).

Basta selecionar um botão e escolher 25%, 50%, 75%, ou 100%. As porcentagens se referem ao recipiente pai. A imagem abaixo mostra diferentes combinações de dimensões de botões.

Para obter mais informações técnicas, confira os pedidos de retirada #25999 e #26781.

Layout Vertical

Esta nova característica acrescenta variações para orientação vertical ao bloco de botões. Os usuários podem mudar de um layout horizontal para um vertical usando o comutador de Transformações disponível no painel de ajustes do bloco (Gutenberg 9.6).

Melhorias nos Ícones Sociais

WordPress 5.7 adiciona novas opções de personalização aos Ícones Sociais: suporte a tamanho personalizado e cores personalizadas.

Tamanho dos Ícones Sociais

Com o bloco de ícones sociais selecionado, a barra de ferramentas do bloco agora fornece um menu de opções de tamanho com tamanhos disponíveis (Gutenberg 9.4).

Cores Personalizadas em Ícones Sociais

O mesmo bloco agora suporta configurações de cores, permitindo-nos definir diferentes cores personalizadas para ícones e fundos (Gutenberg 9.9).

Agora você pode usar a paleta de cores do tema para Ícones Sociais, evitando que as cores dos ícones entrem em conflito com o esquema de cores de seu site (ver também PR #28084).

Suporte ao tamanho da fonte

O WordPress 5.7 adiciona suporte ao tamanho da fonte tanto para blocos de Lista como de Código.

Tamanho da fonte no bloco de lista

Uma placa tipográfica com controles para o tamanho da fonte foi adicionada às configurações de blocos de Lista (Gutenberg 9.4).

Os usuários podem escolher um dos tamanhos de fonte disponíveis para itens da lista ou definir um tamanho de fonte personalizado expresso em pixels. O botão “Reset” restaura os valores padrão.

Suporte ao tamanho da fonte em bloco de código

O WordPress 5.7 também adiciona suporte ao gerenciamento do tamanho da fonte dentro de blocos de código. Com um bloco de Código selecionado, a barra lateral de configurações do bloco exibe um novo controle do tamanho da fonte. Este controle permite que você escolha um dos tamanhos predefinidos disponíveis em seu tema ou defina um valor personalizado em pixels (Gutenberg 9.5).

A implementação deste recurso também permite utilizar variáveis de estilo global no CSS de blocos de código (ver também PR #27294). A imagem abaixo mostra um bloco de Código no frontend com o tema Twenty Twenty instalado.

Alinhamento em Altura Total em Bloco da Cobertura

WordPress 5.7 introduz um novo componente de Alinhamento da Barra de Ferramentas em Altura Total. Ele foi adicionado pela primeira vez ao editor de blocos com Gutenberg 9.5. Agora, ele é fundido no Core e implementado no bloco Cover.

Se você alternar o botão da barra de ferramentas do bloco, mantendo um olho no controle de altura mínima, você verá que o alinhamento em altura total é apenas um curto-circuito para 100vh (leia mais sobre os comprimentos do viewport-percentage).

Você pode usar Alinhamento em Altura Total em combinação com outros ajustes de controle como fundo fixo, posição de conteúdo, e assim por diante. Você provavelmente ficará surpreso com o número de efeitos impressionantes que você poderá criar em suas páginas.

Blocos e Padrões de Arrastar e Soltar do inseridor

O inseridor de blocos agora suporta drag & drop para blocos e padrões. Os usuários podem pegar qualquer bloco ou padrão do inseridor e colocá-lo em qualquer lugar da tela do poste (Gutenberg 9.6 e 9.7).

Note que o drag & drop só funciona se seu tema suportar padrões de blocos.

Bloco Espaçador Semi-transparente

No lugar da antiga cor cinza opaca, o bloco Spacer agora tem um fundo semi-transparente (Gutenberg 9.8).

Esta característica deve facilitar a identificação do bloco espaçador em cima de qualquer cor de fundo.

Melhorias adicionais no Editor de Blocos que merecem ser mencionadas

Nossa lista não cobrirá todas as características e melhorias fundidas no Core, portanto não deixe de verificar a documentação oficial e as notas de desenvolvimento para um registro mais abrangente do que há de novo no editor de blocos com o WordPress 5.7.

Mas só para citar alguns outros, em 5.7, você também vai encontrar:

• Ligar automaticamente o Modo Escuro quando o fundo escuro estiver ativado (PR #28233)
• Ícones Patreon, Telegram e TikTok adicionados aos Ícones Sociais (PR #26118)
• Todas as unidades suportadas em Configurações de tamanho da fonte (PR #26475)
• Bloco transforma antevisões (PR #27861)
• Visualização melhorada do padrão de blocos no inseridor de blocos (PR #27204)
• O modal Options foi melhorado, e o nome mudou para Preferences
• Mudanças no @wordpress/data API
• Mudanças na API dos Blocos Internos
• Melhorias nas recurso de importação/exportação
• Mudanças nos componentes e blocos do editor de blocos

Carregamento preguiçoso (Lazy-loading) iframes

O carregamento preguiçoso é uma técnica de otimização que adia o carregamento de recursos não críticos até que eles estejam no ponto de vista do usuário. Imagens de carga preguiçosa e recursos embutidos não são baixados e renderizados até que sejam necessários. Ela pode melhorar significativamente o desempenho do site, especialmente para sites com imagens e vídeos de alta resolução.

Antes do carregamento preguiçoso nativo, os desenvolvedores só podiam carregar preguiçosamente os ativos via JavaScript. Os usuários do WordPress foram forçados a usar um plugin para obter o mesmo efeito. Como o carregamento preguiçoso tornou-se um padrão, no entanto, imagens e iframes podem ser carregados preguiçosamente simplesmente adicionando o atributo loading="lazy" às tags img e iframe.

O WordPress 5.5 introduziu o Native Image Lazy-Loading no WordPress Core, adicionando automaticamente o atributo loading="lazy" às tags img com atributos de width e height especificados.

Agora, desde o WordPress 5.7, o carregamento preguiçoso é estendido para etiquetas iframe. Quanto às imagens, para evitar mudança de layout, o loading="lazy" só será adicionado às tags iframe com atributos de width e height especificados.

No WordPress, a carga nativa preguiçosa funciona com iframes nos seguintes contextos:

• iframes no conteúdo do post (the_content)
• iframes em excertos postais (the_excerpt)
• iframes em widgets de texto (widget_text_content)

No WordPress, a maioria dos iframes depende da integração oEmbed, que transforma automaticamente uma URL na tag iframe correspondente. Infelizmente, nem todo serviço web fornece atributos de width e height para iframes; isto impede que o WordPress acrescente o atributo de loading a esses iframes.

A imagem abaixo mostra uma tag iframe com o atributo loading="lazy" (carregamento=preguiçoso):

Nas palavras de Felix Arntz:

A marcação dessas etiquetas iframe é controlada pelo respectivo serviço web, e apenas alguns desses serviços web seguem a melhor prática de fornecer atributo de width e height. Como o WordPress não pode adivinhar as dimensões do recurso incorporado, o atributo loading="lazy" só será adicionado se a tag iframe oEmbed vier com ambos os atributos de dimensão presentes.

A imagem a seguir mostra uma tag iframe sem o atributo loading="lazy":

Carregamento preguiçosa (Lazy-Loading) iframes para os desenvolvedores

Do ponto de vista do desenvolvedor, a nova característica exigiu várias mudanças, inclusive:

• O comportamento da função wp_filter_content_tags() foi estendido para adicionar o atributo de loading às tags iframe. O atributo de loading foi anteriormente adicionado apenas às tags img.
• Por padrão, a função wp_lazy_load_enabled() agora retorna true para iframe tags (quando ativado).
• A nova função wp_iframe_tag_add_loading_attr() permite a adição do atributo de loading a iframe tags (semelhante a wp_img_tag_add_loading_attr()-ver referência de código).
• O filtro wp_iframe_tag_add_load_attr permite a personalização do carregamento preguiçoso em iframes específicos. Retornar false ou uma string vazia não adicionará o atributo.

Você pode substituir o comportamento padrão usando o filtro wp_lazy_enabled_enabled, que agora retorna true para iframe tags.

add_filter(
	'wp_lazy_loading_enabled',
	function( $default, $tag_name, $context ){
		if ( 'iframe' === $tag_name && 'the_content' === $context ){
			return false;
		}
		return $default;
	},
	10,
	3
);

Você também pode usar o novo filtro wp_iframe_tag_add_load_attr, que permite a personalização do comportamento de uma tag iframe específica. Por exemplo, você pode desativar o carregamento preguiçoso de vídeos do YouTube em um contexto particular.

O código abaixo é baseado em um exemplo da nota do dev e mostra como desativar o carregamento preguiçoso para iframes incorporando vídeos do YouTube:

add_filter(
	'wp_iframe_tag_add_loading_attr',
	function( $value, $iframe, $context ){
		if ( 'the_content' === $context && false !== strpos( $iframe, 'youtube.com' ) {
		return false;
	},
	10,
	3
);

Note que todos os navegadores da web geralmente não suportam carregamento preguiçoso no momento desta redação. Você pode ver abaixo que Firefox e Safari só suportam carregamento preguiçoso em imagens.

Migração de um clique de HTTP para HTTPS

Desde 5.7, o WordPress detectará se o ambiente de um site suporta HTTPS. Se assim for, a seção HTTPS Status na ferramenta Site Health fornece um botão de chamada para ação que permite aos administradores do site mudar seus sites de HTTP para HTTPS com um único clique. O conteúdo do site é migrado na hora, evitando que nos deparemos com quaisquer avisos de conteúdo misto.

O WordPress exibirá uma notificação se o HTTPS não for suportado.

Migração HTTP para HTTPS para Desenvolvedores

Junto com o novo recurso automático acessível a partir da ferramenta Site Health, o WordPress 5.7 introduz novas funções que permitem aos desenvolvedores testar e personalizar diferentes aspectos da detecção e migração de HTTPS.

A nova função wp_is_using_https() retorna true se tanto “Endereço do site” (home_url()) quanto “Endereço WordPress” (site_url()) tiverem um URL contendo https. Esta nova funcionalidade é ilustrada claramente por Felix Arntz na nota de desenvolvimento:

Essencialmente, a mudança destas duas URLs para HTTPS indica formalmente que o site está usando HTTPS. Enquanto existem outras maneiras de habilitar o HTTPS parcialmente no WordPress (por exemplo, com a constante FORCE_SSL_ADMIN), o novo mecanismo de detecção se concentra no uso de HTTPS em todo o site, ou seja, seu frontend e backend.

Enquanto a função wp_is_using_https() verifica a presença de https na URL, wp_is_https_supported() verifica se o ambiente do site suporta corretamente HTTPS.

Esta função verifica essencialmente a presença da opção https_detection_errors no banco de dados e retorna true se nenhum erro for detectado. No caso de seu ambiente não suportar HTTPS, a opção https_detection_errors estará presente na tabela wp_options, como mostra a imagem a seguir:

Como mencionado acima, as URLs hardcoded no conteúdo do site são alteradas na hora, tudo graças a duas novas funções: wp_replace_insecure_home_url() e wp_should_replace_insecure_home_url().

Para migrar um site de HTTP para HTTPS, o administrador do site precisaria apenas atualizar manualmente “Endereço do site” e “Endereço WordPress” para incluir HTTPS ao invés de HTTP. Entretanto, para tornar as coisas ainda mais fáceis, o WordPress 5.7 introduz a nova função wp_update_urls_to_https().

Esta última função permite a migração de um site e todo seu conteúdo de HTTP para HTTPS com um único clique (pelo menos nos cenários mais comuns, como quando “Endereço do site” corresponde a “Endereço WordPress”). É uma novidade absoluta e uma melhoria considerável na experiência de administração do WordPress.

Para aspectos mais técnicos da detecção e migração de HTTPS, veja a nota de desenvolvimento de Felix Arntz, assim como os bilhetes #47577 e #51437.

Novas funções relacionadas ao Post Parent

O WordPress 5.7 introduz duas novas funções relacionadas ao Post Parent. Elas são simples de usar e ajudam a reduzir a lógica em plugins e temas.

has_parent_post()

A função has_parent_post() é uma tag condicional que verifica se um determinado Post Parent, então retorna true ou false de acordo. Ela aceita o objeto post ID ou WP_Post como parâmetro, e usa a variável global $post, se disponível. Veja o exemplo a seguir:

<?php if ( has_parent_post( get_the_ID() ) ) : ?>
	// your code here
<?php endif; ?>

get_parent_post()

A função get_parent_post() é uma etiqueta modelo que recupera o objeto WP_Post pai para um determinado post. Como a função anterior, ela aceita o objeto post ID ou WP_Post como um parâmetro. Veja o seguinte exemplo de utilização:

<a href="<?php the_permalink( get_parent_post( get_the_ID() ) ); ?>"><?php echo get_the_title( get_parent_post( get_the_ID() ) ); ?></a>

No mundo real, nós usaríamos estas funções em conjunto. Você pode fazer um teste por si mesmo adicionando o seguinte código da nota de desenvolvimento ao arquivo de modelo single.php de seu tema:

<?php if ( has_parent_post( get_the_ID() ) ) : ?>
	<p><a href="<?php the_permalink( get_parent_post( get_the_ID() ) ); ?>">
	<?php
		echo sprintf(
			esc_html__( 'Parent page: %s', 'text-domain' ),
			get_the_title( get_parent_post( get_the_ID() ) )
		);
	?>
	</a></p>
<?php endif; ?>

Login e Atualizações da Interface de Registro

O WordPress 5.7 traz várias melhorias no recurso de login e registro, com uma interface melhorada de Reset Password, novos hooks, e outras pequenas mudanças.

Tela de redefinição de senha

A tela de redefinição de senha agora fornece dois botões: Gerar Senha e Salvar Senha. O primeiro botão gera uma nova senha forte a cada clique, enquanto o segundo botão salva sua senha. Esta mudança deve resultar em uma experiência melhorada de redefinição de senha para novos usuários do WordPress.

A imagem abaixo compara as telas Reset Password no WordPress 5.6 e 5.7:

Novos Filtros

O novo hook lostpassword_user_data permite-nos filtrar a variável $user_data no restabelecimento da senha. Os desenvolvedores podem agora realizar a validação do usuário usando dados personalizados em vez de um nome de usuário ou endereço de e-mail. Para um exemplo do mundo real, veja este comentário de Marcelo Villela Gusmão.

O novo hook de filtro login_site_html_link nos permite substituir completamente o HTML gerando o link “Back to {site_name}” com código/link personalizado. Agora os desenvolvedores podem definir texto personalizado para o link, assim como alterar o próprio link. Você pode usar o filtro como ilustrado no exemplo a seguir:

function custom_login_site_html_link( $link ) {
	return '<a href="' . esc_url( home_url( '/blog/' ) ) . '">' . __( 'Back to my awesome blog', 'textdomain' ) . '</a>';
}
add_filter( 'login_site_html_link', 'custom_login_site_html_link', 10, 1 );

A imagem abaixo mostra a saída na tela:

Para mudanças adicionais, verifique as mudanças nas telas de Login e registro no WordPress 5.7 dev note.

Novas funções para verificar se um post é publicamente visível

O WordPress 5.7 introduz duas novas funções que permitem aos desenvolvedores verificar se um post pode ser visto publicamente.

is_post_status_viewable()

A nova função is_post_status_viewable() permite que os desenvolvedores determinem se um post pode ser visualizado publicamente, dependendo do status do post.

Esta nova função fornece uma maneira melhor de verificar se um post é visível do que a função is_post_type_viewable() existente, que pode verificar se um tipo de post é visível para usuários anônimos mas não ajuda a determinar se um post específico é visível ou não.

Para tipos de correio embutidos, is_post_status_viewable() verifica o atributo public. Para tipos de posts personalizados, ele verifica o atributo public_queryable em seu lugar.

Testamos o seguinte código, com base no exemplo da nota do dev, em uma instalação local:

$current_post_status = get_post_status( $post );
if ( is_post_status_viewable( $current_post_status ) ) {
	echo '<p>This post uses a public post status.' . ' Current status: <strong>' . $current_post_status . '</strong></p>';
} else {
	echo '<p>This post uses a non public post status.' . ' Current status: <strong>' . $current_post_status . '</strong></p>';
}

is_post_status_viewable() aceita um parâmetro requerido:

• $post_status (string|stdClass) O nome ou objeto do status do post.

Em um post de blog público, o código acima produziria o seguinte resultado:

Em um artigo privado, o resultado seria o seguinte:

Jean-Baptiste Audras, o autor da nota do dev, adverte:

Favor observar que as mensagens protegidas por senha são consideradas visíveis publicamente, enquanto as mensagens privadas não são.

is_post_publicly_viewable()

A nova função is_post_publicly_viewable() retorna true se ambos is_post_status_viewable() e is_post_type_viewable() retornam true. Ela também nos permite determinar se um determinado post pode ser visualizado publicamente (ou seja, se é visualizável para usuários logados).

is_post_publicly_viewable() aceita um parâmetro opcional:

• $post (string|stdClass) Uma identificação postal ou objeto. Por padrão, o objeto global $post é passado.

Um novo hook dinâmico para filtrar o conteúdo de um tipo de bloco específico

O WordPress 5.7 introduz um novo hook dinâmico que permite aos desenvolvedores filtrar o conteúdo de um tipo específico de bloco.

Este novo filtro de render_block_{$ this->name} é semelhante ao filtro de render_block existente, com uma diferença chave: o render_block filtra o conteúdo de um único bloco, enquanto o novo hook dinâmico filtra o conteúdo do tipo bloco {$ this->name}.

Para utilizar este filtro, você deve fornecer os seguintes parâmetros:

• $block_content (string): O conteúdo do bloco a ser anexado.
• $block (array): O bloco completo, incluindo nome e atributos.

A chamada de retorno retorna o conteúdo modificado do bloco.

O exemplo a seguir mostra um caso de uso para este filtro em um bloco de parágrafos:

add_filter( 
	'render_block_core/paragraph', 
	function( $block_content, $block ) {
		$content  = '<div class="my-custom-wrapper">' . $block_content . '</div>';
		return $content;
	}, 
	10, 
	2 
);

Neste exemplo, o sufixo core/paragraph é a slug do tipo bloco de parágrafo central. Para blocos personalizados, a slug deve ser algo parecido com o my-custom-plugin/my-custom-block.

Veja a nota de desenvolvimento para uma visão mais aprofundada e exemplos adicionais de uso.

Novos Robots API

A meta tag dos robots permite que os proprietários de sites controlem como uma página da web deve ser indexada e servida aos usuários nos resultados dos mecanismos de busca (por falar nisso, não deixe de conferir nosso guia sobre SEO).

O WordPress 5.7 introduz uma nova Robots API que permite aos desenvolvedores controlar esta meta tag de robots. A nova API fornece um filtro wp_robots para que os desenvolvedores de temas possam adicionar suas diretivas personalizadas à meta tag de robots.

Além disso, a max-image-preview:large diretriz é agora adicionada por padrão aos sites configurados para serem visíveis pelos mecanismos de busca. Ela instrui os mecanismos de busca a exibir grandes visualizações de imagens nos resultados da busca.

Os desenvolvedores podem remover a max-image-preview:large diretriz usando o seguinte código:

remove_filter( 'wp_robots', 'wp_robots_max_image_preview_large' );

A personalização das diretrizes para robots é bastante simples. O exemplo seguinte da nota do dev mostra como adicionar uma diretiva personalizada à meta tag:

add_filter( 
	'wp_robots', 
	function( $robots ) {
		$robots['follow'] = true;
		return $robots;
	}
);

O código acima produziria a seguinte saída:

<meta name="robots" content="max-image-preview:large, follow">

Também é possível remover as diretivas existentes simplesmente desajustando os valores. O código a seguir desativa a diretiva de max-image-preview:

function my_wp_robots_directives( $robots ) {
	unset( $robots['max-image-preview'] );
	$robots['follow'] = true;
	return $robots;
}
add_filter( 'wp_robots', 'my_wp_robots_directives' );

Você encontrará uma visão aprofundada da meta tag dos robts no blog Ahrefs e na referência do Google Search. Veja a nota de desenvolvimento para informações adicionais sobre o novo WordPress Robots API e funções depreciadas.

Links para redefinição de senha

Um novo recurso agora permite aos administradores do site enviar links de redefinição de senha via e-mail para qualquer usuário registrado. Este recurso pode ser útil se um usuário não puder acessar o link de redefinição de senha por qualquer motivo.

Os administradores do site podem enviar um link de redefinição de senha via e-mail de diferentes áreas. Primeiro, você encontrará uma nova seção fornecendo um botão Send Reset Link em qualquer tela de perfil do usuário.

Se tudo correr bem, você deve ver um aviso administrativo confirmando que o link de redefinição da senha foi enviado por e-mail para o usuário.

Você também pode enviar um link de redefinição de senha a partir da tela do usuário.

Você pode até mesmo selecionar vários usuários e enviar links de redefinição de senha em massa.

Como mencionado anteriormente, os usuários receberão um e-mail contendo um link para redefinir a senha. A imagem a seguir mostra um e-mail de redefinição de senha na ferramenta Caixa de entrada de e-mail DevKinsta.

Os desenvolvedores podem usar os filtros retrieve_password_title e retrieve_password_message para personalizar o assunto e a mensagem do e-mail.

Melhorias adicionais para os desenvolvedores

Novas Funções para Passar Atributos a Tags de Script

Várias novas funções permitem agora a passagem de atributos para <script> tags (ou seja, async ou nonce).

wp_get_script_tag()

wp_get_script_tag() carrega uma tag de script formatada e injeta automaticamente o atributo type se o tema não tiver declarado suporte a tags de script HTML5. Ele aceita um array de pares de valores chave representando os atributos que estão sendo adicionados à tag <script>.

Esta função é emparelhada com o novo filtro wp_script_attributes, que pode ser usado para filtrar atributos.

wp_print_script_tag()

wp_print_script_tag() imprime uma etiqueta de script formatada.

wp_get_inline_script_tag()

wp_get_inline_script_tag() envolve JavaScript em linha em uma etiqueta de script.

Esta função tem um hook correspondente wp_inline_script_attributes que filtra os atributos a serem adicionados a uma etiqueta de script.

wp_print_inline_script_tag()

wp_print_inline_script_tag() imprime em JavaScript inline em uma etiqueta de script.

wp_sanitize_script_attributes()

A nova função wp_sanitize_script_attributes() é usada para sanitizar uma série de atributos em uma cadeia de atributos. Eles podem então ser adicionados a uma tag de script.

Confira a nota de desenvolvimento para informações adicionais e exemplos de uso.

Cores padronizadas do WP-Admin

Como parte de um projeto maior com o objetivo de limpar o WP-Admin CSS, o WordPress agora usa uma nova paleta de cores padronizada WP-Admin. A nova paleta de cores inclui 12 tons cada um de azul, verde, vermelho e amarelo. Também adiciona 13 tons de cinza, preto e branco. Além disso, atende aos requisitos mínimos de relação de contraste WCAG 2.0 recomendados.

Nas palavras de Jean-Baptiste Audras:

A padronização deste conjunto de cores ajudará os colaboradores a tomar decisões de projeto consistentes e acessíveis. Os desenvolvedores de Temas e Plugins são encorajados a usar esta nova paleta de cores, para melhor consistência entre seus produtos e o WordPress Core.

WP_MEMORY_LIMIT Constante na saúde do site

A constante WP_MEMORY_LIMIT especifica a quantidade máxima de memória que o PHP pode consumir.

Não incluída nas versões anteriores do WordPress também, a constante WP_MEMORY_LIMIT foi adicionada à guia Info em Saúde do Site.

Mudanças adicionais para desenvolvedores estão listadas em várias mudanças com foco no desenvolvedor e Mudanças na API REST no WordPress 5.7. Você encontrará uma lista completa de notas de desenvolvimento no Guia WordPress 5.7.

Resumo

A participação no mercado WordPress continua a crescer a um ritmo constante:

O WordPress é utilizado por 64,4% de todos os sites cujo sistema de gerenciamento de conteúdo conhecemos. Isto é 40,3% de todos os sites da Web.

É uma prova significativa da saúde do CMS, especialmente para aqueles que constroem seus negócios com base no WordPress. E esta é também uma excelente razão para prestar atenção ao que está acontecendo no ecossistema do WordPress.

O WordPress 5.7 acrescenta toneladas de novos recursos e melhorias para usuários e desenvolvedores, mas isso é apenas um gostinho do que podemos esperar ver em 2021.

Agora é com você. Perdemos algo importante? Quais são suas mudanças e características favoritas do WordPress 5.7?