Em resumo: O modo mais seguro de desativar versões antigas do PHP é em três fases: apurar a utilização, bloquear a versão e observar, só depois desinstalar. No Plesk, um handler pode primeiro ser desativado, de modo que já não possa ser escolhido, e mais tarde removido em Atualizações e componentes. Cada versão removida é menos uma a que terá de aplicar patch e reiniciar na próxima vulnerabilidade, como o PHP2Shell.
Porque limpar justamente agora?
A semana a seguir ao PHP2Shell mostrou a muitos administradores quantas versões do PHP estão instaladas nos seus servidores. Cada uma teve de ser verificada, cada uma precisou de uma atualização ou de medidas provisórias, cada serviço de um reinício. Para o PHP 8.1 e anteriores existem apenas backports mínimos do código-fonte; para o PHP 8.2, o suporte termina a 31/12/2026.
Com esta experiência fresca na memória, é o momento certo para limpar. Como encontrar todas as instalações está descrito no artigo Várias versões do PHP num servidor. Aqui trata-se do passo seguinte: a desativação controlada.
Fase 1: apurar a utilização
Antes de desativar alguma coisa, tem de saber quem usa uma versão. Os sites são a parte óbvia. Menos visíveis são os subdomínios, as instalações de teste, as tarefas cron, os scripts e os componentes do painel.
No Plesk, o comando plesk bin php_handler --list lista todos os handlers registados. Com --get-usage, o Plesk mostra, segundo a documentação, que domínios usam um determinado handler. Nenhum dos dois comandos altera nada.
# Plesk: todos os handlers e os domínios que usam um handler
plesk bin php_handler --list
plesk bin php_handler --get-usage -id <handler-id>
# Em geral: tarefas cron que chamam uma determinada versão do PHP
grep -rE "php(7|8\.0|8\.1)" /etc/crontab /etc/cron.d /var/spool/cron 2>/dev/null
Verifique ainda os registos de acesso dos sites em causa: uma instalação de teste que há meses não recebe qualquer pedido é candidata a ser removida, não migrada. Anote, para cada versão antiga, quem a usa e porquê.
Pergunte também às pessoas que trabalham com os sites. Redações, agências e departamentos conhecem muitas vezes processos que não constam de nenhuma lista: a exportação anual para a contabilidade, o formulário para uma feira, a interface com o sistema de gestão de mercadorias. O que aí depende de uma versão antiga só se nota quando falta.
Fase 2: bloquear e observar
O passo intermédio impede que uma versão volte a ser atribuída, sem a apagar de imediato. No Plesk há a possibilidade de desativar handlers individuais. Segundo a documentação do Plesk, um handler desativado já não pode ser escolhido nas definições de PHP de um site; a versão continua instalada. Na linha de comandos faz-se com plesk bin php_handler --disable -id <handler-id>.
Os domínios que ainda usam a versão antiga, passe-os antes, em articulação com os responsáveis, para uma versão suportada. Como isto se apresenta do ponto de vista do operador do site está descrito no artigo Alterar a versão do PHP na área de cliente do alojamento. A escolha do handler adequado é explicada no artigo Plesk: compreender os handlers do PHP.
Durante o período de observação, esteja atento a mensagens de erro nos registos, à ausência de resultados de tarefas cron e a comentários dos utilizadores. Noutros painéis as funções têm outros nomes; consulte aí a documentação do fabricante.
Defina o fim do período de observação como uma data e indique quem autoriza depois a desinstalação. Caso contrário, o passo intermédio torna-se um estado permanente e a versão antiga acaba por ficar no servidor.
Fase 3: desinstalar
Só depois de o período de observação passar sem anomalias é que remove a versão por completo. No Plesk, segundo a documentação, faz-se em Tools & Settings, Updates, Add/Remove Components, na área Web hosting, nas versões do interpretador PHP. As versões instaladas estão aí assinaladas e podem ser selecionadas para remoção.
Em servidores sem painel, é o gestor de pacotes que trata disto. Antes, guarde a configuração da versão, por exemplo /etc/php/7.4/ no Debian e no Ubuntu, para poder reconstituir numa emergência que definições estavam em vigor.
# Guardar a configuração e depois remover os pacotes de um ramo (exemplo Debian/Ubuntu, PHP 7.4)
tar czf /root/php74-konfiguration.tar.gz /etc/php/7.4/
apt remove 'php7.4*'
Depois da remoção, vale a pena um controlo. No Plesk, a documentação recomenda plesk bin php_handler --reread para reler as informações dos handlers depois de alterações aos binários do PHP. Verifique ainda se os planos de serviço continuam a apontar para a versão removida.
Obstáculos típicos
| Obstáculo | Como o reconhece | O que ajuda |
|---|---|---|
| Componente do painel depende da versão | O painel comunica uma dependência ao remover | Primeiro migrar o componente ou manter a versão |
| Plano de serviço aponta para versão antiga | Os novos sites recebem a versão antiga ou uma mensagem de erro | Adaptar o plano e depois remover a versão |
| Tarefa cron chama um caminho fixo | O script falha depois da remoção | Alterar o caminho para uma versão suportada |
| A aplicação não corre na versão nova | Erro no registo de erros depois da migração | Atualizar ou migrar a aplicação |
Se uma aplicação não puder passar para uma versão suportada, desativar a versão antiga deixa de ser uma questão de configuração e passa a ser um projeto de migração. Os riscos dos ramos desatualizados estão descritos no guia Fim de vida do PHP: riscos das versões desatualizadas.
O próximo candidato já está definido
Limpar não é uma ação única. Já a 31/12/2026 o PHP 8.2 deixa de ter o suporte do projeto PHP. Quem agora remove versões até à 8.1 deve definir ao mesmo tempo o que fazer com a 8.2. Caso contrário, o mesmo jogo recomeça dentro de poucas semanas.
Uma regra simples revelou-se útil para o servidor: só são oferecidos ramos que o projeto PHP suporta. Cada ramo recebe, ao ser configurado, uma data em que volta a ser verificado, com base no fim de suporte no php.net. Os antecedentes deste ciclo estão explicados na página Versões do PHP e ciclo de lançamento.
Quem, como fornecedor de alojamento ou agência, tem clientes no servidor deve informá-los cedo. Um aviso com data, o pedido de migração e uma oferta de apoio evitam que sites falhem no dia limite. Os clientes cuja aplicação não acompanha reconhecem assim a tempo que está pendente uma atualização ou uma migração e podem planear em conformidade.
Como ajuda concretamente a PHP SOS?
- Apuramos que sites, tarefas cron e componentes do painel usam que versão do PHP.
- Passamos os domínios, em articulação consigo, para versões suportadas e bloqueamos os handlers antigos.
- Após o período de observação, removemos as versões antigas de forma controlada e verificamos o resultado.
- Onde as aplicações não acompanham, planeamos a migração do PHP 8.1 e anteriores.
Perguntas frequentes
Porque devo remover versões do PHP que não são usadas?
Cada versão instalada tem de ser verificada, atualizada e reiniciada a cada vulnerabilidade. Os ramos antigos, como o PHP 8.1 e anteriores, já não recebem atualizações do projeto PHP. As versões não usadas só trazem risco e trabalho.
Qual é a diferença entre desativar e desinstalar?
Ao desativar, a versão continua instalada, mas já não pode ser escolhida de novo. Ao desinstalar, é removida do servidor. Desativar é o passo intermédio seguro para ver se algo falha.
Remover uma versão do PHP pode perturbar funções do painel?
Sim. Alguns componentes de um painel, como o webmail ou ferramentas de administração, dependem de uma determinada versão do PHP. Esclareça essas dependências antes de remover; o painel costuma avisar.
Quanto tempo deve durar o período de observação?
O suficiente para que todos os processos regulares tenham corrido pelo menos uma vez, incluindo tarefas cron e exportações mensais. Defina a duração com os departamentos envolvidos.