Toda grande versão do WordPress vira campo de dois exageros ao mesmo tempo: de um lado, quem anuncia a revolução; do outro, quem garante que nada muda. A verdade quase nunca está no meio — está no detalhe. E o WordPress 7.0 “Armstrong”, lançado em 20 de maio de 2026, tem detalhes que importam de verdade para quem opera um site em produção, não só para quem escreve changelog.
Este texto é a referência prática em português do que o 7.0 muda na sua operação. Sem printar tela bonita de recurso que você nunca vai usar. A pergunta que guia cada seção é uma só: isso muda alguma coisa no meu dia a dia, no meu servidor, no meu custo de manutenção? Onde a resposta for “não”, a gente diz “não”. Onde for “sim, e você precisa agir”, a gente diz o que fazer.
WordPress 7.0 “Armstrong” é a versão que trouxe as primeiras fundações de IA para o core, o primeiro redesenho do admin desde 2013 e uma nova forma de registrar blocos só em PHP — além de derrubar o suporte a PHP 7.2 e 7.3.
IA no core: fundação, não assistente pronto
A manchete do 7.0 é a IA. Mas é aqui que mora a maior confusão. O 7.0 não colocou um assistente de escrita dentro do editor. O que ele colocou foi a encanação: um AI Client agnóstico de provedor, uma Abilities API expandida e uma nova tela em Configurações chamada Conectores, que já suporta Anthropic, Google e OpenAI como provedores padrão.
Traduzindo para operação: o WordPress agora tem uma maneira padronizada de plugins exporem funcionalidades para agentes de IA — e para outros plugins. A cobertura da InfoQ sobre o release descreve isso como “fundações de IA no core”, e a palavra certa é essa: fundação. É a diferença entre a companhia elétrica levar o poste até a sua rua e você ter um chuveiro quente. O 7.0 trouxe o poste.
Por que isso importa para você mesmo sem usar IA hoje? Porque padroniza. Antes, cada plugin de IA falava com a OpenAI do seu jeito, guardava chave de API do seu jeito, tratava erro do seu jeito. Com a Abilities API e o AI Client, esse contrato passa a ser do core. O ecossistema para de reinventar a roda, e você ganha previsibilidade de segurança e manutenção. O ganho real chega nos próximos meses, conforme os plugins adotarem a fundação — não no dia da atualização.
O que fazer na prática
Se você não usa IA no site, não precisa mexer em nada: a tela de Conectores vem vazia e inerte. Se pretende usar, o caminho passa a ser conectar um provedor uma vez, em Configurações > Conectores, e deixar os plugins consumirem por ali — em vez de espalhar chave de API por seis lugares. É um ganho de governança que vale a pena adotar com calma, e que se conecta diretamente com segurança de WordPress: chave de IA é credencial, e credencial centralizada é credencial mais fácil de auditar.
Admin redesenhado com DataViews
O 7.0 começou o primeiro redesenho do painel administrativo desde 2013. O sistema por trás disso se chama DataViews, e é a mudança visual e estrutural mais significativa no back-office em mais de uma década. Na prática você vê tipografia mais limpa, espaçamento consistente, filtros inline que não recarregam a página e um alinhamento visual entre o editor de blocos e as telas clássicas do admin.
Some-se a isso o Command Palette, acessível por ⌘K no Mac ou Ctrl+K no Windows, de qualquer lugar do admin. Ele deixa você pular para qualquer tela, post ou comando registrado na hora — o mesmo padrão que você já conhece do VS Code, do Notion, do Linear.
Aqui vale honestidade: redesenho de admin é a mudança que mais gera reclamação de usuário, porque quebra memória muscular. Quem administra conteúdo todo dia vai levar alguns dias para se reacostumar. Não é um problema técnico, é um custo de adaptação — e você deve avisar o time de conteúdo antes de atualizar, não depois. A boa notícia é que a mudança é de aparência e navegação, não de conceito: onde as coisas ficavam, elas continuam existindo.
Registro de bloco só em PHP
Esta é a novidade que mais anima quem desenvolve. O 7.0 introduziu o registro de bloco só em PHP: você registra um bloco usando PHP como fonte da verdade dos metadados, sem precisar de block.json, sem edit.js, sem Webpack, sem pipeline de build. Você mantém registro, metadados, assets e renderização juntos, no mesmo lugar.
A própria proposta no Make WordPress Core é clara sobre o escopo: isso serve para blocos que só precisam de renderização no servidor e não são altamente interativos. Não substitui o paradigma client-side existente, nem pretende ser tão completo quanto ele. É para o bloco dinâmico, PHP-first — aquele que puxa um dado, monta um HTML e devolve.
Por que isso muda o custo de um projeto
Para agências e software houses, essa é a novidade com efeito mais direto no orçamento. Muito bloco customizado que a gente entrega é exatamente isso: dinâmico, server-side, pouco interativo — um card de produto, uma listagem de posts filtrada, um bloco de CTA que puxa dado de outro lugar. Antes, mesmo esse bloco simples arrastava toda uma toolchain de JavaScript junto: Node, build, block.json, um edit.js que só existia para o editor não quebrar.
Cortar essa toolchain para a classe de blocos que não precisa dela significa menos superfície de manutenção, menos dependência para atualizar, menos coisa para dar errado no deploy. Menos JavaScript no projeto também costuma significar site mais leve — o que conversa direto com performance e conversão. Não é bala de prata: bloco interativo continua exigindo o caminho client-side. Mas para o feijão com arroz dos blocos server-side, é um alívio real de complexidade.
Gutenberg Fase 3: roadmap vs. release
Agora a parte em que mais gente se confunde — e onde muito artigo erra feio. A edição colaborativa em tempo real, no estilo Google Docs, é a feature de vitrine da Fase 3 do Gutenberg. Muita gente esperava vê-la no 7.0. Ela não entrou.
A colaboração em tempo real foi puxada do release cerca de doze dias antes do lançamento e adiada para uma versão futura. Isso está documentado na cobertura do release, inclusive na análise da DreamHost sobre o que entrou e o que foi cortado. Ou seja: é roadmap, não é entrega. Se você leu em algum lugar que o WordPress 7.0 “agora tem edição colaborativa igual Google Docs”, esse conteúdo está errado — ou foi escrito antes do corte e nunca atualizado.
Por que insistir nesse ponto? Porque decisão de negócio se toma com base no que existe, não no que foi prometido. Se a colaboração em tempo real é requisito para a sua operação editorial, ela não está disponível no 7.0. O que entrou de fato na linha de colaboração foram recursos menores: Visual Revisions, notificações por e-mail nas Notes e um modo de Sugestões. Úteis, mas longe do commit simultâneo em tempo real. Planeje pelo que está no changelog, não pelo que estava no roadmap.
Fim do PHP 7.2 e 7.3: a mudança que pode quebrar seu site
Se você só for ler uma seção deste texto, leia esta. A mudança mais capaz de quebrar o seu site no 7.0 não é a IA nem o admin novo — é o PHP. O WordPress 7.0 eleva a versão mínima suportada para PHP 7.4 e derruba o suporte a PHP 7.2 e 7.3.
Muito site brasileiro ainda roda em hospedagem compartilhada com PHP antigo, às vezes sem o dono saber. Se o seu servidor estiver em 7.2 ou 7.3, atualizar para o WordPress 7.0 sem antes subir o PHP é receita de tela branca. E o inverso também vale: subir o PHP sem testar pode quebrar plugin velho que dependia de comportamento antigo.
Checklist de atualização segura
- Descobrir a versão de PHP atual do servidor (Ferramentas > Saúde do site, ou painel da hospedagem)
- Se estiver abaixo de 7.4, planejar a subida do PHP antes de tocar no WordPress
- Levantar a lista de plugins e temas e checar compatibilidade declarada com o 7.0 e com PHP 7.4+
- Clonar o site para um ambiente de staging idêntico ao de produção
- Fazer backup completo (arquivos + banco) e testar que o backup restaura
- Atualizar no staging, navegar nas telas críticas, testar formulários e checkout
- Só então atualizar produção, em horário de baixo tráfego, com backup fresco
- Monitorar erros e performance nas 48h seguintes
Nada nessa lista é opcional. É exatamente esse processo que separa “atualizei e nem senti” de “o site caiu na segunda de manhã”. Grande salto de versão não é hora de improviso.
Vale a pena atualizar? Um resumo honesto
Depende de onde você está. Segue o resumo sem rodeio:
| Seu cenário | Recomendação |
|---|---|
| Site já em PHP 7.4+, plugins mantidos | Atualize, com staging e backup. Ganho de admin e futuro de IA valem |
| Site em PHP 7.2/7.3 | Não atualize ainda. Suba o PHP primeiro, teste, depois atualize |
| Muitos plugins antigos e sem manutenção | Audite antes. O 7.0 pode expor plugin que já estava por um fio |
| Precisa de colaboração em tempo real | O 7.0 não resolve. Ela é roadmap, não release |
| Quer construir com a nova IA do core | Vale começar a experimentar a Abilities API em staging |
O 7.0 é uma versão importante — talvez a mais significativa em uma década, tanto pela fundação de IA quanto pelo redesenho do admin. Mas “importante” não é sinônimo de “atualize hoje às pressas”. É sinônimo de “planeje bem, porque essa você não quer fazer no susto”.
Onde a Pixelize entra
Grande parte do estrago em atualização de WordPress vem de site sem manutenção contínua: PHP esquecido em versão antiga, plugin que ninguém revisa, ausência de staging. Quando isso está em dia, uma versão como a 7.0 vira um evento tranquilo — você agenda, testa, sobe. Quando não está, vira crise. É a diferença que a manutenção contínua faz.
Se o seu WordPress é institucional e você está avaliando arquitetura, vale também entender onde faz — e onde não faz — sentido ir para uma abordagem desacoplada; escrevemos sobre isso em WordPress headless vale a pena. E se você quer que a atualização para o 7.0 seja conduzida com staging, backup e revisão de plugins de verdade, é isso que fazemos em WordPress: tirar o susto da equação.
Perguntas frequentes
Quando o WordPress 7.0 foi lançado?
Em 20 de maio de 2026, com o codinome “Armstrong”, em homenagem a Louis Armstrong. É a primeira versão a trazer fundações de IA no core e o primeiro redesenho do admin desde 2013, segundo os anúncios oficiais e a cobertura técnica da imprensa especializada.
O WordPress 7.0 já vem com IA que escreve meus textos?
Não. O 7.0 traz a fundação — o AI Client agnóstico de provedor, a Abilities API e uma tela de Conectores para Anthropic, Google e OpenAI. É infraestrutura para plugins e agentes usarem, não um assistente de escrita pronto no editor. O valor vem de quem construir em cima dela.
Preciso atualizar para o 7.0 imediatamente?
Não precisa correr, mas precisa se planejar. O ponto crítico é o PHP: o 7.0 exige no mínimo PHP 7.4 e derruba 7.2 e 7.3. Antes de atualizar, cheque a versão do PHP no servidor e a compatibilidade dos plugins em ambiente de teste, nunca direto na produção.
A edição colaborativa em tempo real entrou no 7.0?
Não. A colaboração em tempo real era a feature mais esperada e foi removida cerca de doze dias antes do lançamento, adiada para uma versão futura. Ela é roadmap da Fase 3 do Gutenberg, não algo que já foi entregue no 7.0. Cuidado com conteúdo que afirma o contrário.
O que é o registro de bloco só em PHP?
É um jeito novo de registrar um bloco usando PHP como fonte da verdade, sem precisar de block.json, edit.js ou pipeline de build. Serve para blocos dinâmicos e com renderização no servidor, não para blocos altamente interativos. Simplifica muito a vida de quem faz plugin PHP-first.
Meu site vai quebrar quando eu atualizar?
Se você pular a etapa de teste, pode quebrar — principalmente por PHP desatualizado ou plugin incompatível. Com um ambiente de staging, backup e revisão de plugins, a atualização costuma ser tranquila. Manutenção contínua existe exatamente para que grandes saltos de versão não virem crise.