Por que ordem atualizar o PrestaShop, o PHP, o tema e os módulos sem estragar a loja

Uma loja PrestaShop tem quatro peças que envelhecem a ritmos diferentes: o núcleo, a versão de PHP do servidor, o tema e os módulos. Cada uma tem as suas próprias versões e cada uma exige algo das outras. Se as atualizar por qualquer ordem, mais cedo ou mais tarde chega a uma combinação que não funciona: um módulo que não arranca com o PHP novo, um tema que chama uma função que o núcleo já não tem ou um núcleo que não se instala porque o PHP é demasiado antigo.

A boa notícia é que a ordem correta deduz-se quase sempre de uma única regra. Vamos a ela e ao procedimento completo.

A regra: nunca passar por uma combinação sem suporte

Cada versão do PrestaShop admite um intervalo de versões de PHP. Cada módulo e cada tema declaram (ou deveriam declarar) com que versões do PrestaShop e de PHP funcionam. Atualizar bem consiste em avançar por passos de forma a que, depois de cada passo, todas as peças continuem dentro do que suportam.

Isto tem uma consequência prática: quase nunca pode saltar diretamente para o fim. Se a sua loja está numa versão antiga com um PHP antigo, e a versão de destino exige um PHP mais moderno que a de origem não suporta, precisa de um passo intermédio. Às vezes é uma versão intermédia do núcleo; outras, um PHP intermédio que ambas admitam.

Antes de mexer em qualquer coisa: inventário

Faça uma tabela com tudo o que a loja tem. Sem ela, a ordem é um palpite.

• Versão exata do núcleo e versão de PHP usada pelo site (que pode não ser a mesma do terminal do servidor).
• Tema: se é o de origem, um comprado ou um feito à medida, se tem tema filho e quem o mantém.
• Módulos instalados, com versão, autor e de onde foram descarregados. Assinale os que já não usa: não é para os atualizar, é para os retirar.
• Overrides na pasta override/. São os primeiros a partir-se quando o núcleo muda, porque substituem classes inteiras ou métodos cuja assinatura pode ter mudado.
• Integrações externas: ERP, gateways de pagamento, marketplaces, transportadoras. Cada uma é um módulo ou um script que também depende de versões.

Para cada módulo, anote a última versão compatível com o seu núcleo atual e com o de destino. Os que não têm versão para o destino são o verdadeiro trabalho do projeto: é preciso procurar um substituto, pedi-la ao autor ou adaptá-los.

A ordem que funciona na maioria dos casos

1. Cópia completa de ficheiros e base de dados, e confirme que é possível restaurá-la.
2. Retire o que sobra. Módulos desinstalados que continuam no disco, módulos instalados que ninguém usa, overrides órfãos. Cada peça que retira é menos uma peça para atualizar e testar.
3. Atualize os módulos dentro da sua versão atual até à última versão que a suporte. Muitas vezes essa mesma versão já funciona também no núcleo de destino, e assim o grande salto faz-se com módulos modernos.
4. Atualize o tema para a última versão compatível com o seu núcleo atual, se o fabricante a tiver. Se for um tema à medida, reveja antes os templates que mais mudam entre versões: checkout, carrinho e página de produto.
5. Atualize o núcleo, primeiro para a última revisão do seu ramo e depois, se for o caso, para o ramo seguinte.
6. Mude a versão de PHP para a mais moderna que o novo núcleo suporte e que todos os seus módulos admitam.
7. Volte a rever módulos e tema: alguns têm uma versão específica para o novo ramo que só pode ser instalada quando o núcleo já está atualizado.

Porquê numa cópia e não em produção

Tudo o que foi dito ensaia-se primeiro numa cópia da loja, com os mesmos ficheiros, a mesma base de dados e, se possível, o mesmo PHP e a mesma configuração de servidor. Na cópia pode enganar-se, voltar atrás e repetir. Em produção, cada tentativa falhada é vista pelos seus clientes.

Durante o ensaio, registe cada passo com detalhe suficiente para o repetir: que módulo foi atualizado, por que ordem, que definição foi preciso alterar à mão, que ficheiro do tema foi corrigido. No dia da mudança não se improvisa: repete-se a lista.

O que testar depois de cada passo

• Página inicial, uma categoria com filtros, uma página de produto com combinações e o motor de pesquisa.
• Registo de cliente, início de sessão e recuperação de palavra-passe.
• Uma encomenda completa com cada método de pagamento, no modo de testes de cada gateway, até ver a encomenda no estado correto.
• Os e-mails enviados ao cliente (sem que cheguem a ninguém de verdade: na cópia o correio deve estar capturado).
• Back-office: lista de encomendas, ficha de uma encomenda, fatura em PDF, edição de um produto.
• O registo de erros do PHP e o do PrestaShop: o que não parte a página também conta.

O que costuma partir-se

• Overrides que redefinem métodos do núcleo que mudaram. O sintoma é um erro fatal logo após a atualização, às vezes só numa página concreta.
• Módulos de pagamento em versões antigas que usam hooks ou classes retirados. São os mais delicados, porque a falha pode estar no regresso do gateway: o cliente paga e a encomenda não é criada.
• Templates do tema que esperam variáveis que o núcleo já não envia ou que têm outro nome.
• Funções de PHP retiradas ou comportamentos que passam de aviso a erro ao subir de versão. Um módulo que funcionava com os avisos silenciados pode deixar de funcionar por completo.
• Caches que conservam classes compiladas da versão anterior. Esvaziá-las faz parte do procedimento, não é um truque de última hora.

A janela da mudança

Com o ensaio feito, escolha quando aplicá-lo em produção:

• Um momento de pouco tráfego que possa confirmar nas suas estatísticas, não o que todos supõem.
• Longe de campanhas e de dias de muitos envios. Não atualize na véspera dos saldos nem numa sexta-feira à tarde se na segunda-feira não houver ninguém para verificar.
• Com as pessoas disponíveis: quem faz a mudança, quem testa os pagamentos e quem pode ligar para o alojamento se for preciso.
• Com um plano de reversão escrito: que cópia se restaura, quanto tempo demora e a partir de que sintoma se decide voltar atrás. Se a loja recebeu encomendas entre a cópia e a reversão, é preciso saber como recuperá-las.

Coloque a loja em manutenção durante a mudança, deixando o seu IP com acesso para testar, e não a abra até ter completado a mesma lista de testes do ensaio.

Depois da mudança

Os primeiros dias são de vigilância. Reveja o registo de erros, compare as encomendas com os pagamentos do gateway e pergunte à equipa de apoio ao cliente se chegam pedidos estranhos. Muitas falhas de uma atualização não aparecem na primeira hora, mas sim quando alguém usa pela primeira vez uma função pouco habitual: um cupão concreto, uma transportadora que só aparece para certas províncias ou uma nota de crédito.

E deixe registado o estado final no inventário. A próxima atualização começa por aí, e será muito mais curta se não deixar passar anos entre uma e outra.

Como resolver no PrestaShop

Na Rekire fazemos este trabalho todos os dias, desde uma atualização de revisão dentro do mesmo ramo até uma migração entre versões principais. Com um pacote de horas de suporte (20 ou 50 horas, conforme a dimensão da loja) preparamos o inventário de núcleo, PHP, tema e módulos, montamos a cópia de testes, ensaiamos a ordem de atualização com a respetiva lista de testes e aplicamos a mudança em produção na janela que escolher. As horas são consumidas conforme o trabalho real, por isso pode começar pelo inventário e decidir depois até onde ir.