O WordPress 7.2 será a última versão principal de 2026. O cronograma oficial coloca a Beta 1 entre 20 e 22 de outubro e a versão final entre 8 e 10 de dezembro. Em 12 de setembro, portanto, o ciclo ainda está antes da Beta 1: é a fase certa para montar um ambiente descartável, acompanhar o trunk e o Gutenberg recente e descobrir incompatibilidades enquanto o código ainda está mudando. O ponto central é separar duas coisas: testar o que já existe no desenvolvimento e não tratar toda novidade do Gutenberg como recurso garantido do 7.2. O próprio projeto avisa que novas funcionalidades só entram se estiverem suficientemente prontas. Consulte o cronograma oficial do WordPress 7.2 e o resumo de setembro para desenvolvedores.
O que muda quando a Beta 1 chega
Antes da Beta 1, o trunk ainda recebe trabalho de desenvolvimento e pode mudar com frequência. A partir da fase beta, o ciclo passa a concentrar esforços em testes e correções de bugs, enquanto as Dev Notes começam a ser consolidadas. Isso torna as semanas anteriores a 20–22 de outubro especialmente úteis para autores de plugins e temas: um conflito encontrado agora pode revelar uma API em transição, uma depreciação ou uma regressão que ainda pode ser investigada com contexto fresco.
Não use essa fase como justificativa para atualizar produção. O alvo é um ambiente em que seja aceitável quebrar o editor, perder conteúdo de teste, desativar extensões e trocar versões várias vezes.
Monte um ambiente de teste que você possa quebrar
O cenário ideal é um staging, ambiente local ou instância temporária que reproduza a combinação real de tema, plugins críticos, PHP e conteúdo, mas sem dados sensíveis nem tráfego de clientes. Para acompanhar o próximo major, a documentação oficial permite usar o plugin WordPress Beta Tester em “Bleeding edge nightlies” ou atualizar para trunk com WP-CLI. O guia de beta testing também recomenda esse fluxo para quem quer testar antes das versões pré-lançamento.
Para mudanças do editor, o resumo de setembro recomenda executar o WordPress trunk junto com a versão mais recente do Gutenberg ou abrir uma instância no Playground. Isso é útil porque parte do que está sendo preparado para o ciclo 7.2 aparece primeiro no Gutenberg. Preserve, porém, uma segunda instalação sem o plugin Gutenberg para distinguir comportamento do core em trunk de comportamento experimental do plugin.
Matriz mínima de compatibilidade
| Camada | O que testar | Por que importa |
|---|---|---|
| Core | WordPress 7.1 estável e trunk do 7.2 | Comparar o último comportamento estável com o desenvolvimento ajuda a identificar regressões. |
| PHP | A versão usada em produção e pelo menos outra versão suportada pelo seu produto | Evita concluir que um erro é do core quando depende da combinação com PHP. O quadro oficial mostra o WordPress 7.1 compatível com PHP 7.4 a 8.5; confirme novamente a matriz quando a documentação específica do 7.2 for publicada. |
| Editor | Trunk sem Gutenberg e trunk com Gutenberg recente | Separa mudanças já integradas ao core de mudanças ainda experimentais ou em integração. |
| Tema | Seu tema principal e um tema padrão | Ajuda a isolar conflito de tema de regressão do WordPress. |
| Plugins | Sem plugins, plugins críticos isolados e a pilha completa | Mostra qual extensão introduz ou expõe o problema. |
| Navegador | Ao menos os navegadores que você declara suportar | Erros de editor e atalhos podem depender do ambiente do navegador. |
A referência oficial de compatibilidade de PHP está em PHP Compatibility and WordPress Versions. Não antecipe uma alteração de requisito mínimo para o 7.2 sem uma nota oficial.
Plugins: comece pelos pontos que podem quebrar mais
Priorize plugins que alteram o editor, registram blocos, adicionam telas administrativas, modificam REST/AJAX, dependem de pacotes JavaScript do WordPress ou mantêm integrações com tipos de conteúdo e metadados. Rode primeiro os fluxos que sustentam receita, publicação ou operação: criar e editar conteúdo, salvar configurações, processar formulários, executar jobs, autenticar integrações e concluir operações que escrevem no banco.
Entre as mudanças já destacadas no Gutenberg 23.8 e 23.9, há alguns alvos concretos para testes de compatibilidade. Templates de blocos internos estão migrando das props de InnerBlocks para configurações do tipo de bloco; as props antigas ainda funcionam, mas foram marcadas como deprecadas. O pacote DataViews está removendo dependências de APIs privadas, e componentes antes escondidos atrás dessas APIs estão ganhando caminhos públicos. Variações e transformações de blocos também podem declarar atalhos de teclado. Se o seu plugin usa essas áreas, teste não apenas se “abre”, mas se inserção, seleção, transformação, undo/redo, salvamento e recarregamento continuam consistentes.
O mesmo vale para extensões da administração. Os editores passaram a usar o esquema de cores do admin por meio de um ThemeProvider, e existe uma exportação pública para obter essas cores. Plugins que desenham componentes próprios no admin devem verificar contraste, estados de foco e legibilidade em mais de um esquema de cores.
Temas: concentre-se em theme.json, Global Styles e espaçamento
O ciclo recente do Gutenberg trouxe correções de schema para estados responsivos e pseudoestados em theme.json. Também surgiram controles para desativar a edição de estados e de responsividade via configurações do editor, sem remover os estilos já definidos. Para temas que exploram esses recursos, valide três camadas: o que o theme.json declara, o que a interface de Global Styles permite editar e o CSS efetivamente renderizado no front-end.
Outros pontos do Gutenberg 23.8/23.9 merecem regressão: estilização do elemento label, edição de cite, campos de texto e selects em Global Styles, blockGap horizontal e vertical no bloco Group, novos supports em blocos como List, Query No Results e Query Loop, além de ajustes em duotone, sombras e normalização de espaçamento. Não presuma que todos esses itens estarão exatamente iguais no 7.2 final; use-os como roteiro para testar temas e style variations enquanto o ciclo amadurece.
Blocos e editor: teste comportamento, não só aparência
Um bloco pode parecer correto e ainda quebrar na serialização, na seleção ou na reabertura do post. Para cada bloco próprio ou altamente customizado, teste inserção, duplicação, transformação, drag and drop, atalhos, copiar e colar, undo/redo, salvar, recarregar, alternar para visualização de código quando aplicável e renderizar no front-end. Para blocos com InnerBlocks, inclua cenários com template inicial, inserção adicional e conteúdo já existente.
Se o seu plugin estende o Site Editor, acompanhe também o trabalho do Site Editor extensível. O resumo de setembro registra que esse caminho ainda é experimental, mas as diretrizes de contribuição já exigem que novos recursos do Site Editor também funcionem nele. Isso é sinal para preparar testes, não para prometer suporte de produção antes da estabilização.
Hooks, logs e sinais de depreciação
Ative observabilidade no ambiente de teste. Registre erros de PHP, acompanhe o log do WordPress, abra o console do navegador e inspecione falhas de rede. Avisos de função deprecada, propriedades inesperadas, respostas REST diferentes, erros JavaScript e mudanças no momento em que um hook dispara podem ser o primeiro indício de incompatibilidade.
Faça o mesmo fluxo duas vezes: uma na versão estável e outra no trunk. Se o comportamento divergir, reduza a instalação ao menor conjunto possível. Um teste com tema padrão e plugins desativados é a base para saber se você encontrou um problema de core; depois, reative apenas o componente necessário para reproduzir a falha.
Como decidir se vale reportar uma falha
Um bom reporte precisa ser reproduzível. A equipe de Test recomenda registrar ambiente, versão do WordPress e PHP, navegador, tema, plugins, passos exatos, comportamento esperado e resultado observado. O guia de reprodução de issues inclui um modelo e indica o plugin Test Reports para preencher automaticamente parte dos dados de ambiente.
Problemas de WordPress Core normalmente pertencem ao Core Trac; issues do Gutenberg ficam no repositório do Gutenberg no GitHub. Antes de abrir algo novo, procure um ticket existente. Se conseguir reproduzir, acrescente o cenário e os dados do ambiente ao ticket correspondente. A documentação de Test Reports reforça que o melhor lugar para o resultado é o próprio ticket, issue ou pull request.
Checklist prático até a Beta 1
- Agora: crie o staging ou ambiente local, registre versões e faça uma cópia dos casos de teste mais importantes.
- Semanalmente: atualize trunk e, quando fizer sentido, Gutenberg; rode smoke tests nos plugins e temas críticos.
- Plugins: procure depreciações, falhas de JavaScript, respostas REST alteradas e problemas em telas administrativas e blocos.
- Temas: revise theme.json, Global Styles, style variations, espaçamento, elementos e supports de blocos.
- Editor: teste criação, edição, transformação, undo/redo, salvar, reabrir e renderizar no front-end.
- Isolamento: confirme qualquer regressão com tema padrão e o menor conjunto possível de plugins.
- Beta 1: quando sair entre 20 e 22 de outubro, congele uma rodada completa de regressão contra esse build e acompanhe as Dev Notes.
O que um teste aprovado não prova
Passar hoje no trunk não garante compatibilidade com a versão final, porque o código ainda pode mudar. Também não significa que uma novidade vista no Gutenberg 23.8 ou 23.9 será entregue sem alterações no 7.2. O objetivo desta fase é reduzir surpresa: descobrir cedo onde seu plugin, tema ou bloco depende de um comportamento que está mudando e manter um caso de teste que possa ser repetido a cada beta e release candidate.
Se você tiver pouco tempo, concentre o esforço nos fluxos que combinam maior impacto e maior acoplamento ao editor ou ao core. Uma lista pequena de testes repetíveis vale mais do que navegar aleatoriamente pelo painel. Ao chegar à Beta 1, você deve saber quais componentes são críticos, quais cenários já têm baseline no 7.1 e como reproduzir rapidamente qualquer diferença no 7.2.
