WordPress 7.1: o que muda na sua operação WP

WordPress 7.1 é a versão principal do WP publicada em agosto de 2026, com mais de 310 tickets do Core Trac incluídos e um Field Guide próprio documentando as mudanças relevantes para quem desenvolve e mantém sites. Se o seu site é ativo de receita, a pergunta que importa não é “o que veio”, é “quando eu atualizo e o que pode quebrar”.

Toda release principal chega assim. Metade novidade, metade risco operacional.

E o risco quase nunca está no core. Está no que você colocou em cima dele.

O que já está confirmado sobre o WordPress 7.1

O anúncio oficial saiu no blog do WordPress.org sob o nome Mary Lou, seguindo a tradição do projeto de batizar cada release principal em homenagem a músicos de jazz.

O documento que interessa para o time técnico é outro: o Field Guide do WordPress 7.1, publicado pela equipe de Core em 5 de agosto de 2026, ainda na fase de Release Candidate.

Segundo o próprio Field Guide, o WordPress 7.1 reúne mais de 310 tickets do Core Trac, sendo mais de 100 deles enhancements e feature requests.

Traduzindo esse número para a sua realidade: são mais de cem pontos do sistema que mudaram de comportamento de propósito, não por correção de bug. Cada um deles é uma linha de código que pode encostar no seu tema, no seu bloco customizado ou na integração que o time de dados montou via REST API.

Aqui na Apiki a gente não parafraseia changelog. A lista canônica de APIs alteradas, deprecations e breaking changes está no Field Guide, ela é atualizada pela própria equipe de Core e é ela que deve abrir a sua reunião de planejamento de atualização. Qualquer resumo de terceiro (inclusive este) é sempre uma camada a mais de ruído entre você e a fonte primária.

O que dá para fazer de valor real aqui é outra coisa: te mostrar como transformar essa release em um plano de execução que não derruba o seu portal na quinta-feira à tarde.

Release principal não é atualização de rotina

Existe uma confusão comum entre versões do WP que precisa morrer.

Uma versão x.y.z (tipo 7.0.3) é uma release de manutenção e segurança. Escopo fechado, superfície pequena, risco baixo. Você aplica rápido e dorme tranquilo.

Uma versão x.y (o caso do WordPress 7.1) é uma release principal. Ela carrega mudanças de API, novas capacidades do editor, ajustes de comportamento e, eventualmente, remoção de coisas que estavam depreciadas há ciclos.

Tratar as duas com o mesmo processo é onde a operação se machuca.

Na nossa experiência com projetos corporativos de Educação, Fintech e Saúde, o incidente pós-atualização quase nunca vem do core do WordPress. Vem de um plugin sem manutenção há dois anos, de um tema filho com lógica acoplada a um hook que mudou de assinatura, ou de um bloco customizado registrado sem versionamento de asset.

O core do WP é a parte mais testada do seu stack. O seu functions.php não é.

Como ler um Field Guide sem perder o dia inteiro

O Field Guide é longo por natureza. Ele cobre o ciclo inteiro, e boa parte do conteúdo não tem relação com o seu projeto.

O caminho que a gente segue é ler por camada de impacto, nesta ordem:

• Breaking changes e deprecations: a única seção obrigatória. É aqui que aparecem funções removidas, hooks com assinatura alterada e comportamentos que deixaram de existir. Se o seu tema é customizado, essa leitura não é opcional.

• Requisitos de ambiente: versão mínima de PHP, MySQL ou MariaDB suportada pela release. Se houver mudança, o problema deixa de ser do time de marketing e passa a ser de infraestrutura antes do deploy.

• Editor e blocos: mudanças no Gutenberg afetam diretamente quem publica todos os dias. Bloco customizado que depende de API interna do editor é o candidato número um a quebrar visualmente.

• REST API e integrações: se você roda headless, alimenta um app mobile ou sincroniza com CRM, mudanças de endpoint e de schema entram no seu radar antes de qualquer novidade de interface.

• Performance: alterações em carregamento de assets, lazy loading e queries do core podem mexer nos seus Core Web Vitals, para melhor ou para pior. Vale medir antes e depois, não confiar na promessa.

Leia essas cinco camadas com o inventário do seu site aberto do lado. Sem inventário, você está lendo documentação genérica, não avaliando risco.

O protocolo de atualização que aplicamos no WP Care

Atualizar o WP de um portal que recebe tráfego o dia inteiro é como reformar a cozinha do restaurante no meio do almoço. Dá para fazer. Mas não do jeito que você faria com o salão vazio.

O roteiro abaixo é o que a gente executa em contas gerenciadas. Adapte ao seu contexto, mas não pule etapa.

1. Inventário completo do ambiente. Liste versão atual do core, todos os plugins ativos com versão e data do último update, tema pai, tema filho e qualquer mu-plugin. O WP-CLI resolve isso em um comando e gera um artefato que você anexa no card da tarefa.

2. Cruzamento com o Field Guide. Marque quais itens do inventário tocam nas áreas alteradas pelo WordPress 7.1. O que não toca, sai da análise. O que toca, vira caso de teste nomeado.

3. Clone de staging fiel à produção. Mesma versão de PHP, mesmo servidor web (Nginx ou Apache), mesmo banco, mesma camada de cache. Staging com configuração diferente de produção não testa nada, só dá falsa confiança.

4. Atualização em staging com log ativo. Rode com WP_DEBUG e WP_DEBUG_LOG ligados. Warning de deprecation em log é o seu aviso prévio antes do erro fatal em produção. Se você não conhece as flags disponíveis, vale revisar as constantes do wp-config.php.

5. Teste dos fluxos de negócio, não das telas. Formulário de captação, área logada do aluno, checkout, integração com CRM, busca interna, envio de newsletter. Homepage abrindo bonito não é critério de aprovação.

6. Benchmark de performance antes e depois. Meça LCP, INP e CLS nas três ou quatro URLs que mais convertem, com o mesmo método nas duas medições. Sem baseline, você não tem como provar que a release melhorou ou piorou nada.

7. Janela de deploy definida com o time de conteúdo. Nunca em pico de tráfego, nunca em véspera de campanha, nunca na sexta. E com alguém de plantão pela primeira hora.

Sete passos. Nenhum deles é criativo, e é exatamente esse o ponto.

Onde uma atualização do WP costuma quebrar de verdade

Se eu tivesse que apostar em um culpado antes de abrir o log, apostaria sempre nos mesmos suspeitos.

Plugin sem manutenção. Aquele que resolve uma coisa específica, foi instalado em 2021 e cujo autor sumiu. Ele não vai ser atualizado para o WordPress 7.1 porque não tem ninguém do outro lado.

Tema filho com lógica de aplicação. Quando o functions.php vira repositório de regra de negócio, cada mudança de hook no core vira um incidente. Código de negócio pertence a plugin próprio, versionado, com responsável.

Page builder de terceiro. Builders reimplementam boa parte do que o editor faz e frequentemente dependem de APIs internas. Eles são os primeiros a sentir e nem sempre os primeiros a corrigir.

Bloco customizado sem build atualizado. Se o seu bloco foi compilado com uma versão antiga das dependências do editor de blocos, ele pode continuar renderizando no front e quebrar na edição. O editor trava, o time de conteúdo para, e o chamado chega em você.

Camada de cache servindo HTML velho. Esse não é bug, é configuração. Depois de atualizar, invalide cache de página, de objeto e de edge. Já vimos “o site quebrou” que era só CDN entregando markup antigo com asset novo.

Nenhum desses problemas é do WordPress. Todos são do ambiente. E é por isso que atualização de release principal é trabalho de operação, não de clique no botão azul.

Atualizar no dia do lançamento ou esperar o 7.1.1

Essa discussão aparece em toda release, e a resposta honesta é: depende do papel do site no seu negócio.

Na minha visão, para site institucional simples, atualizar cedo é ótimo. Para portal com dez mil sessões diárias, área logada e integração com sistema acadêmico, correr para ser o primeiro é vaidade técnica.

Abordagem	Quando faz sentido	Risco principal	Requisito mínimo
Auto-update no dia do lançamento	Sites institucionais, blogs, poucos plugins, tema padrão ou com pouca customização	Regressão de plugin de terceiro sem correção disponível	Backup automatizado diário e monitoramento de uptime
Janela controlada em staging (nosso padrão)	Portais corporativos, e-commerce em WooCommerce, sites com equipe de conteúdo e integrações ativas	Custo de horas de teste e coordenação entre marketing e TI	Staging espelhado, WP-CLI, checklist de fluxos críticos e plano de rollback
Esperar a primeira release de manutenção	Ambientes com compliance rígido, muitos blocos customizados ou dependência forte de builder	Ficar exposto a correções de segurança que só chegam na versão nova	Política escrita de prazo máximo de defasagem e acompanhamento do Trac

Repare que a terceira linha tem um risco embutido que muita gente ignora. Esperar não é neutro. Ficar duas releases atrás por medo é trocar risco de regressão por risco de vulnerabilidade, e o segundo costuma ser mais caro. Se esse é o seu cenário, vale rodar um WPScan para auditar vulnerabilidades conhecidas enquanto a janela não chega.

Rollback é plano escrito, não improviso

A pergunta que eu faço em toda reunião de atualização é simples: se em quinze minutos o editor não conseguir publicar, qual é o comando que reverte?

Se a resposta demora, o plano não existe.

Rollback de WordPress tem duas metades que precisam voltar juntas: arquivos e banco. Reverter só os arquivos depois que o core rodou uma migração de schema é receita de inconsistência.

• Snapshot pré-deploy de arquivos e banco, tirado imediatamente antes da atualização e com restauração já testada pelo menos uma vez, não apenas configurada.

• Comando de reversão documentado, com a versão exata de origem registrada no card da tarefa, para que qualquer pessoa do plantão execute sem depender de quem fez o deploy.

• Critério objetivo de acionamento, definido antes: erro fatal em qualquer template, falha no fluxo de conversão principal ou editor inacessível para o time de conteúdo.

• Monitoramento ativo nas primeiras 24 horas, olhando log de PHP, taxa de erro 5xx, tempo de resposta e volume de chamados abertos pelos editores.

Esse último item é o mais negligenciado. Muita regressão não derruba o site, só torna alguma coisa lenta ou chata. Ela aparece no volume de chamados antes de aparecer no gráfico de uptime.

O que fazer com as novidades depois que o WP está estável

Atualizar é a primeira metade. Usar é a segunda, e é onde quase toda operação deixa valor na mesa.

Uma release com mais de 100 enhancements, como o Field Guide indica no WordPress 7.1, traz capacidade nova que só vira resultado se alguém sentar e aplicar.

Nosso caminho é sempre o mesmo. Depois de duas semanas de produção estável, o time revisita o Field Guide procurando por três coisas: o que reduz passo no fluxo de publicação, o que permite aposentar plugin de terceiro e o que melhora tempo de carregamento sem refatoração grande.

Plugin aposentado é a melhor delas. Cada dependência a menos é uma superfície de ataque a menos e um ponto a menos de quebra na próxima atualização. Se o core passou a fazer nativamente algo que você resolvia com plugin, tire o plugin.

Medimos. Testamos. Validamos. Escalamos. Nessa ordem, sempre.

Perguntas frequentes sobre o WordPress 7.1

O WordPress 7.1 quebra plugins existentes?

O core do WordPress mantém compatibilidade retroativa como princípio de projeto, então plugins bem escritos e atualizados costumam funcionar sem intervenção. O risco real está em extensões abandonadas, em código customizado acoplado a hooks alterados e em builders que dependem de APIs internas do editor. A lista de deprecations e breaking changes do ciclo está no Field Guide oficial da release, e é ela que deve ser cruzada com o inventário de plugins do seu site antes de qualquer deploy.

Quanto tempo esperar antes de atualizar um site corporativo?

Não existe número universal, existe critério. Para sites institucionais com poucas customizações, atualizar cedo com backup ativo é razoável. Para portais com área logada, integrações e equipe de conteúdo publicando diariamente, o padrão que adotamos é validar em staging espelhado antes de subir e definir uma janela fora de pico. O que não é aceitável é ficar indefinidamente para trás, porque correções de segurança chegam nas versões novas.

Dá para atualizar o WordPress 7.1 pelo WP-CLI?

Dá, e é o caminho que recomendamos em ambientes gerenciados. O WP-CLI permite atualizar core, plugins e banco por comando, roda em pipeline, gera log e é reproduzível entre staging e produção, o que o painel administrativo não oferece. Combine o update com verificação de checksums dos arquivos do core e com invalidação de cache logo em seguida.

A atualização afeta os Core Web Vitals do site?

Pode afetar, nos dois sentidos. Mudanças em carregamento de assets, lazy loading e queries do core mexem no comportamento de renderização, e o efeito real depende do seu tema e dos seus plugins. A única forma de saber é medir LCP, INP e CLS nas URLs de maior tráfego antes e depois, usando o mesmo método de coleta. Sem baseline, qualquer conclusão sobre performance vira achismo.

Conclusão

O WordPress 7.1 é uma release principal com mais de 310 tickets fechados, e isso significa superfície de mudança suficiente para exigir processo.

Não é sobre a novidade do editor. É sobre o inventário, o staging fiel, o teste de fluxo de negócio e o plano de rollback escrito antes do deploy.

Quem trata atualização como evento tem incidente. Quem trata como rotina versionada tem previsibilidade, e previsibilidade é o que o seu time de conteúdo precisa para publicar sem pedir socorro para a TI.

Se a fila de atualização do seu WP está sempre atrasada porque ninguém tem janela para testar, é exatamente esse gargalo que a gente destrava no WP Care: inventário, ambiente de homologação, execução e monitoramento pós-deploy, com relatório do que foi feito. Chame nosso time para uma conversa e a gente avalia a sua operação WordPress junto com você.

Me conta: como está a política de atualização do WordPress no seu time hoje, documentada ou no combinado verbal?