Desde 1º de janeiro de 2026, o PHP 8.1 não recebe nenhuma correção de segurança, e o PHP 8.2 vai pelo mesmo caminho em 31 de dezembro de 2026. Se o seu site ainda roda em uma dessas versões, chegou a hora de mudar a versão do PHP no cPanel. Este guia ajuda você a escolher entre PHP 8.3, 8.4 e 8.5, testar a nova versão em uma cópia do site e depois trocar o site em produção, com a opção de voltar atrás em um clique.
Por que atualizar o PHP agora
O PHP segue um ciclo de vida fixo: cada versão recebe dois anos de correções de bugs (suporte ativo) e depois dois anos apenas de correções de segurança. Passado esse prazo, falhas novas deixam de ser corrigidas. Um site WordPress ou PrestaShop parado em uma versão sem suporte fica exposto a vulnerabilidades conhecidas e públicas.
Há também um lado prático: plugins e temas recentes vão abandonando as versões antigas do PHP, e cada nova versão traz ganho de desempenho. Ficar para trás acaba travando as atualizações do próprio CMS.
O calendário oficial do PHP
Estas datas vêm do projeto PHP no php.net (páginas “Supported Versions” e “Unsupported Branches”), conferidas em outubro de 2026:
| Versão | Lançamento | Fim do suporte ativo | Fim das correções de segurança | Situação em outubro de 2026 |
|---|---|---|---|---|
| PHP 8.1 | novembro de 2021 | 25 de novembro de 2023 | 31 de dezembro de 2025 | Sem suporte (última versão: 8.1.34) |
| PHP 8.2 | 8 de dezembro de 2022 | 31 de dezembro de 2024 | 31 de dezembro de 2026 | Só segurança, faltam poucas semanas |
| PHP 8.3 | 23 de novembro de 2023 | 31 de dezembro de 2025 | 31 de dezembro de 2027 | Só segurança |
| PHP 8.4 | 21 de novembro de 2024 | 31 de dezembro de 2026 | 31 de dezembro de 2028 | Suporte ativo |
| PHP 8.5 | 20 de novembro de 2025 | 31 de dezembro de 2027 | 31 de dezembro de 2029 | Suporte ativo |
Na prática, o PHP 8.4 é hoje o melhor equilíbrio: tem cobertura até o fim de 2028 e é amplamente suportado por CMS e plugins. O PHP 8.5 dá um ano a mais, desde que todo o seu ambiente seja compatível. O PHP 8.3 é um passo intermediário aceitável se algum plugin estiver segurando a atualização, mas o suporte dele termina já no fim de 2027.
Qual versão escolher para o seu CMS
WordPress
Segundo o manual oficial do WordPress (“PHP Compatibility and WordPress Versions”), o WordPress 6.9 e as versões seguintes suportam o PHP 8.5, e o PHP 8.4 é suportado desde o WordPress 6.7. O rótulo de “suporte beta” que o WordPress usava para essas versões foi aposentado em maio de 2026. Desde o WordPress 7.0, a versão mínima exigida do PHP é a 7.4.
Mas o núcleo do WordPress é só metade da história: quem costuma quebrar numa troca de PHP são os plugins e o tema. Confira em cada plugin o campo “Requer PHP” e a data da última atualização. Um plugin sem atualização há dois anos é um risco.
PrestaShop
A documentação oficial do PrestaShop traz uma tabela de compatibilidade precisa:
| PrestaShop | PHP 8.1 | PHP 8.2 | PHP 8.3 | PHP 8.4 | PHP 8.5 |
|---|---|---|---|---|---|
| 8.0 a 8.2 | Recomendado | Não suportado | Não suportado | Não suportado | Não suportado |
| 9.0 | Sim | Sim | Sim | Recomendado | Não suportado |
| 9.1 | Sim | Sim | Sim | Sim | Recomendado |
O ponto principal: uma loja PrestaShop 8 está presa ao PHP 8.1, uma versão que não recebe mais correções. A saída é migrar primeiro a loja para o PrestaShop 9 e só depois mudar a versão do PHP. Fazer o contrário (PHP 8.3 com PrestaShop 8) quase sempre termina em erros. O PrestaShop 9 também exige várias extensões PHP (intl, gd, zip, curl, mbstring, fileinfo, entre outras) e recomenda um memory_limit de pelo menos 512M.
O que pode quebrar ao migrar para o PHP 8.4 ou 8.5
Entre as versões menores do PHP 8, as mudanças são principalmente depreciações: o código continua funcionando, mas grava avisos nos logs. As quedas de verdade costumam vir de módulos antigos ou de extensões PHP ausentes. Estas são as depreciações que mais afetam plugins do WordPress e módulos do PrestaShop:
- PHP 8.4: parâmetros implicitamente anuláveis (
function f(Type $a = null)precisa virar?Type $a = null), uso deE_USER_ERRORcomtrigger_error(), a constanteE_STRICTe chamadas afgetcsv()oufputcsv()sem informar o parâmetroescape. - PHP 8.5: casts não canônicos como
(integer)ou(boolean), o operador de crase que executa comandos do sistema, o uso denullcomo chave de array, a variável$http_response_headere algumas constantes PDO específicas do MySQL, substituídas pelos equivalentes emPdo\Mysql.
Mesmo assim, a causa mais comum de página em branco ou erro 500 logo após a troca é uma extensão PHP ausente na nova versão: cada versão do PHP instalada no servidor tem as próprias extensões. Se intl ou imagick estão ativas no PHP 8.2 mas não no PHP 8.4, o seu CMS vai falhar no 8.4.
Passo 1: faça um inventário antes de mexer em qualquer coisa
- Anote a versão atual do PHP de cada domínio. Ela aparece na ferramenta MultiPHP Manager do cPanel (seção Software).
- Atualize o CMS, o tema e todos os plugins ou módulos antes de mudar a versão do PHP. As atualizações muitas vezes já resolvem as incompatibilidades.
- Faça um backup completo de arquivos e banco de dados. A ferramenta Backup (ou o Assistente de backup) do cPanel permite baixar um arquivo do diretório inicial e uma exportação de cada banco MySQL.
- Identifique os plugins abandonados e procure alternativas mantidas.
Passo 2: teste a nova versão em uma cópia do site
É a etapa que a maioria dos tutoriais pula. O MultiPHP Manager define a versão do PHP por domínio e por subdomínio, então você pode rodar uma cópia do site no PHP 8.4 enquanto o site principal continua na versão atual.
- Crie um subdomínio de teste, por exemplo
teste.seusite.com.br, pela interface Domínios do cPanel, com uma pasta raiz própria. - Copie o site: no WordPress, o recurso de staging do Softaculous faz isso em poucos cliques, se a sua hospedagem oferecer. Se não, copie os arquivos com o Gerenciador de arquivos (compactar, mover, extrair) e duplique o banco com o phpMyAdmin (exportar e importar em um banco novo).
- Ajuste a configuração da cópia: nome do banco no
wp-config.php(WordPress) ou noapp/config/parameters.php(PrestaShop) e o endereço do site (opçõessiteurlehomeno WordPress, URL da loja na tabelaps_shop_urlno PrestaShop). - Proteja a cópia com a ferramenta Directory Privacy do cPanel (senha), para que ela não seja indexada nem fique pública.
- Mude apenas o subdomínio de teste para a nova versão do PHP no MultiPHP Manager.
Em seguida, ative o log de erros na cópia. No WordPress, dentro do wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true ); // grava em wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // não mostra nada aos visitantes
No PrestaShop, ative o modo de depuração em Parâmetros avançados > Desempenho. Depois percorra as páginas principais: início, página de produto, carrinho, checkout em modo de teste, formulário de contato, login no painel, envio de um e-mail. Confira o debug.log, os arquivos error_log nas pastas do site e a ferramenta Erros do cPanel. Uma linha “Deprecated” não impede nada; uma linha “Fatal error” impede.
Passo 3: mude a versão do PHP no cPanel
Com a cópia aprovada, trocar o site em produção leva menos de um minuto:
- Entre no cPanel e abra o MultiPHP Manager na seção Software.
- Marque a caixa do domínio que deseja alterar (dá para marcar vários).
- Escolha a versão no menu PHP Version, no canto superior direito. As versões aparecem como
PHP 8.4 (ea-php84); as marcadas como “Recommended” são as indicadas pelo administrador do servidor. - Clique em Apply. A coluna de versão do domínio é atualizada na hora.
Nos bastidores, o cPanel adiciona um bloco ao arquivo .htaccess na raiz do domínio. Não edite esse bloco à mão, o cPanel o reescreve:
# php -- BEGIN cPanel-generated handler, do not edit
# Set the "ea-php84" package as the default "PHP" programming language.
<IfModule mime_module>
AddHandler application/x-httpd-ea-php84 .php .php8 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit
Se um domínio mostra “Inherited”, ele usa a versão padrão do servidor, definida pela hospedagem, que pode mudar sem nenhuma ação sua. É mais seguro definir explicitamente a versão de cada site.
Para confirmar a versão realmente em uso, coloque temporariamente na raiz do site um arquivo com nome difícil de adivinhar, abra no navegador e depois apague:
<?php echo PHP_VERSION;
Se a versão desejada não aparece
Uma versão que não está no menu não está instalada no servidor ou não está liberada para a sua conta. A instalação é feita no servidor, pelo EasyApache 4, então você não consegue adicioná-la sozinho pelo cPanel: fale com o suporte da sua hospedagem. Algumas hospedagens também oferecem a ferramenta “Select PHP Version”, que permite trocar de versão e ativar ou desativar extensões PHP por conta própria.
Passo 4: confira as configurações do PHP depois da troca
Cada versão do PHP tem sua própria configuração padrão. Depois da mudança, abra o MultiPHP INI Editor (ao lado do MultiPHP Manager), selecione o domínio e confira pelo menos:
memory_limit: 256M para WordPress com construtor de páginas, no mínimo 512M para PrestaShop 9;upload_max_filesizeepost_max_size: de acordo com o tamanho das suas mídias;max_execution_time: aumente se importações de produtos ou backups forem interrompidos;display_errors: desativado em produção.
Por fim, limpe todos os caches: o plugin de cache do WordPress, o cache Smarty e Symfony do PrestaShop (Parâmetros avançados > Desempenho > Limpar cache) e o cache da CDN, se você usar uma.
Como voltar atrás se algo der errado
Mudar a versão do PHP não mexe nos seus arquivos nem no banco de dados. Se aparecer algum problema, volte ao MultiPHP Manager, marque o domínio, escolha a versão anterior e clique em Apply: o site volta ao estado anterior em segundos. Só não esqueça o prazo: voltar para o PHP 8.2 só dá tempo até 31 de dezembro de 2026 para resolver o problema.
Perguntas frequentes
Mudar a versão do PHP pode apagar meu site?
Não. O MultiPHP Manager muda apenas o interpretador que executa os seus arquivos. Conteúdo, arquivos e banco de dados continuam intactos, e a volta para a versão anterior é imediata.
Dá para usar uma versão diferente em cada site?
Sim. O MultiPHP Manager funciona domínio por domínio: um blog WordPress pode rodar no PHP 8.5 e uma loja PrestaShop 9.0 no PHP 8.4 na mesma conta do cPanel. Domínios estacionados (aliases) seguem o domínio principal.
Meu site mostra erro 500 depois da troca. E agora?
Primeiro volte para a versão anterior para restabelecer o site. Depois consulte a ferramenta Erros do cPanel ou o arquivo error_log: a causa quase sempre é uma extensão PHP ausente na nova versão ou um módulo incompatível. Corrija na cópia de teste antes de tentar de novo.
PHP 8.5 ou PHP 8.4?
Se o seu site usa WordPress atualizado ou PrestaShop 9.1 e todos os plugins são compatíveis, o PHP 8.5 dá a maior folga (correções de segurança até o fim de 2029). Para PrestaShop 9.0, ou se um plugin importante ainda não confirma compatibilidade, escolha o PHP 8.4.