Por que usar versões atualizadas do PHP?

Um ramo do PHP recebe correção de erro por dois anos e correção de segurança por mais um. Passados os três, ele não recebe mais nada — nem quando aparece uma falha grave. É por isso que “está funcionando” não é resposta para “por que atualizar”: o site que roda numa versão encerrada funciona até o dia em que alguém repara que ele não é mais corrigido.

Em agosto de 2026 esta é a conta, direto do calendário do php.net:

• PHP 8.5, lançado em 20 de novembro de 2025 — correção de erro até 31/12/2027, segurança até 31/12/2029.
• PHP 8.4 — correção de erro até 31/12/2026, segurança até 31/12/2028.
• PHP 8.3 — só segurança, até 31/12/2027.
• PHP 8.2 — só segurança, e ela acaba em 31/12/2026: daqui a poucos meses.
• PHP 8.1 e tudo que veio antes — encerrado. Sem correção de nenhum tipo, incluindo o PHP 7 inteiro e o 5.6.

Quem está no 8.1 ou abaixo não tem prazo para se planejar: já passou. Quem está no 8.2 tem este ano.

O que “sem suporte” significa na prática

Não é que o site pare. É que ele passa a acumular três dívidas ao mesmo tempo, e nenhuma delas aparece no dia em que nasce.

A primeira é segurança. Falha encontrada em ramo encerrado não é corrigida, e a descrição dela fica pública do mesmo jeito. A partir daí, quem procura alvo sabe exatamente o que procurar, e a única defesa que sobra é o que estiver na frente do PHP — firewall, regra de servidor, sorte. É defesa de fora, não conserto.

A segunda é a plataforma em volta. O WordPress, os plugins e os temas param de testar contra versão encerrada. O plugin não avisa que deixou de suportar: ele publica uma atualização que usa sintaxe nova, e o site quebra na hora do update — que é o pior momento possível, porque parece que a culpa é da atualização.

A terceira é a hospedagem. Empresa séria não mantém para sempre um interpretador que ninguém corrige. Em algum momento vem o aviso de migração compulsória, e aí a atualização deixa de ser projeto e vira urgência, com data marcada por outra pessoa.

O ganho que não é segurança

O salto de desempenho grande do PHP já aconteceu, e foi a virada do 5.6 para o 7.0, em 2015 — o motor foi reescrito e o consumo de memória por requisição caiu de forma que se enxergava sem instrumento. De lá para cá o ganho por versão é menor e constante: cada ramo entrega um pouco mais de requisição por segundo no mesmo servidor.

Num site institucional isso é detalhe. Num portal que serve dezenas de milhares de páginas por hora, é a diferença entre precisar e não precisar de mais um nó no cluster. É a mesma conta que a gente faz ao dimensionar a infraestrutura de um portal: a versão do interpretador entra antes da decisão de comprar máquina.

O que costuma quebrar, e por que quase nunca é o que se teme

O medo de atualizar é razoável; a paralisia não. Na prática o que quebra é um conjunto pequeno e conhecido de coisas, quase sempre em código antigo de tema ou de plugin abandonado:

• Propriedade dinâmica — gravar num atributo que a classe não declarou virou aviso no 8.2 e vai virar erro. É de longe o mais comum em tema antigo.
• Interpolação ${...} dentro de texto — depreciada no 8.2, com a forma nova sendo {$var}.
• Funções que sumiram há muito tempo, como a família mysql_*, each() e create_function(). Quem ainda depende delas não está atrasado uma versão, está atrasado uma década.
• Tipo implicitamente nulo em parâmetro — depreciado no 8.4, e resolvido escrevendo ?tipo onde o valor pode ser nulo.

Repare no padrão: quase tudo é aviso antes de ser erro. O PHP avisa por um ou dois ramos inteiros antes de derrubar. Quem lê o log de erro do site tem anos de aviso; quem nunca abriu o log descobre tudo de uma vez, no dia da migração compulsória.

Como atualizar sem transformar o dia num incidente

A ordem importa mais do que a ferramenta. É esta, e ela vale tanto para um site institucional quanto para um portal:

1. Descobrir a versão de hoje e a versão de destino — e escolher como destino o ramo que ainda recebe correção de erro, não o que só recebe segurança. Atualizar para um ramo prestes a encerrar é repetir o trabalho em poucos meses.
2. Ligar o registro de erro e ler o que já está lá. Os avisos de depreciação do código de hoje são a lista de tarefas da atualização, escrita de graça pelo próprio PHP.
3. Levantar plugin e tema por plugin e tema: qual declara compatibilidade, qual foi atualizado nos últimos meses, qual está abandonado. O abandonado é decisão, não tarefa — trocar, reescrever ou remover.
4. Rodar a troca numa cópia do site, não no site. Cópia com o mesmo banco, o mesmo conteúdo e o mesmo tráfego sintético; não vale testar a home e declarar vitória.
5. Virar em horário de pouco acesso, com o caminho de volta pronto e testado. Reverter é parte do plano, não confissão de fracasso.

Em site de conteúdo grande, o passo 3 é o que consome o tempo, e é onde a conta aparece: o custo de atualizar o PHP raramente é o PHP. É o plugin que ninguém mantém mais e que segura o site inteiro num ramo encerrado. Quando isso aparece, o assunto deixa de ser versão e vira manutenção do que já está no ar.

Perguntas frequentes