O WordPress 7.1.1 já tem um cronograma público, mas ainda não tem uma lista final de correções fechada. A manutenção foi programada depois do lançamento do WordPress 7.1 em 19 de agosto de 2026, e o plano divulgado pelo time de Core em 2 de setembro coloca a primeira Release Candidate (RC1) em 10 de setembro e a versão geral em 17 de setembro.
Para quem administra sites em produção, a leitura mais útil é esta: 10/9 é um marco para testar; 17/9 é o marco previsto para atualizar a versão estável. Até lá, o conjunto de tickets ainda pode mudar e os próprios horários do cronograma são estimativas, conforme o post oficial do WordPress 7.1.1.
Cronograma oficial do WordPress 7.1.1 até 17/9
O calendário publicado pelo Make WordPress Core inclui sessões de revisão de bugs antes e depois da RC1. A tabela abaixo converte os horários para Brasília (UTC-3), além de preservar o horário oficial em UTC.
| Data | Evento | UTC | Horário de Brasília |
|---|---|---|---|
| 3/9 | Bug scrub | 14:00 | 11:00 |
| 4/9 | Bug scrub | 14:00 | 11:00 |
| 8/9 | Bug scrub; abertura do milestone 7.1.2 e possível adiamento de tickets | 20:00 | 17:00 |
| 9/9 | Bug scrub | 10:00 | 07:00 |
| 10/9 | WordPress 7.1.1 RC1 | 17:30 | 14:30 |
| 15/9 | Bug scrub | 14:00 | 11:00 |
| 17/9 | Lançamento geral do WordPress 7.1.1 | 15:00 | 12:00 |
Há duas ressalvas importantes. Primeiro, o post oficial afirma que os horários são estimativas e dependem da disponibilidade das pessoas envolvidas na liberação. Segundo, em 8/9 o milestone do WordPress 7.1.2 deve ser aberto e alguns tickets podem ser transferidos para ele. Isso significa que uma correção discutida agora não deve ser tratada como parte confirmada do 7.1.1 até a composição final da versão.
O que já está confirmado sobre o 7.1.1
O escopo declarado é de manutenção com correção de bugs. O time de Core informa que os tickets entram no 7.1.1 quando tratam de problemas introduzidos durante o ciclo do WordPress 7.1 ou de itens que foram intencionalmente adiados no fim daquele ciclo.
Isso também define o que não convém prometer antes das notas oficiais: não há base para anunciar uma lista fechada de correções, ganhos de desempenho específicos, mudança de recurso ou correção de segurança apenas porque um ticket está em discussão. O conjunto final deve ser conferido quando a RC1 e, depois, a versão estável forem publicadas.
O que a RC1 de 10/9 significa na prática
RC significa Release Candidate: uma versão candidata a se tornar a versão pública se não surgirem problemas relevantes. O handbook do ciclo de lançamento do WordPress descreve essa fase como o estágio em que o trabalho se concentra em regressões e estabilização. O mesmo handbook admite mais de uma RC quando bugs encontrados precisam ser corrigidos antes do lançamento.
Para o administrador de um site, isso não transforma a RC1 em uma atualização de produção. Em anúncios de RC, o próprio WordPress recomenda testar versões de pré-lançamento em servidor ou site de teste, e não em instalações de produção ou críticas. O objetivo da RC1 é validar a versão em ambientes reais sem colocar o site principal em risco.
Quem deveria testar a RC1 e quem pode esperar
| Perfil do site | Conduta mais prudente | O que validar |
|---|---|---|
| Desenvolvedor de plugin, tema ou integração | Testar a RC1 assim que houver pacote e instruções oficiais | Compatibilidade, avisos PHP, editor, APIs, fluxos alterados pelo produto |
| Agência com muitos sites WordPress 7.1 | Usar um staging representativo antes de 17/9 | Stacks recorrentes, plugins comuns, cache, formulários, autenticação e deploy |
| WooCommerce, membership, LMS ou site com fluxos críticos | Testar em clone de staging; evitar RC em produção | Checkout, login, webhooks, tarefas agendadas, e-mails, pagamentos e integrações |
| Site institucional simples e estável | Pode esperar a versão final de 17/9 | Backup, editor, formulários, cache e páginas principais após a atualização |
| Site sem ambiente de staging e sem equipe técnica | Esperar a versão estável e revisar a estratégia de backup | Capacidade de restauração antes de atualizar |
Essa divisão é uma orientação de risco, não uma regra do projeto WordPress. Quanto mais receita, autenticação, automação ou integração externa depender do site, maior o valor de reproduzir o ambiente real em staging antes de liberar a atualização em produção.
Checklist de teste em staging antes de atualizar produção
- Faça backup recuperável de arquivos e banco de dados antes de qualquer atualização relevante. A documentação oficial de atualização do WordPress recomenda backup como etapa inicial.
- Use um clone representativo do site, com tema, plugins, versão de PHP e configurações semelhantes às de produção.
- Registre o estado inicial: WordPress, plugins, tema, PHP, cache e integrações. Isso facilita identificar o que mudou.
- Teste o wp-admin e o editor: criação e edição de páginas e posts, mídia, padrões, navegação e permissões usadas pela equipe.
- Teste fluxos que geram negócio: formulários, login, checkout, assinaturas, área de membros, LMS, pesquisas internas ou integrações por API.
- Observe logs e erros: erros PHP, falhas JavaScript, tarefas agendadas e comportamento de cache podem revelar incompatibilidades que a navegação superficial não mostra.
- Tenha rollback definido: saber restaurar o backup é tão importante quanto ter o arquivo de backup.
Para testar versões de pré-lançamento, o guia de Beta Testing do WordPress documenta o uso do plugin WordPress Beta Tester e das trilhas Beta/RC. Quando o 7.1.1 RC1 for publicado, vale seguir as instruções específicas do anúncio daquela build, porque o método ou o foco de teste pode ser detalhado ali.
Vale esperar até 17/9 para atualizar?
Para a maioria dos sites que só precisa de uma versão estável, sim: esperar o lançamento geral previsto para 17/9 evita colocar uma RC em produção. Sites complexos ganham mais segurança se usarem a janela entre 10/9 e 17/9 para validar a candidata em staging e preparar um plano de atualização.
Também é importante verificar como o site recebe atualizações automáticas. A documentação de atualização do WordPress explica que atualizações menores do Core, como releases de manutenção e segurança, são habilitadas automaticamente por padrão em muitos cenários, embora constantes, filtros, controle do administrador, presença de versionamento e políticas da hospedagem possam alterar esse comportamento. Em ambientes gerenciados, confirme ainda se o provedor aplica atualizações em uma janela própria.
O que ainda pode mudar antes do lançamento
Três elementos permanecem abertos até a publicação final: o conjunto de tickets, porque itens podem ser movidos para 7.1.2; a necessidade de uma RC adicional, caso testes encontrem problemas que exijam nova candidata; e o horário exato dos marcos, que o cronograma classifica como estimado.
Já as datas-alvo de 10/9 para RC1 e 17/9 para a versão geral são o plano oficial vigente em 4 de setembro de 2026. Se o cronograma mudar, a referência primária continua sendo o Make WordPress Core.
Como acompanhar sem confundir proposta com correção confirmada
Use o post de cronograma como ponto de partida e acompanhe os links de tickets e tarefas editoriais indicados pelo próprio time. Antes da RC1, trate tickets como candidatos. Depois da RC1, confira o pacote e as notas daquele build. Para produção, a decisão final deve considerar as notas da versão estável, seus testes em staging e a possibilidade real de rollback.
Em resumo: marque 10 de setembro como a data para testar e 17 de setembro como a data prevista para atualizar a versão estável. Quem mantém plugins, temas, lojas, portais com autenticação ou sites com integrações críticas tem mais a ganhar testando a RC1 em staging; quem administra um site simples e estável pode esperar a versão geral, preparar backup e então validar os fluxos essenciais antes de concluir a atualização.
