Novidades do WordPress 7.1: processamento de mídia no lado do cliente, ferramentas de design, Abilities API e muito mais

O lançamento do WordPress 7.1 está previsto para 19 de agosto e promete ser uma atualização empolgante para desenvolvedores, profissionais, agências e blogueiros de todo o ecossistema.

Esta segunda grande versão do ano apresenta uma ampla variedade de atualizações que abrangem praticamente todos os aspectos do CMS. Entre as novas funcionalidades, o Processamento de mídia no lado do cliente é o que mais nos empolga. Isso porque, aqui na Kinsta, somos obcecados por desempenho web e velocidade dos sites, e essa nova arquitetura de mídia representa um avanço significativo, proporcionando melhorias perceptíveis na eficiência do servidor e tempos de carregamento de página mais rápidos.

Além do gerenciamento de mídia, o WordPress 7.1 traz melhorias significativas para a colaboração em equipe, incluindo novas funcionalidades para as Notas, além de vários aprimoramentos na interface do painel de controle, como uma barra de administração persistente e a nova tela Identidade no Editor do Site. A versão também inclui blocos novos e aprimorados, ferramentas de design ampliadas e uma grande variedade de atualizações para desenvolvedores.

Quer descobrir o que vem por aí? Vamos conhecer o WordPress 7.1.

Processamento de mídia no lado do cliente

Até o WordPress 7.0, a geração de dimensões de imagens e miniaturas para exibição no frontend, a conversão de formatos e o gerenciamento da rotação de imagens eram realizados no lado do servidor por meio do PHP.

Agora, o WordPress 7.1 introduz uma nova arquitetura de processamento de mídia: o redimensionamento de imagens, a conversão de formatos, a rotação EXIF e a geração de miniaturas passam a ocorrer no lado do cliente, diretamente no navegador do usuário.

Essa mudança deve melhorar significativamente o desempenho do site e reduzir o consumo de recursos do servidor.

Vamos analisar mais detalhadamente o que muda no processamento de imagens:

1. O que é o Processamento de mídia no lado do cliente?

Anteriormente, as imagens eram processadas no servidor pelo PHP usando as bibliotecas GD ou Imagick. Agora, a geração de imagens em vários tamanhos, a conversão de formatos e a rotação EXIF ocorrem diretamente no navegador do usuário, desde que o navegador ofereça suporte ao header Document-Isolation-Policy (DIP) para conceder acesso ao SharedArrayBuffer.

Como o processamento ocorre no navegador, o WordPress não recebe mais apenas uma única imagem, mas todos os arquivos de imagem resultantes do processo. Isso tem dois efeitos principais: menor uso de CPU e RAM do servidor e um número maior de solicitações HTTP para enviar individualmente as miniaturas.

No momento da publicação deste artigo, apenas o Chrome 137+ e o Microsoft Edge 137+ (desktop) oferecem suporte completo ao Document-Isolation-Policy. O Safari e o Firefox não oferecem suporte ao processamento com WASM, embora o Safari ofereça suporte à decodificação nativa dos formatos HEIC/HEIF para JPG.

2. Quais são os recursos técnicos do Processamento de mídia no lado do cliente?

Do ponto de vista da arquitetura, o Processamento de mídia no lado do cliente é gerenciado por 3 pacotes principais:

• O novo pacote @wordpress/vips gerencia o processamento no lado do cliente usando a biblioteca libvips compilada em WebAssembly (wasm-vips). Amplamente considerada uma das bibliotecas de processamento de imagens mais rápidas e eficientes disponíveis, ela é executada em paralelo dentro de um Web Worker, evitando que a interface do usuário fique travada e proporcionando um desempenho significativamente melhor do que JavaScript puro.
• O pacote @wordpress/upload-media coordena o processo de upload, incluindo o gerenciamento de filas de upload, uploads simultâneos (até 5 uploads simultâneos e 2 operações de processamento de imagens), novas tentativas automáticas, retomada de uploads interrompidos e suporte off-line.
• O pacote @wordpress/media-utils gerencia o transporte HTTP e as solicitações da REST API.

Além do processamento de imagens, essa nova funcionalidade introduz a conversão automática de GIFs animados em vídeos MP4/WebM. A conversão é realizada pelo novo pacote @wordpress/video-conversion, que encapsula a biblioteca mediabunny em um Web Worker para converter GIFs opacos (sem fundos transparentes) em arquivos de vídeo mais leves.

O Processamento de mídia no lado do cliente também introduz novos endpoints da REST API (sideload, finalize e replace_file), além de 2 novos parâmetros: generate_sub_sizes e convert_format.

3. Quais são os benefícios para os usuários do WordPress?

O Processamento de mídia no lado do cliente transfere o processamento de imagens do servidor para o cliente. Isso libera o servidor da carga pesada de gerar miniaturas em várias dimensões, girar imagens e converter formatos, transferindo esse trabalho diretamente para o navegador do usuário.

Veja alguns dos benefícios de transferir o processamento de mídia para o cliente:

• Menos erros de falta de memória no PHP: O Processamento de mídia no lado do cliente elimina erros de esgotamento de memória (PHP memory limit exceeded) que anteriormente ocorriam durante o processamento de arquivos de imagem grandes.
• Menor consumo de CPU e RAM: Outro grande benefício para o servidor é a redução significativa no uso de CPU e RAM do provedor de hospedagem, liberando recursos para outras tarefas.
• Melhor desempenho do site: A biblioteca libvips usa algoritmos avançados de compressão que produzem imagens, em média, ~15% menores do que as geradas pelo GD ou Imagick. Isso resulta em imagens mais leves e tempos de carregamento de página mais rápidos.
• Maior resiliência nos uploads: Cada upload de imagem requer uma solicitação HTTP independente. Isso resulta em um volume maior de solicitações HTTP, mas garante que cada imagem seja processada de forma independente. Solicitações que falham são pausadas e repetidas automaticamente.

Além disso, GIFs animados podem ser convertidos automaticamente em vídeos com reprodução automática mais eficientes, fotos HEIC enviadas de iPhones podem ser convertidas para JPG pelo navegador antes do upload (evitando possíveis problemas de compatibilidade com o servidor), e o suporte a AVIF agora funciona mesmo sem recursos AVIF no lado do servidor (a verificação do tipo MIME é ignorada para uploads decodificados no lado do cliente).

4. O que muda para os desenvolvedores?

Os desenvolvedores podem desabilitar o processamento de mídia no lado do cliente usando o novo filtro wp_client_side_media_processing_enabled. Veja um exemplo:

add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );

Além disso, não há grandes mudanças que afetem os desenvolvedores de plugins. Os hooks associados ao processamento de mídia continuam sendo acionados como se as imagens fossem processadas no servidor.

Os filtros existentes leem as configurações do servidor e continuam funcionando conforme o esperado. Por exemplo, o filtro wp_generate_attachment_metadata é executado duas vezes: primeiro durante o upload inicial (create) e depois novamente após a chamada do endpoint de finalização (update). Os plugins que usam esse filtro continuarão funcionando conforme o esperado.

Para desenvolvedores de temas, os tamanhos de imagem registrados por meio de add_image_size() agora são gerados no lado do cliente. Se um tema definir um tamanho de imagem com dimensões idênticas às de um tamanho padrão do WordPress, as imagens serão “desduplicadas” em um único arquivo de imagem registrado com os dois nomes de tamanho.

5. Quais são os benefícios para a segurança?

Embora o Processamento de mídia no lado do cliente tenha sido desenvolvido principalmente para melhorar o desempenho e a eficiência, e não a segurança, ele oferece várias vantagens que aumentam a segurança dos sites WordPress.

Primeiro, ele reduz a superfície de ataque. Como mencionado anteriormente, antes do WordPress 7.1, o processamento de imagens dependia de bibliotecas executadas no servidor, como GD e Imagick. Ao longo do tempo, essas bibliotecas foram afetadas por diversas vulnerabilidades de segurança relacionadas à decodificação de imagens.

Com o processamento de imagens no lado do cliente, o servidor não precisa mais do GD ou Imagick, pois recebe imagens já processadas. Isso reduz significativamente a quantidade de código sensível executado no servidor.

Outra vantagem de segurança é que o processamento de imagens ocorre em um ambiente isolado do navegador, usando WebAssembly em um Web Worker.

O processamento no lado do cliente também reduz o risco de ataques de negação de serviço (DoS), pois a carga computacional fica no cliente.

Para processar imagens no cliente, o WordPress utiliza o SharedArrayBuffer, um objeto JavaScript que permite que a thread principal e os Web Workers compartilhem o mesmo espaço de memória.

Para conceder acesso ao SharedArrayBuffer, o WordPress habilita o header Document-Isolation-Policy: isolate-and-credentialless. Isso fornece um contexto de execução isolado para o Editor de Blocos em navegadores Chromium 137+ (Chrome 137+ e Edge 137+).

Em resumo, embora o principal objetivo do Processamento de mídia no lado do cliente seja melhorar o desempenho e a eficiência no gerenciamento de mídia, essa nova funcionalidade também traz melhorias significativas de segurança.

6. Recursos oficiais

O Processamento de mídia no lado do cliente foi amplamente documentado tanto para usuários quanto para desenvolvedores. Consulte os seguintes recursos para obter mais detalhes:

• Processamento de mídia no lado do cliente no WordPress 7.1 (nota para desenvolvedores)
• Arquitetura do Processamento de mídia no lado do cliente (Manual do Editor de Blocos)
• Processamento de mídia no lado do cliente (Guias práticos)
• Filtros e parâmetros do processamento de mídia no lado do cliente (Referência de hooks)

Melhorias nas Notas

Introduzidas pela primeira vez no WordPress 6.9, as Notas receberam várias adições e melhorias que as tornam uma ferramenta de colaboração mais completa.

Para começar, o WordPress 7.1 adiciona suporte a rich text nas Notas, tornando-as “mais expressivas, mais claras de ler e mais alinhadas às expectativas dos usuários em relação a ferramentas como Google Docs, Figma, GitHub e outros editores colaborativos”.

Isso inclui formatação inline básica, como negrito (Ctrl/⌘ + B), itálico (Ctrl/⌘ + I), links (Ctrl/⌘ + K) e emojis.

Agora você pode adicionar notas inline selecionando trechos de texto, em vez de apenas um bloco inteiro (comentários inline em blocos). Também é possível adicionar várias notas ao mesmo bloco ou à mesma seleção de texto.

O WordPress 7.1 também introduz as @menções para marcar seus colaboradores nas notas, tornando a funcionalidade Notas mais semelhante às ferramentas de colaboração populares. Ao digitar o caractere @, um painel é exibido com uma lista dos usuários do seu site para facilitar a seleção. O destinatário da menção receberá uma notificação por e-mail com um link para a publicação.

Outra novidade diz respeito à parte visível das notas. Agora, as notas longas são recolhidas por padrão para não ocuparem muito espaço na tela. Um botão de alternância Mostrar mais/Mostrar menos permite exibir ou ocultar o texto completo.

Você pode conferir a lista completa de novas funcionalidades das Notas que chegam com o WordPress 7.1 em Iteração das Notas para o WordPress 7.1.

Melhorias na interface de administração

A interface de administração recebeu várias atualizações que melhoram a consistência da interface e simplificam a navegação entre as telas.

Barra de administração persistente no editor de posts e no Editor do Site

Antes do WordPress 7.1, a barra de administração não era exibida no editor de posts nem no Editor do Site. Esse comportamento era inconsistente, pois a barra de ferramentas de administração é o elemento mais utilizado da interface de administração, e sua ausência nos editores não era considerada ideal. A partir do WordPress 7.1, esse comportamento muda, e a barra de ferramentas de administração passa a ficar visível no editor de posts e no Editor do Site.

Esquema de cores do usuário estendido ao Editor do Site

Outra melhoria destinada a tornar a aparência de todas as áreas de administração mais consistente é aplicar também ao Editor do Site o mesmo esquema de cores definido pelo usuário em sua página de configurações. Antes da versão 7.1, a barra lateral do Editor do Site era sempre preta.

A barra de ferramentas do editor também recebe uma atualização no WordPress 7.1. O ícone do site foi removido da barra de ferramentas do editor e agora aparece na barra de ferramentas do WordPress.

Nas versões anteriores, para voltar à administração do WordPress, era necessário clicar no ícone do site, que tecnicamente não era um botão de voltar.

Como resultado, o ícone do site agora aparece apenas na barra de ferramentas de administração, enquanto um botão de voltar mais claro aparece na barra de ferramentas do editor.

Categorias de comandos e melhorias na interface da paleta de comandos

A paleta de comandos recebeu várias adições e modificações para melhorar sua usabilidade. Primeiro, os comandos disponíveis foram divididos em seções (recentes, sugestões e resultados) para facilitar sua localização.

O modal foi redimensionado (512px), e agora os comandos estão mais fáceis de ler.

Tela Identidade no Editor do Site

Um novo item Identidade agora aparece no menu Design do Editor do Site. A tela correspondente permite configurar o título, slogan, logo e ícone do seu site. Isso permite editar as configurações de identidade do site sem sair do Editor do Site.

Rolagem infinita na visualização em grade da Biblioteca de Mídia

Até o WordPress 7.0, era possível habilitar a rolagem infinita na visualização em grade da Biblioteca de Mídia por meio do filtro media_library_infinite_scrolling, definido como false por padrão. Os desenvolvedores podiam alterar a configuração padrão adicionando a seguinte linha aos seus plugins:

add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );

A partir do WordPress 7.1, o filtro media_library_infinite_scrolling é definido como true, o que significa que a rolagem infinita na visualização em grade da Biblioteca de Mídia fica habilitada por padrão para todos os usuários.

Além disso, uma nova configuração na página de perfil do usuário na administração do WordPress permite definir suas preferências de rolagem infinita.

O WordPress armazena a escolha do usuário nas opções do usuário usando a meta key infinite_scrolling. Você pode recuperar a preferência do usuário desta forma:

$infinite_scrolling = get_user_option( 'infinite_scrolling', $user_id );

Blocos nativos e melhorias nos blocos

O WordPress 7.1 introduz dois novos blocos e várias melhorias nos blocos existentes.

Novos blocos Playlist e Abas

Um novo bloco Playlist permite incorporar uma playlist simples ao seu conteúdo.

Os usuários podem personalizar vários aspectos da aparência do bloco, incluindo tipografia, plano de fundo, dimensões, borda e elementos. Os controles de estilo específicos desse bloco incluem Forma de onda e botão Reproduzir e Plano de fundo da forma de onda. O controle Forma permite alterar a visualização da forma de onda do áudio.

O bloco Playlist oferece suporte a todos os arquivos de áudio compatíveis com sua instalação do WordPress. Se você adicionar suporte a um novo tipo MIME, o bloco o herdará automaticamente.

O novo bloco Abas nativo foi desenvolvido para organizar o conteúdo em abas. Cada aba pode conter qualquer bloco, o que o torna particularmente útil para apresentar conteúdo categorizado por tópico, FAQs ou comparações de produtos e serviços.

Blocos editáveis dentro do bloco HTML personalizado

O bloco HTML personalizado recebeu uma nova melhoria. Agora você pode adicionar blocos editáveis diretamente dentro do código HTML. Isso permite combinar HTML estático e blocos editáveis no mesmo trecho de código.

Embora possam ser editados, os blocos editáveis não podem ser movidos nem removidos, e também não é possível adicionar outros blocos pelo editor visual. No entanto, o código subjacente continua totalmente editável no editor de código.

Antes do WordPress 7.1, seu conteúdo precisava ser composto inteiramente por HTML estático ou inteiramente por blocos. Agora você pode combinar livremente HTML e blocos, o que é particularmente útil ao gerar conteúdo usando modelos de IA.

Essa mudança vem acompanhada da possibilidade de adicionar código HTML estático às variações de blocos. Graças ao novo suporte a innerContent, você pode registrar uma variação do bloco HTML personalizado conforme mostrado no exemplo abaixo:

wp.blocks.registerBlockVariation( 'core/html', {
	name: 'custom-image-card',
	title: 'Custom image card',
	description: 'A custom HTML block with static header/footer and an editable image.',
	innerContent: [ 
		'<h2>Static heading</h2>\n', 
		null, 
		'\n<footer>Static footer</footer>' 
	],
	innerBlocks: [ 
		[ 
			'core/image', 
			{ 
				id: 419,
				sizeSlug: 'medium',
				linkDestination: 'none',
				url: 'https://example.com/wp-content/uploads/...',
				alt: ''
			} 
		] 
	],
} );

O valor null em innerContent funciona como um placeholder para o bloco Imagem.

Observe que innerContent está disponível apenas para o bloco HTML personalizado. Aplicá-lo a variações de outros blocos não terá efeito.

Melhorias no sistema de ícones SVG

O WordPress 7.0 introduziu um novo bloco Ícone e uma biblioteca de ícones. Com o WordPress 7.1, o sistema de gerenciamento de ícones recebe uma API pública, permitindo registrar, renderizar e excluir ícones de forma programática, além de recuperá-los por meio da REST API.

Registrar e cancelar o registro de ícones

Para registrar um ícone ou conjunto de ícones, primeiro você precisa registrar uma coleção de ícones conectando a nova função wp_register_icon_collection() à ação init:

function custom_icons_register_icon_collection() {
	wp_register_icon_collection(
		'my-icon-set',
		array(
			'label'       => __( 'My awesome icons', 'my-plugin' ),
			'description' => __( 'My personal set of icons.', 'my-plugin' ),
		)
	);
}
add_action( 'init', 'custom_icons_register_icon_collection' );

Uma coleção tem um nome exclusivo que a diferencia dos ícones nativos e de outros conjuntos de ícones registrados por plugins de terceiros. O nome da coleção deve começar e terminar com uma letra minúscula e pode conter letras minúsculas, números, hífens e underscores.

O segundo argumento da função é um array que contém o rótulo da coleção exibido na biblioteca de ícones e uma descrição opcional.

Para remover uma coleção, use a função wp_unregister_icon_collection(). A remoção de uma coleção exclui automaticamente todos os ícones associados a ela.

Para registrar um ícone individual, use a função wp_register_icon(), conforme mostrado no exemplo a seguir:

wp_register_icon(
	'my-icon-set/motorbike',
	array(
		'label'   => __( 'Motorbike', 'my-plugin' ),
		'content' => '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">...</svg>',
	)
);

No exemplo acima, registramos um ícone usando uma string SVG. Você também pode registrar um ícone diretamente de um arquivo .svg:

wp_register_icon(
	'my-icon-set/motorbike',
	array(
		'label'   => __( 'Motorbike', 'my-plugin' ),
		'file_path' => plugin_dir_path( __FILE__ ) . 'icons/motorbike.svg',
	)
);

É importante observar que o SVG é sanitizado com wp_kses, e atualmente apenas os elementos <svg>, <path> e <polygon> são permitidos. Todos os outros elementos são filtrados, embora a lista de permissões possa ser ampliada para incluir outros elementos e atributos no futuro.

Para excluir um ícone, você pode usar a função wp_unregister_icon().

Atualizações na biblioteca de ícones e no bloco Ícone

A biblioteca de ícones foi atualizada e agora conta com uma barra lateral que exibe a lista de coleções de ícones registradas no site.

O bloco Ícone também foi atualizado. Por padrão, agora o bloco exibe o ícone Informação em vez de um placeholder vazio, como nas versões anteriores. Além disso, dois novos controles na barra de ferramentas do bloco permitem inverter o ícone vertical e horizontalmente.

Novos endpoints da REST API para ícones

Também foram introduzidos novos endpoints somente leitura da REST API para acessar coleções de ícones ou ícones específicos.

Para coleções de ícones, você usará os seguintes endpoints:

GET /wp/v2/icon-collections
GET /wp/v2/icon-collections/<collection>

Para acessar ícones, você usará os seguintes endpoints:

GET /wp/v2/icons - Introduced with WordPress 7.0.
GET /wp/v2/icons/<collection>
GET /wp/v2/icons/<collection>/<name>

Um usuário com a capacidade « edit_posts » deve autenticar as solicitações.

Para uma visão mais detalhada do sistema de ícones no WordPress 7.1, consulte a nota para desenvolvedores.

Novas ferramentas de design

Criadores e editores agora contam com ferramentas de design novas e aprimoradas que permitem estilizar blocos de conteúdo sem precisar recorrer a CSS personalizado.

Suporte a gradientes de fundo

O WordPress 7.1 introduz suporte a background.gradient e um novo controle na interface de administração para gradientes de fundo.

Na barra lateral de configurações do bloco, um novo painel Plano de fundo, com controles separados para Imagem, Cor e Gradiente, permite experimentar diferentes combinações de imagens, cores e gradientes de fundo, evitando conflitos.

No WordPress 7.1, o suporte a background.gradient é habilitado por padrão para os blocos Grupo, Acordeão, Citação destacada, Conteúdo do post e Citação. Desenvolvedores de temas podem adicionar suporte a background.gradient no block.json adicionando uma propriedade gradient em styles.background ou para cada bloco individualmente, conforme mostrado no código a seguir:

{
	"styles": {
		"background": {
			"gradient": "linear-gradient( 135deg, #1e3c72 0%, #2a5298 100% )"
		},
		"blocks": {
			"core/group": {
				"background": {
					"gradient": "linear-gradient( 135deg, #f5f7fa 0%, #c3cf8d 100% )"
				}
			}
		}
	}
}

Suporte à largura mínima

Outra novidade do WordPress 7.1 que designers e desenvolvedores de temas vão apreciar é o suporte à dimensão minWidth. Ela se junta ao suporte existente para height, minHeight e width, completando o conjunto de ferramentas de design para dimensões.

Desenvolvedores de temas podem adicionar suporte à largura mínima por meio do theme.json, habilitando as Ferramentas de aparência ou adicionando o campo dimensions.minWidth em settings:

{
	"settings": {
		"dimensions": {
			"minWidth": true
		}
	}
}

Você também pode adicionar suporte à largura mínima globalmente ou para cada bloco individualmente:

{
	"styles": {
		"dimensions": {
			"minWidth": "400px"
		},
		"blocks": {
			"core/group": {
				"dimensions": {
					"minWidth": "400px"
				}
			}
		}
	}
}

Desenvolvedores de blocos também podem adicionar suporte a minWidth no block.json:

{
	"supports": {
		"dimensions": {
			"minWidth": true
		}
	}
}

O controle fica oculto por padrão na barra lateral, mas você pode alterar a configuração padrão usando __experimentalDefaultControls. Nos Estilos Globais, o controle fica visível por padrão.

Suporte a sombra de texto nos Estilos Globais

O WordPress 7.1 introduz suporte a text-shadow nos Estilos Globais. Anteriormente, era necessário usar um plugin ou recorrer a CSS personalizado.

Observe que esta é uma implementação inicial. Algumas decisões importantes ainda estão pendentes, como qual controle da interface será usado para personalizar sombras de texto no editor e se text-shadow deverá estar disponível como uma predefinição. Por enquanto, só é possível definir text-shadow no seu theme.json de uma das seguintes maneiras:

{
	"$schema": "https://schemas.wp.org/wp/6.7/theme.json",
	"version": 3,
	"settings": {},
	"styles": {
		"typography": {
			"textShadow": "1px 1px 2em white, 0 0 2em yellow, 0 0 0.2em red;"
		},
		"blocks": {
			"core/paragraph": {
				"typography": {
					"textShadow": "1px 1px 2px red, 0 0 1em red, 0 0 0.2em red"
				}
			}
		},
		"elements": {
			"h2": {
				"typography": {
					"fontSize": "var:preset|font-size|x-large",
					"textShadow": "1px 1px 2em white, 0 0 2em yellow, 0 0 0.2em red;"
				}
			}
		}
	}
}

A imagem a seguir mostra o resultado das definições acima.

Atualizações para desenvolvedores

As atualizações que chegam para desenvolvedores de temas e plugins com o WordPress 7.1 são significativas. Entre as diversas adições e melhorias, as que mais se destacam são as relacionadas à Abilities API e à personalização do sistema de design.

Personalização do sistema de design

O WordPress 7.1 introduz um novo sistema de design que desenvolvedores de plugins podem usar para personalizar o estilo dos elementos da interface de administração. O novo sistema é composto por duas partes: Design tokens e um novo componente React ThemeProvider.

Design tokens

Os design tokens do WordPress são propriedades CSS personalizadas que seguem um padrão estabelecido. Este, por exemplo, é o padrão para a família de tokens Color:

--wpds-color-<property>-<target>-<tone>[-<emphasis>][-<state>]

Com base no padrão acima, a variável a seguir define a cor de fundo para superfícies com ênfase normal:

--wpds-color-background-surface-neutral-strong

A partir do WordPress 7.1, os design tokens podem ser usados por qualquer plugin que gere elementos da interface de administração graças a uma nova folha de estilos wp-theme, que inclui um conjunto completo de design tokens semânticos e está disponível como dependência para plugins. Você pode enfileirar uma folha de estilos personalizada que usa wp-theme, conforme mostrado abaixo:

function myplugin_enqueue_admin_assets( $hook_suffix ) {
	wp_enqueue_style(
		'myplugin-admin-style',
		plugin_dir_url( __FILE__ ) . 'assets/css/admin.css',
		array( 'wp-theme' ),
		'1.0.0'
	);
}
add_action( 'admin_enqueue_scripts', 'myplugin_enqueue_admin_assets' );

A vantagem dos design tokens é que eles podem substituir valores de propriedades CSS definidos diretamente no código. Veja o exemplo a seguir da nota para desenvolvedores:

.card {
	background-color: var(--wpds-color-background-surface-neutral-strong);
	color: var(--wpds-color-foreground-content-neutral);
	border: var(--wpds-border-width-xs) solid var(--wpds-color-stroke-surface-neutral-weak);
	border-radius: var(--wpds-border-radius-lg);
	padding: var(--wpds-dimension-padding-2xl);
}

Os design tokens podem ser usados em conjunto com o componente ThemeProvider para personalizar a aparência de áreas específicas da página de administração.

ThemeProvider

Você pode substituir os valores padrão dos design tokens fornecidos pela folha de estilos wp-theme envolvendo o conteúdo da área de administração no novo componente React ThemeProvider, conforme mostrado no exemplo da nota para desenvolvedores:

import { ThemeProvider } from '@wordpress/theme';
import { Card } from '@wordpress/ui';

function Application() {
	return (
		<ThemeProvider
			color={
				{
					primary: '#3858e9', 
					background: '#11004d' 
				}
			}
			cornerRadius="pronounced"
		>
			<Card.Root>
				<Card.Content>
					Card content
				</Card.Content>
			</Card.Root>
		</ThemeProvider>
	);
}

A partir de uma cor primária e uma cor de fundo definidas como base, o componente gera automaticamente uma escala de cores harmoniosa e consistente que proporciona contraste acessível entre os elementos da interface.

O ThemeProvider permite que desenvolvedores de plugins expressem a identidade visual de suas marcas em áreas da interface, mantendo a consistência com o estilo geral da interface de administração do WordPress.

Para uma análise mais detalhada, consulte a nota para desenvolvedores e a documentação oficial sobre design tokens e ThemeProvider.

Melhorias na Abilities API

Com o lançamento do WordPress 7.1, a Abilities API recebe várias adições que ampliam sua funcionalidade.

Novo ciclo de execução da Abilities API

Primeiro, o ciclo de execução foi aprimorado com 4 novos filtros que são executados antes, durante e depois da execução de uma ability.

O filtro wp_pre_execute_ability é executado no início de WP_Ability::execute() e é usado para interceptar e interromper antecipadamente a execução de uma ação, antes mesmo que o WordPress comece a processá-la. Se o filtro retornar um valor diferente do valor padrão $pre (um erro, dados ou um booleano), o WordPress interrompe imediatamente a execução, ignora as verificações e retorna esse valor.

Esse filtro possibilita casos de uso interessantes, como desabilitar uma ability durante a manutenção do site, limitar a taxa de solicitações originadas do mesmo IP ou simular a resposta de uma ability (testes unitários).

O filtro wp_ability_normalize_input é executado logo após a aplicação dos valores padrão e antes da validação formal do schema e das verificações de permissão. Ele é usado para preparar ou transformar os dados recebidos antes que sejam validados e processados pela ability. Por exemplo, para adicionar metadados contextuais, normalizar dados antes da validação, enriquecer um prompt de IA ou interromper a execução da ability em caso de erro.

O filtro wp_ability_permission_result permite modificar o resultado das verificações de permissão realizadas antes da execução de uma ability. Você pode usá-lo para adicionar regras de autorização mais granulares, criar um sistema de permissões personalizado ou ignorar permissões em casos específicos.

Observe que esse filtro deve ser usado com cautela:

Os plugins devem ter cuidado especial com esse filtro, pois retornar true pode substituir uma negação do permission_callback original da ability.

O filtro wp_ability_execute_result é executado após o callback de execução da ability e antes da validação da saída, permitindo modificar o resultado final retornado por uma ability. Ele permite transformar a resposta produzida pelo processamento da ability antes que ela seja retornada ao solicitante.

Filtragem e manipulação de abilities

Antes do WordPress 7.1, para filtrar abilities registradas era necessário percorrer manualmente o registro usando array_filter(). A partir do WordPress 7.1, wp_get_abilities() aceita um array opcional de argumentos para filtrar abilities registradas por category, namespace, meta ou uma combinação desses critérios.

O exemplo a seguir mostra como recuperar abilities pertencentes a uma categoria específica:

$abilities = wp_get_abilities(
	array(
		'category' => 'content-generation',
	)
);

Você também pode combinar vários parâmetros:

$abilities = wp_get_abilities(
	array(
		'category'  => 'content-generation',
		'meta'      => array(
			'public' => true,
		),
	)
);

Para uma filtragem mais avançada, a API fornece os parâmetros item_include_callback e result_callback, dois callbacks usados para incluir ou excluir abilities do array e para ordenar ou manipular o conjunto de resultados antes que ele seja retornado.

Junto às atualizações de wp_get_abilities(), o WordPress 7.1 introduz dois novos filtros globais:

• wp_get_abilities_item_include: É executado para cada ability que passa pelos filtros declarativos e pelo item_include_callback. Você pode usar esse filtro para incluir ou excluir abilities específicas em todo o site.
• wp_get_abilities_result: É executado após result_callback. Você pode usá-lo para manipular todo o conjunto de resultados de abilities no site.

Consulte a nota para desenvolvedores para uma visão mais detalhada das atualizações de « wp_get_abilities() » e de seus filtros associados.

Novo sinalizador de exposição pública

O WordPress 7.1 também introduz um novo sinalizador de metadados para indicar que uma ability está disponível para acesso por clientes externos, como a REST API, adaptadores MCP e agentes de IA.

Ao registrar uma ability, agora você pode usar meta.public para permitir que ela seja descoberta e invocada por meio dos endpoints REST de abilities. Anteriormente, era necessário especificar a exposição separadamente para cada canal. Por exemplo, definindo ‘show_in_rest’ => true para tornar uma ability visível via REST.

Outras melhorias na Abilities API

Além das atualizações apresentadas acima, o WordPress 7.1 introduz outras melhorias que abrangem vários aspectos da API.

Dois novos filtros, wp_ability_validate_input e wp_ability_validate_output, permitem que plugins validem dados de entrada e saída usando regras mais complexas do que aquelas que podem ser expressas pelo WordPress JSON Schema. O primeiro filtro é executado depois que os dados de entrada são preparados e passam pela validação inicial do schema. O segundo é executado depois que a ability é executada e antes que o resultado final seja retornado.

A ação wp_ability_invoked é executada no início de WP_Ability::execute() e pode ser usada para rastrear e registrar todas as tentativas de invocar uma ability. Você pode conectar uma função a essa ação para registrar tentativas de acesso a uma ability específica, medir a carga do servidor, configurar contadores de uso diários ou mensais e detectar tentativas de chamadas por força bruta.

No entanto, é preciso ter cuidado:

A ação recebe dados de entrada brutos e não normalizados. Portanto, os plugins devem evitar registrar indiscriminadamente os dados de entrada, pois eles podem conter credenciais, informações pessoais ou outros dados confidenciais.

Mais atualizações para desenvolvedores

As atualizações para desenvolvedores não terminam aqui. O WordPress 7.1 traz um número impressionante de melhorias e adições, oferecendo ferramentas de desenvolvimento novas e mais confiáveis. Com esta nova versão, você também encontrará:

• Quatro novos filtros para configurar as telas do Editor do Site
• Editor de posts sempre em iframe
• Atualizações nos componentes do editor
• jQuery UI atualizado para a versão 1.14.2
• Preparação do JSON Schema para compatibilidade com clientes.
• Agora os usuários podem aplicar estilos a pseudoestados.
• Estilos responsivos de blocos e viewports configuráveis
• Novas funções para renderizar tooltips e informações de ajuda

Hospedagem de última geração para o WordPress de última geração

O WordPress 7.1 representa um grande avanço para o CMS em várias frentes.

O processamento de mídia no lado do cliente representa um ponto de virada no gerenciamento de imagens. Agora, o processamento ocorre no lado do cliente, proporcionando maior eficiência no uso dos recursos do servidor e carregamento mais rápido das páginas.

Quanto aos recursos de IA, após as atualizações revolucionárias das versões 6.9 e 7.0, o WordPress 7.1 marca um momento de consolidação. A Abilities API ganha novas funcionalidades que permitem aos desenvolvedores criar integrações e recursos de IA mais confiáveis e seguros.

Outra adição importante que desenvolvedores e agências vão apreciar é o ThemeProvider, que permite que plugins expressem sua identidade visual na área de administração, mantendo a consistência com a interface do painel do WordPress.

Há também melhorias nas Notas, novos blocos, um sistema de ícones SVG mais avançado e muito mais. Em resumo, o WordPress está longe de desacelerar e está mais voltado para o futuro do que nunca.

Para um CMS cada vez mais avançado, é essencial escolher um provedor de hospedagem que acompanhe as tecnologias modernas. A Kinsta oferece o ambiente ideal para sites WordPress de última geração: infraestrutura de nuvem em contêineres, excelente desempenho, segurança robusta e suporte rápido e altamente avaliado.

Se você ainda não experimentou nossa hospedagem, aproveite o teste gratuito em planos selecionados ou entre em contato conosco para saber mais.