O Adobe Commerce PHP 8.2 fim do suporte precisa entrar no planejamento das lojas que ainda executam a linha 2.4.6 com essa versão da linguagem. O prazo não significa que o e-commerce deixará de funcionar automaticamente, mas aumenta a exposição operacional e exige uma decisão sobre atualização da plataforma, infraestrutura e extensões.
A política de ciclo de vida da Adobe informa que o PHP 8.2 chega ao fim de vida em 31 de dezembro de 2026 e alerta que o Adobe Commerce 2.4.6 pode ficar em risco de conformidade PCI quando utiliza essa versão. A orientação é priorizar a migração para versões suportadas do Commerce e do PHP, além de avaliar a situação com o assessor de segurança qualificado da organização, conforme a política oficial de ciclo de vida do Adobe Commerce.
Quais lojas são afetadas pelo fim do suporte ao PHP 8.2?
O ponto de partida é descobrir a combinação realmente utilizada em produção. Ter o Adobe Commerce 2.4.6 no arquivo composer.json não confirma, sozinho, que o servidor web está executando PHP 8.2. Da mesma forma, consultar o PHP pelo terminal pode mostrar uma versão diferente daquela usada pelo PHP-FPM que atende a loja.
A operação merece atenção quando reúne estes fatores:
- utiliza Adobe Commerce 2.4.6;
- executa a aplicação em PHP 8.2;
- depende de módulos que ainda não foram validados em uma combinação posterior;
- processa pagamentos ou integra serviços sujeitos a controles de segurança e conformidade;
- não possui ambiente de homologação equivalente à produção;
- não tem uma atualização de plataforma planejada antes do prazo.
Lojas em outras versões também devem conferir o ambiente, mas não é seguro concluir a compatibilidade apenas pelo número principal do Magento. Edição, patch instalado, versão do PHP, bibliotecas, extensões e serviços de infraestrutura formam uma combinação que precisa ser analisada em conjunto.
Como confirmar a versão do PHP usada pelo Adobe Commerce
1. Consulte o PHP disponível no terminal
No diretório do projeto, execute:
php -v
which php
php --iniEsses comandos mostram a versão do binário chamado pela linha de comando, seu caminho e os arquivos de configuração carregados. Registre o resultado, mas não encerre o diagnóstico nesse ponto.
2. Verifique o serviço que atende as requisições web
Em ambientes com PHP-FPM, confira a versão do serviço, o socket ou a porta configurada no servidor web e o pool associado ao domínio. É comum encontrar mais de uma linha do PHP instalada durante migrações anteriores. Nesse cenário, o cron pode usar uma versão, o terminal outra e a vitrine uma terceira.
Evite publicar páginas permanentes com phpinfo(), pois elas podem revelar detalhes desnecessários do ambiente. Se a consulta temporária for indispensável, restrinja o acesso, remova o arquivo imediatamente após o teste e não o mantenha no repositório.
3. Compare produção, cron e homologação
Confirme a versão usada pelos processos agendados e pelos consumidores de filas. Uma atualização incompleta pode manter tarefas em um binário antigo, mesmo quando a vitrine já foi direcionada ao novo PHP. Também registre extensões carregadas, limites de memória e configurações relevantes para comparar os ambientes.
O PHP 8.2 sem suporte faz a loja parar?
Não há um desligamento automático da linguagem na data-limite. A aplicação pode continuar respondendo enquanto o servidor, os pacotes e os serviços permanecerem disponíveis. O problema é operar sobre uma base que saiu do período indicado de suporte, dificultando a manutenção segura e a sustentação da combinação tecnológica.
No caso do Adobe Commerce 2.4.6 com PHP 8.2, a Adobe destaca o possível risco de conformidade PCI e recomenda migrar para versões suportadas, com análise do assessor de segurança qualificado. Isso não equivale a declarar automaticamente toda loja não conforme: arquitetura, escopo, controles compensatórios e avaliação formal precisam ser examinados pela organização responsável, segundo a orientação publicada pela Adobe.
Também não é recomendável trocar somente o interpretador em produção. Uma versão mais nova do PHP pode expor incompatibilidades em módulos de pagamento, frete, antifraude, ERP, integrações fiscais, temas e customizações. O impacto pode aparecer apenas em fluxos específicos, sem deixar toda a loja indisponível.
Plano de migração do Adobe Commerce PHP 8.2 fim do suporte
1. Faça um inventário técnico
Registre edição e versão exata do Commerce, PHP da web e da CLI, Composer, banco, busca, cache, filas, servidor web, módulos instalados e integrações externas. Inclua customizações locais e pacotes mantidos em repositórios privados.
Se a loja ainda estiver em uma linha sem sustentação adequada, use o plano de migração do Adobe Commerce 2.4.5 como referência para organizar escopo, riscos e etapas, sem presumir que a mesma versão de destino serve para todos os projetos.
2. Escolha a combinação de destino
A decisão deve começar pela versão suportada do Adobe Commerce que a operação poderá manter, seguida pela versão de PHP compatível com ela. A Adobe recomenda priorizar uma versão suportada de ambos os componentes em sua política de ciclo de vida. Não defina o PHP isoladamente nem faça a troca com base apenas no que está disponível no provedor de hospedagem.
Se a estratégia considerar a linha 2.4.9, consulte o checklist de adequação de PHP, banco, busca e cache do Adobe Commerce 2.4.9. Uma atualização dessa dimensão pode exigir mudanças em vários serviços, não apenas na linguagem.
3. Analise as dependências com o Composer
Execute a análise em uma cópia controlada do projeto. Preserve composer.json e composer.lock, valide o acesso aos repositórios privados e descubra quais pacotes restringem a versão pretendida. Não apague o arquivo de bloqueio como primeira tentativa.
Comandos de diagnóstico, como os seguintes, podem ajudar:
composer check-platform-reqs
composer why-not php <versao-de-destino>
composer outdated --directO resultado deve ser interpretado no contexto do projeto. Um pacote compatível no Composer ainda pode apresentar falhas funcionais. Para localizar restrições sem atualizar tudo indiscriminadamente, veja também como investigar um conflito no Composer do Magento 2.
4. Monte uma homologação equivalente
Restaure uma cópia sanitizada do banco, replique configurações essenciais e utilize as mesmas famílias de serviços previstas para produção. Desative envios reais de e-mail, pagamentos, webhooks e integrações que possam movimentar estoque ou documentos fiscais.
Teste login, catálogo, busca, carrinho, cupons, cálculo de frete, checkout, meios de pagamento, criação de pedido, faturamento, expedição, cancelamento, reembolso, painel administrativo, APIs, cron e consumidores de filas. Para operações com várias lojas ou moedas, repita os cenários em cada escopo relevante.
5. Prepare implantação e reversão
Defina janela, responsáveis, backup verificado, critérios de aprovação e procedimento de retorno. O rollback precisa considerar código, dependências, banco e configuração de infraestrutura. Restaurar somente os arquivos pode não ser suficiente quando a atualização altera o esquema de dados.
Após a implantação, acompanhe logs da aplicação e do PHP-FPM, respostas 4xx e 5xx, filas, cron, taxa de aprovação dos pagamentos, criação de pedidos e tempos de resposta. Compare os indicadores com uma linha de base registrada antes da mudança.
O que não fazer perto do prazo
- não atualizar o PHP diretamente em produção sem validar a versão do Commerce;
- não presumir que a compatibilidade do núcleo cobre todas as extensões;
- não ignorar diferenças entre PHP da CLI, cron e servidor web;
- não remover módulos sem avaliar dados, configurações e dependências;
- não tratar conformidade PCI apenas como uma tarefa de infraestrutura;
- não deixar checkout e pagamentos para o último teste.
Perguntas frequentes
Quais versões do Adobe Commerce usam PHP 8.2?
A combinação confirmada no alerta analisado é o Adobe Commerce 2.4.6 com PHP 8.2. Para qualquer instalação, consulte a edição, o patch exato e a matriz correspondente antes de escolher a versão de destino.
Como descobrir a versão do PHP usada pelo Magento em produção?
Use php -v para verificar a CLI e confira separadamente o serviço PHP-FPM, o pool e a configuração do servidor web. Verifique também os binários chamados pelo cron e pelos consumidores de filas.
O PHP 8.2 sem suporte impede a loja de funcionar?
Não automaticamente. A loja pode continuar respondendo, mas passa a operar com riscos adicionais de manutenção, segurança e conformidade. No cenário citado pela Adobe, o Commerce 2.4.6 com PHP 8.2 pode ficar em risco de conformidade PCI.
Como testar módulos antes de migrar para um PHP mais novo?
Comece pelas restrições do Composer e depois valide os fluxos funcionais em homologação. Dê prioridade a checkout, pagamentos, frete, antifraude, ERP, rotinas fiscais, cron, filas, APIs e customizações locais.
Conclusão
O Adobe Commerce PHP 8.2 fim do suporte não deve ser tratado como uma simples troca de pacote no servidor. A preparação correta combina inventário, definição de uma versão suportada do Commerce, análise das dependências, homologação funcional, avaliação de PCI e um plano real de reversão.
Se sua equipe ainda não sabe qual PHP atende a vitrine, o cron e as filas, comece pelo diagnóstico. Para revisar a arquitetura, identificar incompatibilidades e planejar a atualização sem colocar o checkout em risco, solicite uma avaliação técnica especializada.
Fontes consultadas
As informações atuais mencionadas neste artigo foram verificadas nas fontes abaixo.
