Actualizar o PHP sem partir o site
O PHP 8.2 deixa de ter correcções a 31 de Dezembro. Em que versão está o seu site, porque é que a mudança pode partir algo e como actualizar o PHP sem sustos.
A falha PHP2Shell deixou uma lição incómoda para muitas empresas: quem tinha o site no PHP 8.1 ou anterior não recebeu correcção oficial. E o calendário não pára. O PHP 8.2 deixa de ter correcções de segurança a 31 de Dezembro de 2026, daqui a dois meses.
A razão por que tantos sites ficam em versões antigas é quase sempre a mesma: medo de que o site deixe de funcionar. É um medo justificado, mas tem solução. Este é o guia para mudar de versão sem sustos.
Em que ponto está cada versão
Cada versão do PHP tem dois anos de suporte activo e mais dois só com correcções de segurança. Depois disso, deixa de receber correcções, mesmo para falhas graves. O calendário oficial, segundo o php.net:
| Versão | Correcções de segurança até | Situação |
|---|---|---|
| 8.5 | 31-12-2029 | Suporte completo |
| 8.4 | 31-12-2028 | Suporte completo até ao fim de 2026 |
| 8.3 | 31-12-2027 | Só segurança |
| 8.2 | 31-12-2026 | Só segurança, a terminar |
| 8.1 | 31-12-2025 | Sem suporte |
| 8.0 | 26-11-2023 | Sem suporte |
| 7.4 | 28-11-2022 | Sem suporte |
O próprio WordPress recomenda o PHP 8.3 ou posterior. Hoje, a escolha sensata para um site que vai mudar é o 8.4: tem correcções garantidas até ao fim de 2028 e já está estabilizado. O 8.5 também é uma boa opção quando o tema e os plugins já o suportam.
Primeiro, saber de onde parte
- WordPress: Ferramentas → Saúde do site → Informação → Servidor mostra a versão exacta. A própria Saúde do site avisa quando a versão está desactualizada.
- cPanel ou Plesk: o painel mostra o ramo escolhido (por exemplo, 8.1) e, em regra, permite mudar por domínio.
- Site feito à medida ou servidor próprio: quem fez o site deve saber dizer a versão e se o código foi testado em versões recentes. Se ninguém sabe, isso já é informação útil.
Porque é que a mudança pode partir o site
Cada versão nova do PHP retira funções antigas e torna-se mais rigorosa com código descuidado. O núcleo do WordPress acompanha estas mudanças, mas um site é mais do que o núcleo: um tema comprado há anos, um plugin abandonado pelo autor ou um bocado de código feito à medida podem usar funções que já não existem. O resultado vai de avisos no ecrã a uma página em branco, ou a um erro que só aparece no checkout de uma loja.
Quanto mais antiga a versão de partida, maior o salto. Passar do 7.4 para o 8.4 é muito diferente de passar do 8.2 para o 8.3.
Como mudar sem sustos
- Faça uma cópia de segurança completa, ficheiros e base de dados, guardada fora do servidor. Confirme que a sabe repor. Explicámos como em Cópias de segurança: como saber se o site volta.
- Actualize primeiro tudo o resto: WordPress, tema e plugins, ainda na versão antiga do PHP. Versões recentes dos plugins são as que suportam o PHP novo.
- Faça uma lista do que não tem actualizações há muito tempo. Um plugin sem actualizações há anos é o suspeito mais provável e, muitas vezes, pode ser substituído ou removido.
- Teste numa cópia do site (um ambiente de testes, ou staging), com a versão nova do PHP. Muitos alojamentos criam esta cópia com um clique.
- Percorra o que dá dinheiro: formulários de contacto, pesquisa, carrinho, pagamento, área de cliente, envio de emails. Não basta a página inicial abrir.
- Veja os registos de erros da cópia de testes. Avisos de funções obsoletas indicam o que vai partir na versão seguinte.
- Mude o site real num horário calmo e volte a testar o mesmo percurso. Se algo correr mal, voltar à versão anterior no painel demora segundos, desde que não tenha apagado nada.
Quando a mudança não é possível
Às vezes, o site depende de código que não funciona em versões recentes e não tem quem o corrija. Nesse caso, há três saídas, por ordem de preferência: corrigir ou substituir a peça que impede a mudança; refazer o site, quando o custo de remendar já é maior do que o de construir de novo; ou, como último recurso temporário, um fornecedor que ofereça suporte prolongado para versões antigas. Deixar ficar como está não é uma opção: a próxima falha grave vai encontrar o site sem correcção.
O que pedir ao alojamento
- Que versões do PHP disponibiliza e quando retira as antigas.
- Se aplica as correcções de segurança dentro de cada versão (por exemplo, do 8.4.26 para o 8.4.27) automaticamente e em quanto tempo.
- Se tem ambiente de testes e cópias de segurança automáticas, e por quanto tempo as guarda.
Se as respostas forem vagas, é um bom sinal de que está na altura de mudar de alojamento, ou de entregar o servidor a quem o mantenha.
Quer que tratemos disto?
A MarcaWeb actualiza sites WordPress e à medida para versões suportadas do PHP, com testes antes da mudança, e mantém os servidores actualizados depois disso. Veja o que fazemos em cibersegurança, comece pela auditoria gratuita ou escreva para info@marcaweb.pt.
Fontes: php.net, versões suportadas e versões sem suporte; WordPress, requisitos (consultados a 23-10-2026).
