O Que Há de Novo no WordPress 5.6 (Acessibilidade, Desempenho, Segurança)

O WordPress 5.6 “Simone” saiu e estamos entusiasmados em conhecer a fundo com você as características e adições mais interessantes incorporadas ao Core com a última versão do WordPress de 2020.

Como versões anteriores, o WordPress 5.6 inclui várias versões do Editor de Blocos melhorando a experiência de edição para usuários do WordPress que ainda não têm o plugin Gutenberg instalado e atualizado em seus sites.

Mas nem tudo é sobre o Block Editor. Vários recursos foram adicionados ao WordPress Core, como um novo tema padrão Twenty Twenty-One, atualizações automáticas para as principais versões, melhor suporte para PHP 8.0, Senhas de Aplicação para Autenticação REST API.

E há muito mais no WordPress 5.6. Veremos melhorias de acessibilidade, melhorias de IU, toneladas de correções de bugs e uma enorme lista de mudanças para os desenvolvedores.

Se você quiser ler mais sobre o ciclo de desenvolvimento do WordPress 5.6, verifique os links abaixo:

20 de outubro de 2020: Beta 1
27 de outubro de 2020: Beta 2
2 de novembro de 2020: Beta 3
12 de novembro de 2020: Beta 4
17 de novembro de 2020: RC 1
7 de dezembro de 2020: Dry run para lançamento do WordPress 5.6
8 de dezembro de 2020: Lançamento do WordPress 5.6 “Simone”

Pronto para mergulhar?

O que há de novo com o editor de blocos

Com o WordPress 5.6, várias versões do plugin Gutenberg foram fundidas no núcleo, portanto os usuários e escritores do WordPress devem notar várias melhorias no editor. Veremos melhorias nos padrões de blocos, contagem de palavras no painel de informação, navegação melhorada no teclado, melhor UI de arrastar e soltar, e muito mais.

Para uma lista mais abrangente de todas as melhorias e mudanças adicionadas ao editor de blocos, confira os anúncios de lançamento: 8.6, 8.7, 8.8, 8.9, 9.0, 9.1, e 9.2. As correções de bugs e melhorias de desempenho implementadas em Gutenberg 9.3 e 9.4 também estão incluídas no WordPress 5.6.

Vamos mergulhar nas mudanças mais interessantes que veremos no editor do bloco.

Blocos, Padrões e Melhorias da IU
Bloco API V2
Características adicionais e melhorias para desenvolvedores de blocos

Blocos, Padrões e Melhorias da IU

Novas características de bloco, melhorias e correções de bugs melhorarão a experiência geral de edição. Além disso, foi feito um grande trabalho sobre acessibilidade. Abaixo você encontrará nossa seleção selecionada a dedo das características mais interessantes que você verá no editor de blocos assim que atualizar seu website para o WordPress 5.6.

Controles de Posição para Vídeos em Bloco de Capa

Adicionados aos blocos de cobertura desde o Gutenberg 8.6, os controles de posição para vídeos permitem aos usuários mover o ponto focal e definir uma posição personalizada para os vídeos. Esta funcionalidade estava disponível anteriormente apenas para fundos de imagem.

Controles de posição em vídeo para o bloco de cobertura

Os valores de posição são definidos clicando em qualquer lugar no seletor do ponto focal e/ou usando as teclas de seta em seu teclado. Você pode pular os valores em 10 segurando o deslocamento (ver também #22531).

Atualizações de Padrões de Bloco

O WordPress 5.6 também inclui várias melhorias no padrão de blocos adicionados com Gutenberg 8.6.

O layout, texto e cor do cabeçalho e parágrafo Grande foi atualizado (#23858)

O título em Duas colunas de texto foi removido do bloco de texto e colocado acima das colunas (#23853)

O padrão de citação agora inclui uma imagem em cima e um separador em baixo.

O novo padrão de citação inclui uma imagem e um separador

Um novo padrão de título e parágrafo foi adicionado com Gutenberg 8.7 (#24143).

Padrão de cabeçalho e parágrafo no WordPress 5.6

Uma boa melhora na usabilidade do inseridor de blocos é a queda de categoria de padrão de blocos, que permite filtrar padrões por categoria. Isto é extremamente útil quando você tem toneladas de padrões para escolher (#24954).

Apoio para legendas de vídeo

Os blocos de vídeo agora suportam legendas de vídeo.

Adicionando legendas de vídeo em Video Block

Editores e criadores de conteúdo devem fornecer legendas de vídeo em formato WebVTT (Web Video Text Tracks Format), que é “um formato para exibição de faixas de texto cronometradas (como legendas ou legendas) usando o <track> elemento” (#25861).

trilha ligando a legendas em diferentes idiomas

Uma vez que você tenha carregado seus arquivos .vtt, os visualizadores do site poderão habilitar legendas em seu idioma favorito.

Legendas de vídeo configurações do usuário

Transformar blocos múltiplos em um bloco de colunas

Uma melhoria interessante na usabilidade é a capacidade de converter múltiplos blocos selecionados em um Bloco de Colunas.

Você só precisa selecionar os blocos que deseja mostrar em colunas, depois clique no botão superior direito da barra de ferramentas de blocos.

Cada bloco selecionado será convertido em uma coluna de um Bloco de Colunas.

Blocos de árvores convertidos em colunas de árvores

Padrões de fundo em bloco de cobertura

Os blocos de cobertura podem agora exibir padrões de fundo.

Um bloco de cobertura com um padrão de fundo

Para adicionar um padrão de fundo, carregue uma imagem padrão e, em seguida, alterne para a opção de fundo repetido (aqui está tudo o que você precisa saber sobre a Biblioteca de Mídia no WordPress).

Quando estiver pronto, ajuste o seletor do ponto focal de acordo com suas necessidades e tente combinações diferentes com fundos fixos.

Controle do tamanho da imagem adicionado à mídia e ao bloco de texto

Com Gutenberg 9.1, um novo controle de tamanho de imagem foi adicionado às imagens em Media & Text Block.

Os usuários podem agora escolher entre todos os tamanhos de imagem disponíveis (#24795).

Controle do tamanho da imagem na mídia e bloco de texto

Block API V2

Uma nova versão do Block API permite aos blocos renderizar seu elemento de embalagem. O objetivo da nova versão API é aliviar o DOM do editor e torná-lo compatível com o conteúdo da primeira página. De acordo com Ella van Durpe:

O maior benefício disto é que os temas e plugins podem mais facilmente estilizar o conteúdo do bloco se a marcação for a mesma no editor.

A nova versão exige a declaração da propriedade apiVersion no registro do tipo bloco:

registerBlockType( name, { apiVersion: 2 } );

A nova API também requer o gancho useBlockProps na função Edit bloco. Este gancho marca o elemento envolvente de um bloco como um elemento de bloco.

Qualquer propriedade passada para este gancho será fundida e devolvida ao elemento de embalagem. O seguinte exemplo das notas do dev mostra um caso de uso simples:

import { useBlockProps } from '@wordpress/block-editor';
 
function Edit( { attributes } ) {
	const blockProps = useBlockProps( {
		className: someClassName,
		style: { color: 'blue' },
	} );
	return <p { ...blockProps }>{ attributes.content }</p>;
}

Para mais exemplos, consulte o Bloco API versão 2.

Características adicionais e melhorias para desenvolvedores de blocos

Além do Bloco API Versão 2, aqui está uma lista de adições para os desenvolvedores passarem.

Suporte de bloco API

O suporte de blocos API permite que os desenvolvedores de blocos adicionem recursos a seus blocos. Cores, fundos, tamanhos de fonte são apenas algumas das muitas características que podem ser adicionadas aos blocos através da API de Suporte de Bloco.

O WordPress 5.6 também introduz vários novos suportes de blocos “para aumentar a consistência e facilitar a introdução destas opções em blocos”.

Os desenvolvedores podem usar os novos suportes de bloco adicionando as chaves correspondentes à propriedade de supports do arquivo block.json ou diretamente na função registerBlockType.

O seguinte exemplo do Block Supports dev note mostra que ele funciona bem:

supports: {
	color: {
		background: true, // Enable background color UI control.
		gradient: true, // Enable gradient color UI control.
		text: true // Enable text color UI control.
	},
	fontSize: true, // Enable font size UI control.
	lineHeight: true // Enable line height UI control.
}

O valor de estilo será automaticamente anexado ao elemento de embalagem, seja através da categoria has-<-value>-<-preset-category> class (para valores pré-definidos) ou com um elemento de style (para valores personalizados).

Por este motivo, os Suportes de Bloco destinam-se a ser utilizados com o novo Bloco API V2.

Os suportes de blocos também podem ser usados com blocos dinâmicos.

createBlocksFromInnerBlocksTemplate API

Os desenvolvedores podem usar o componente InnerBlocks para criar blocos personalizados contendo outros blocos. Exemplos disso são o bloco Colunas e o bloco Links Sociais.

O novo createBlocksFromInnerBlocksTemplate Block API permite criar blocos a partir do modelo InnerBlocks.

Veja as notas do dev para uma visão do depper e um exemplo de código.

Componentes da barra de ferramentas

Algumas mudanças também afetam os componentes da barra de ferramentas:

1. Componente do Toolbar Group

Antes do WordPress 5.6, o componente da barra de ferramentas permitia que os desenvolvedores agrupassem opções relacionadas em um recipiente comum. Agora, um novo componente ToolbarGroup deve ser usado em seu lugar.

<BlockControls>
	<ToolbarGroup>
		<ToolbarButton />
	</ToolbarGroup>
</BlockControls>

2. Barra de ferramentas Botão e componentes da barra de ferramentas Item

O uso de elementos tabuláveis diretamente como itens da barra de ferramentas (ou seja, <button> ) foi depreciado. Com o objetivo de melhorar a acessibilidade, os itens da barra de ferramentas podem ser adicionados usando Toolbar Button para botões e Toolbar Item para outros controles. O exemplo abai xo mostra um botão e um menu suspenso:

<BlockControls>
	<ToolbarItem as="button" />
	<ToolbarButton />
	<ToolbarItem>
		{ ( itemProps ) => ( <DropdownMenu toggleProps={ itemProps } /> ) }
	</ToolbarItem>
</BlockControls>

Desabilitando os Padrões de Blocos Nucleares

Os padrões principais podem agora ser desativados usando a core-block-patterns (#24042)

Desabilitando o Editor de Imagens Inline

Gutenberg 8.4 adicionou um recurso de Edição de Imagem Inline que permite aos usuários editar imagens diretamente do Editor de Blocos.

Os desenvolvedores podem agora desativar o Editor de Imagens usando o filtro block_editor_settings (#23966):

add_filter( 'block_editor_settings', function( $settings ) {
	$settings['imageEditing'] = false;
	return $settings;
} );

Blocos reutilizáveis movidos para um pacote separado

Os blocos reutilizáveis, anteriormente parte do pacote @wordpress/editor, foram movidos para o pacote @wordpress/reusable-blocks para torná-los disponíveis em outros editores.

Um Novo Tema Default: Twenty Twenty-One

O WordPress 5.6 inclui um tema padrão totalmente novo. TwentyTwenty-One é um tema WordPress altamente acessível e minimalista, com um layout de uma única coluna e uma barra lateral de rodapé.

O novo tema utiliza uma pilha de fontes do sistema e uma paleta de cores mínima baseada em cores de fundo pastel.

Você pode ler muito mais sobre o Twenty Twenty-One em nosso blog aprofundado: Twenty Twenty-One: Um mergulho profundo novo tema padrão do WordPress).

Atualizações automáticas para grandes lançamentos

As atualizações automáticas são uma característica central introduzida no WordPress 3.7 com o objetivo de melhorar a segurança do site e facilitar aos administradores do site a manutenção de seus sites WordPress atualizados.

Enquanto as pequenas atualizações automáticas do núcleo foram implementadas em versões anteriores, com o WordPress 5.6 os administradores do site podem agora habilitar manualmente as atualizações automáticas também para as versões principais (mais sobre isso em um segundo).

Infelizmente, esta tarefa crucial de manutenção ainda pode ser um pouco confusa para os usuários não tecnológicos. Você pode ler mais sobre como as atualizações automáticas funcionam em nosso blog Um Mergulho Profundo nas Atualizações Automáticas do WordPress.

Assim, o WordPress 5.6 introduz uma nova interface que permite aos administradores do site habilitar atualizações automáticas para as principais versões do núcleo.

O escopo deste recurso mudou durante o ciclo beta do WordPress 5.6 e a nota de desenvolvimento original foi substituída. Nas palavras de Jb Audras,

O escopo inicial das atualizações automáticas do Core passou para:

Fornecer algumas atualizações sobre o projeto da IU.

Para instalações existentes, o comportamento continuará o mesmo de hoje: optou-se por atualizações menores por padrão, mas o usuário deve optar por atualizações maiores (constantes e filtros que já estão em uso por hosts ou agências continuarão a ter precedência).

Para novas instalações, o comportamento padrão mudará: optou-se por atualizações menores por padrão e optou-se por atualizações maiores por padrão.

A partir do WordPress 5.6, você pode optar por atualizações automáticas para as principais versões principais na tela Updates, onde uma nova IU fornece uma caixa de seleção que permite habilitar atualizações automáticas para todas as novas versões do WordPress.

Permitir atualizações automáticas para todas as novas versões do WordPress

Uma vez que você tenha ativado as atualizações automáticas do núcleo para as principais versões, você pode então habilitá-las para a manutenção e segurança apenas clicando em Mudar para atualizações automáticas apenas para as versões de manutenção e segurança.

Mudar para atualizações automáticas apenas para manutenção e liberações de segurança

Principais atualizações automáticas do núcleo para desenvolvedores

Primeiro, quando grandes atualizações automáticas do núcleo principal são ativadas, a opção auto_update_core_major é armazenada no banco de dados com a option_value habilitada. Portanto, se a opção get_site_option( 'auto_update_core_major' ) retornar true, a caixa de seleção de atualizações automáticas é marcada.

Em seguida, o WordPress verifica se as principais atualizações automáticas do núcleo estão habilitadas através da constante WP_AUTO_UPDATE_CORE ou da constante allow_major_auto_core_updates filter e define a caixa de seleção de acordo.

Os desenvolvedores também podem desativar as atualizações automáticas do núcleo principal definindo a constante WP_AUTO_UPDATE_CORE como false ou minor, como mostrado abaixo (veja também Controle de atualizações de fundo através do wp-config.php):

# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );

# Enables minor updates:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Observe que os valores possíveis para WP_AUTO_UPDATE_CORE são true (todos), 'beta', 'rc', 'minor', false.

Outra opção para desativar as principais atualizações automáticas por padrão é usar o novo filtro allow_major_auto_core_updates:

add_filter( 'allow_major_auto_core_updates', '_return_false' );

Alguns comentários sobre a inclusão de atualizações automáticas no Core

Em dezembro de 2018, Matt Mullenweg compartilhou as nove prioridades para 2019 onde “Fornecer uma maneira para os usuários optarem por atualizações automáticas dos principais lançamentos do Core” era o número 7. Talvez um pouco tarde, mas estamos chegando lá.

Grandes atualizações automáticas do núcleo devem ter um grande impacto na segurança do WordPress e na experiência geral. Uma coisa parece estar clara: do ponto de vista técnico, a principal característica das atualizações automáticas do núcleo é uma tarefa complexa que não é 100% realizada com o lançamento do WordPress 5.6.

Depois de uma discussão ponderada sobre Slack, Josepha Haden resumiu as preocupações e perguntas vindas dos colaboradores do Core.

O principal objetivo a longo prazo é ter atualizações automáticas disponíveis na maioria dos sites WordPress para melhorar a segurança em todo o ecossistema WordPress (mais de 30% da web).

De qualquer forma, de acordo com Helen Hou-Sandí, Desenvolvedora Principal:

Em minha mente há algumas coisas técnicas muito difíceis de executar e isso precisa de alguma MUITO disciplinado e focado na propriedade técnica do produto

Portanto, devemos ver mudanças e melhorias adicionais na principal UI de atualizações automáticas ao longo do tempo. Isto é o que podemos esperar de agora em diante:

WordPress 5.6:

Em instalações existentes, grandes atualizações devem ser ativadas pelo usuário. Qualquer constante e filtro já em uso terá precedência. Atualizações menores são ativadas por padrão.
Em novas instalações, tanto as atualizações menores quanto as maiores são ativadas por padrão.

WordPress 5.6.1:

Devemos ver algumas mudanças na interface principal de atualização automática com base no feedback.

WordPress 5.7:

Um empurrão deve ser adicionado à tela de Saúde do Site para qualquer pessoa que opte por sair das principais atualizações automáticas.
Um opt-in de atualização automática deve ser adicionado ao processo de instalação no WordPress 5.7.

Uma grande preocupação com as principais atualizações automáticas é a confiança dos usuários. De acordo com Helen:

Acredito que ainda podemos fazer muito trabalho para solicitar proativamente a confiança dos usuários, especialmente aqueles que tiveram experiências anteriores ruins com WordPress e/ou atualizações

Entretanto, cada site WordPress é uma mistura de Core, plugins e tema. Nas palavras de Helen:

As atualizações principais são bastante seguras e há algumas proteções embutidas, mas como os sites podem executar qualquer código de qualquer fonte, não há “100%” para “todo tipo de site WordPress”.

Os usuários com as principais atualizações automáticas habilitadas devem fazer backups regulares do seu site ou escolher um servidor web que forneça backups automáticos em seus planos.

As principais atualizações automáticas também afetarão a experiência geral de atualização, incluindo as atualizações automáticas plugin e temáticas. Joost de Valk observou em um comentário:

Se ativarmos as atualizações automáticas do núcleo do WordPress por padrão, devemos fazer o mesmo para os plugins. Caso contrário, os plugins e temas não podem ser atualizados para coisas que precisam ser corrigidas por causa das atualizações do núcleo. Acho que os usuários também esperariam isto: se as atualizações automáticas do WordPress, os plugins e os temas devem ser autoatualizados também.

Mudanças na saúde do site em WordPress 5.6

Além de todas as características aqui discutidas, o WordPress 5.6 também traz uma versão melhorada da ferramenta Site Health, que agora se comporta de forma diferente em segundo plano.

Validação dos dados do Site Health Check

Um validador agora verifica as respostas aos testes de saúde do site. O validador descartará qualquer resposta inválida, impedindo que a ferramenta Site Health cause erros fatais e interrompendo qualquer outro controle.

De agora em diante, as respostas inválidas não afetarão o indicador de saúde do site (#50145).

Verificações assíncronas via REST Endpoind

A ferramenta Site Health é uma poderosa ferramenta de segurança que permite que os proprietários de sites estejam cientes do status de saúde do seu site.

Esta ferramenta executa uma série de testes de segurança que fornecem uma visão geral do estado de saúde do seu site.

Estes testes se encaixam em duas categorias: testes diretos, executados em carga de página, e testes assimétricos, que podem exigir algum tempo para serem concluídos, e serão executados posteriormente via chamadas JavaScript.

Anteriormente, estes testes eram executados com uma chamada para admin-ajax.php. Com o WordPress 5.6, as coisas estão se afastando de admin-ajax.php e um novo endpoint REST API será usado em seu lugar. A partir do WordPress 5.6, testes assíncronos podem ser encontrados no namespace /wp-json/wp-site-health/v1.

Graças ao novo aprimoramento REST API, plugins e temas também são capazes de fazer uso dos pontos finais REST e não estão limitados a ações Ajax para seus testes de saúde.

Cada teste assíncrono pode agora declarar o argumento has_rest, que por defeito é false.

O código abaixo de wp-admin/includes/class-wp-site-health.php mostra o conjunto de testes assíncronos no WordPress 5.6:

'async'  => array(
	'dotorg_communication' => array(
		'label'             => __( 'Communication with WordPress.org' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/dotorg-communication' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_dotorg_communication' ),
	),
	'background_updates'   => array(
		'label'             => __( 'Background updates' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/background-updates' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_background_updates' ),
	),
	'loopback_requests'    => array(
		'label'             => __( 'Loopback request' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/loopback-requests' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_loopback_requests' ),
	),
	'authorization_header' => array(
		'label'     => __( 'Authorization header' ),
		'test'      => rest_url( 'wp-site-health/v1/tests/authorization-header' ),
		'has_rest'  => true,
		'headers'   => array( 'Authorization' => 'Basic ' . base64_encode( 'user:pwd' ) ),
		'skip_cron' => true,
	),
),

Verificações programadas da saúde do site:

Embora testes assíncronos tenham sido implementados para evitar a lentidão das páginas e o timeout, tal preocupação não existe com testes programados.

Com isso em mente, além do argumento has_rest que mencionamos acima, as matrizes de teste também podem declarar o argumento async_direct_test (usando o código acima), que deve ser uma instância chamável de teste.

Se um teste for executado durante um evento programado, o teste não utilizará o ponto final REST API, mas será executado diretamente.

Senhas de Aplicativos para Autenticação REST API

Application Passwords é um novo sistema para fazer pedidos autenticados a várias APIs do WordPress.

As senhas têm 24 caracteres e consistem em letras maiúsculas, minúsculas e numéricas, que podem ser geradas manualmente ou através do REST API.

Para gerar manualmente uma nova senha de aplicação, navegue até sua tela de Perfil e desça a página.

Senhas de aplicação na tela Perfil do usuário

Escolha um nome para sua senha de aplicação e confirme. O WordPress exibirá sua nova senha.

As senhas de aplicação são exibidas em pedaços de 4 caracteres, separados por espaços, como mostrado abaixo:

gsUc UhkU 0ScI gdRd TGoU vrW5

Entretanto, as senhas podem ser usadas como u sem espaços:

As senhas de aplicação passadas de volta pelo fluxo de autorização não incluem espaços. Elas estão estritamente lá para facilitar que alguém que olha para um fio longo mantenha seu lugar se entrar manualmente nele.

Eles podem ser usados em pedaços, sem espaços, ou – se você quiser, você provavelmente poderia adicionar um espaço após cada personagem.

Na tela Perfil do usuário, você pode visualizar, criar e revogar senhas de aplicação. As colunas Last Used e Last IP fazem com que você descubra facilmente as senhas não mais utilizadas que devem ser revogadas.

No momento desta redação, as Senhas de Aplicação podem ser usadas com solicitações autenticadas REST API e com o legado XML-RPC API. No entanto, devemos ver Senhas de Aplicação usadas com APIs adicionais no futuro. George Stephanis explica:

O esquema de autenticação de senhas de aplicação também pode ser aplicado a futuras APIs para WordPress à medida que elas se tornam disponíveis. Por exemplo, se o GraphQL ou outros sistemas estiverem habilitados no WordPress, as senhas de aplicação lhes fornecerão uma infra-estrutura de autenticação sólida e estabelecida para que possam ser construídas fora da caixa.

Uma chamada autenticada para o REST API no carteiro

Não é possível usar senhas de aplicação no wp-login.php.

Para uma visão mais próxima desta característica e mais conhecimentos técnicos, certifique-se de verificar os seguintes recursos:

Melhor suporte para o PHP 8

O PHP 8.0 traz toneladas de novas características e otimizações, tornando-o um verdadeiro marco dentro da evolução da linguagem. A versão mais recente do PHP introduz muitas atualizações que quebram a compatibilidade retroativa e muitas características obsoletas foram agora oficialmente removidas. Portanto, adicionar suporte ao PHP 8 no WordPress é um grande desafio.

Na verdade, mesmo que os colaboradores do WordPress Core se esforcem muito para tornar o WordPress 5.6 compatível com o PHP 8, não devemos esperar que todos os possíveis problemas sejam descobertos. O objetivo aqui é atingir um ponto onde todo o ecossistema WordPress seja compatível com o PHP 8, o que parece ser realmente um osso duro de roer no momento.

Além disso, um site WordPress inclui pelo menos um tema e um número variável de plugins. Portanto, o que podemos esperar é um bom suporte ao PHP 8 no WordPress Core, mas é difícil acreditar que plugins e temas rapidamente adicionariam suporte ao PHP 8.

Concordamos com Jonathan Desrosiers quando ele afirma:

O estado do suporte do PHP 8 dentro do ecossistema mais amplo (plugins, temas, etc.) é impossível de saber. Por essa razão, o WordPress 5.6 deve ser considerado “beta compatível” com o PHP 8.

“Beta compatível com PHP 8” parece uma boa expressão para representar um processo contínuo que ainda requer muito esforço, mas ao mesmo tempo reconhece o grande trabalho feito até agora.

No entanto,

Todos os desenvolvedores de plugins e temas, assim como as comunidades de hospedagem, são chamados a tornar seu código compatível com o PHP 8. Isto permitirá que o WordPress alcance uma verdadeira “compatibilidade total” mais cedo, e sem que os usuários finais tenham que carregar o fardo.

Algumas mudanças no PHP 8 para estar atento

Como mencionamos acima, tornar o WordPress totalmente compatível com o PHP 8 é um trabalho em andamento. Jonathan Desrosiers fornece uma lista de características do PHP 8 e as mudanças que os desenvolvedores do WordPress devem estar cientes disso.

Parâmetros Nomeados

Com o nome PHP é agora possível passar argumentos para uma função baseada no nome do parâmetro, ao invés da posição do parâmetro. Isto permite escrever código que é autodocumentado, os argumentos são independentes de ordem e os valores padrão podem ser arbitrariamente ignorados.

Infelizmente, os parâmetros nomeados atualmente podem causar problemas de retrocompatibilidade no WordPress. A principal razão é que os nomes dos parâmetros estão sujeitos a alterações sem aviso prévio até que a auditoria atual seja concluída. Portanto, no momento desta redação:

O uso de parâmetros nomeados ao chamar funções do WordPress e métodos de classe não é explicitamente suportado e altamente desencorajado até que esta auditoria possa ser concluída, pois durante a auditoria, os nomes dos parâmetros estão sujeitos a alterações sem aviso prévio. Quando esta auditoria for concluída, ela será anunciada em uma futura nota do desenvolvedor.

Validações rigorosas de tipo/valor para funções internas

Ao passar um parâmetro de tipo ilegal, as funções internas e definidas pelo usuário se comportam de forma diferente. As funções definidas pelo usuário lançam um TypeError, mas as funções internas se comportam de várias maneiras, dependendo de várias condições.

Para remover estas inconsistências, no PHP 8 os parâmetros internos que analisam APIs sempre geram um ThrowError no caso de um desajuste do tipo de parâmetro.

A declaração de tipo estrito não é utilizada no WordPress Core. No entanto, os colaboradores do Core estão trabalhando para evitar que tipos inválidos sejam passados para as funções do Core. Até que esse trabalho seja concluído, essa mudança do PHP 8 pode levar ao TypeErrors, “especialmente se o tipo de um valor for incorretamente alterado através de código engatado a um filtro”.

Verificações mais rígidas para operadores aritméticos e bitwise

Nas versões anteriores do PHP, o uso de operadores aritméticos e bitwise a um array, recurso ou objeto não sobrecarregado era permitido, mas o comportamento era inconsistente e até mesmo irracional às vezes:

var_dump([] % [42]);
// int(0)

Com o PHP 8, o comportamento é sempre o mesmo e todos os operadores aritméticos e bitwise lançarão uma exceção TypeError quando o operando for um array, recurso ou objeto não sobrecarregado (ver o RFC).

Esta é outra mudança que requer algum trabalho extra dos colaboradores do Core, como os muitos erros, avisos e mudanças de aviso.

Novamente, devido às várias questões ainda não resolvidas, é altamente recomendável executar testes de compatibilidade em um ambiente de encenação ou desenvolvimento antes de fazer a mudança para o PHP 8 em seu website ao vivo. Leia mais sobre o WordPress e o PHP 8.0.

Mudanças adicionais para os desenvolvedores

O WordPress 5.6 introduz toneladas de mudanças para os desenvolvedores e não pudemos incluir tudo em nossa lista. Mas aqui vale a pena ver os três primeiros:

1. wp_after_insert_post Action Hook

Antes do WordPress 5.6 você poderia usar o save_posts ou ações similares para executar código personalizado após a publicação de um post. Agora o WordPress 5.6 introduz o novo gancho de ação wp_after_insert_post, que dispara apenas uma vez que os termos e metadados tenham sido salvos.

Além disso, várias funções foram atualizadas para evitar que esses ganchos sejam demitidos. O novo parâmetro $fire_after_hooks foi adicionado às funções wp_insert_posts(), wp_update_post() e wp_insert_attachment(). Se ajustado para false, ele evita que os ganchos de pós-introdução sejam disparados.

Confira a nota de desenvolvimento para uma visão mais profunda.

2. Tipecasting

As funções de digitação intval(), strval(), floatval() e boolval() foram removidas do Core em favor da digitação direta:

intval() → (int)
strval() → (string)
floatval() → (float)

Esta mudança tem efeitos diretos no desempenho, já que a digitação direta é ~6x mais rápida do que as funções de digitação.

3. WP_Error Objetos

A classe WP_Error foi aprimorada para permitir a fusão de múltiplas instâncias WP_Error em uma só. Anteriormente, você só podia fazer isso manualmente. Agora, o WordPress 5.6 introduz três novos métodos para ajudar a lidar com múltiplas instâncias do WP_Error. O código abaixo é um exemplo a partir da nota de desenvolvimento:

<?php
$error_1 = new WP_Error(
	'code1',
	'This is my first error message.',
	'Error_Data'
);
 
$error_2 = new WP_Error(
	'code2',
	'This is my second error message.',
	'Error_Data2'
);
 
// Merge from another WP_Error.
$error_1->merge_from( $error_2 );
 
// Retrieve all error data, optionally for a specific error code.
$error_1->get_all_error_data( 'code2' );
 
// Export to another WP_Error
$error_1->export_to( $error_2 );

Leituras adicionais para os desenvolvedores

É impossível mencionar todas as mudanças focadas no desenvolvimento introduzidas pelo WordPress 5.6, mas você pode ler mais sobre elas usando os seguintes recursos:

Resumo

O WordPress 5.6 é um grande lançamento com toneladas de recursos e mudanças tanto para usuários quanto para desenvolvedores. Estamos sempre animados em ver como a evolução das tecnologias web afeta diretamente a segurança, o desempenho, a usabilidade e a acessibilidade do WordPress.

Mas a evolução nunca pára e já podemos dar uma olhada em datas futuras de lançamento potencial.

Até você agora: O que você mais gosta no WordPress 5.6? E quais características você gostaria que fossem adicionadas ao WordPress 5.7?

Carlo Daniele Kinsta

Carlo é um apaixonado por webdesign e desenvolvimento frontend. Ele tem mais de 10 anos de experiência com WordPress e colaborou com diversas universidades e instituições educacionais na Itália e na Europa. Carlo já publicou inúmeros artigos e guias sobre WordPress, tanto em sites italianos quanto internacionais, além de revistas impressas. Você pode seguir ele no LinkedIn e no X.

Site
Twitter