Atualizar o PrestaShop sem partir a loja: guia passo a passo

Para atualizar o PrestaShop sem partir a loja é preciso seguir sempre a mesma ordem: cópia completa dos ficheiros e da base de dados, ensaio da atualização numa cópia da loja, atualização real num período de pouco tráfego e revisão do checkout, do correio e dos módulos antes de dar o trabalho por terminado. O assistente oficial faz a parte mecânica; o que evita os sustos é tudo o que está à volta.

Este artigo trata das atualizações «de manutenção»: dentro do mesmo ramo (8.1 para 8.2) ou para a versão menor seguinte (9.0 para 9.1). Um salto da 1.6 ou 1.7 para a 9 é outra coisa, um projeto de migração, e tratamo-lo à parte.

Atualizar ou migrar: não é o mesmo

Usam-se como sinónimos e não o são, e confundi-los leva a planear mal:

• Atualizar é substituir o núcleo do PrestaShop por uma versão mais recente na mesma loja. Os dados, o tema e os módulos ficam; a base de dados adapta-se com os scripts da versão nova.
• Migrar é levar a loja para uma versão com alterações de fundo (ou para outro servidor), onde o tema, parte dos módulos e os overrides se refazem e o que se conserva são sobretudo os dados.

Entre versões próximas, atualizar é o normal e o recomendável. Quanto mais tempo passa sem o fazer, mais cada atualização se parece com uma migração: mais módulos sem versão compatível, mais alterações acumuladas no tema e mais distância na versão de PHP.

Antes de mexer em nada: o inventário

Dez minutos de inventário poupam horas no dia da atualização. Anote:

• Versão atual do PrestaShop e do PHP, e que versão de PHP exige a versão para a qual vai. Consulte os requisitos dessa versão antes de tudo: se o servidor não os cumprir, primeiro vem a mudança de PHP, testada também numa cópia.
• Tema: se é o de origem, um tema filho ou um tema comprado, e se alguém editou diretamente os seus modelos.
• Módulos de terceiros, com a versão e se o autor declara compatibilidade com a versão de destino.
• Overrides na pasta override/: cada um é código que substitui uma parte do núcleo e que pode deixar de encaixar.
• Alterações manuais em ficheiros do núcleo: linhas acrescentadas em config/, regras no .htaccess, proteção por palavra-passe da pasta de administração. A atualização sobrescreve-as.
• Integrações que comunicam com a loja: ERP, marketplaces, transportadoras, o webservice.

A cópia completa, e verificada

O assistente de atualização oferece-se para fazer a sua própria cópia, e é bom que a faça, mas não deveria ser a única. Antes de começar, faça uma cópia sua de todos os ficheiros e da base de dados, guarde-a fora do servidor e verifique que pode ser restaurada. Uma cópia que ninguém restaurou é uma esperança, não uma cópia.

O ensaio numa cópia da loja

A regra que mais dissabores evita: a atualização faz-se primeiro numa cópia, noutro servidor ou num ambiente local, com os mesmos ficheiros e a mesma base de dados que a produção. Aí vê-se que módulo falha, que modelo do tema dá erro e quanto tempo demora o processo, que é o dado de que precisa para escolher o horário certo.

Na cópia convém desativar tudo o que possa sair para fora: o correio (que vá para uma caixa de testes e não para os seus clientes), os gateways de pagamento (em modo de teste), as tarefas agendadas que comunicam com terceiros e as integrações que enviam encomendas para o ERP. Uma cópia da loja com o correio real configurado pode escrever a clientes verdadeiros com uma simples mudança de estado de encomenda.

Durante a atualização: o que vimos falhar

O assistente oficial do PrestaShop (o módulo de atualização num clique) funciona bem na maioria das lojas, mas há situações que se repetem em lojas reais:

• Fechar o navegador a meio. O assistente avança por passos a partir da própria página do back-office. Se o separador for fechado ou a ligação cair, o processo para. Deixe o computador ligado e sem lhe tocar até terminar; se for interrompido, pode ser retomado pela consola, mas é melhor não chegar a esse ponto.
• Integrações que continuam a comunicar. O modo de manutenção esconde a loja dos clientes, mas não corta o webservice. Um ERP que continua a sincronizar durante a atualização pode ir regenerando a cache enquanto o assistente a apaga, e o processo para. Pause as integrações antes de começar.
• Pouca memória na consola. Em alguns alojamentos, o PHP da linha de comandos tem menos memória do que o da web. Se a atualização for lançada pela consola, verifique esse limite antes.
• Ficheiros do núcleo substituídos. A atualização substitui ficheiros como config/config.inc.php ou o .htaccess da pasta de administração. O que se tenha acrescentado manualmente aí desaparece sem aviso, incluindo uma proteção por palavra-passe do painel. Guarde-o antes e reponha-o depois.
• Base de dados incompleta. Em algumas subidas de versão menor vimos que a loja atualizada não tinha todas as tabelas ou definições que uma instalação nova dessa versão traz, e a montra falhava em muitas páginas. Por isso o ensaio tem de percorrer a loja inteira, não só a página inicial.

No fim, é normal que o back-office termine a sessão: é preciso voltar a entrar.

Depois de atualizar: a lista de verificação

Uma atualização não está terminada quando o assistente diz que correu bem, mas sim quando verificou isto:

De quanto em quanto tempo atualizar

As versões de manutenção corrigem falhas e, muitas vezes, problemas de segurança. O saudável é não deixar passar muito tempo desde que sai uma versão do seu ramo, com o ensaio prévio de sempre. Uma loja que se atualiza de forma regular tem atualizações pequenas e previsíveis; uma em que só se mexe de vários em vários anos acumula alterações e cada atualização é um projeto.

O mesmo vale para os módulos e para o PHP: ir atualizando por partes é mais barato do que pôr tudo em dia de uma vez. Se a loja está há muito tempo sem lhe mexerem, o prudente é começar com uma revisão que diga o que está instalado e que ordem seguir.

Quando pedir ajuda

Uma atualização menor numa loja com o tema de origem e poucos módulos pode ser feita por alguém com experiência no back-office, sempre com cópia e ensaio. Convém que seja feita por um técnico quando há overrides, um tema muito personalizado, integrações com ERP ou marketplaces, ou um volume de encomendas que não permite que a loja falhe nem uma manhã. No serviço de migrações e atualizações do PrestaShop fazemos o ensaio numa cópia, dizemos-lhe o que se parte antes de mexer na produção e deixamos a loja revista. E se prefere que alguém trate disto de forma periódica, a manutenção do PrestaShop inclui as atualizações com a respetiva cópia e verificação.

Perguntas frequentes

É possível atualizar o PrestaShop sem perder dados?

Sim. Uma atualização conserva produtos, clientes e encomendas, porque adapta a base de dados existente. Mesmo assim, faça sempre uma cópia completa antes: é o que o protege se o processo for interrompido.

Quanto tempo demora uma atualização do PrestaShop?

Depende do tamanho da loja e do servidor. O ensaio numa cópia dá-lhe o tempo real, e com ele escolhe um período de pouco tráfego para o fazer em produção.

Também tenho de atualizar os módulos?

Normalmente sim, sobretudo os que o autor marca como compatíveis apenas com versões concretas. Verifique a compatibilidade de cada um antes de atualizar o núcleo.

O que faço se a atualização falhar a meio?

Não a volte a lançar às cegas. Veja em que passo ficou: por vezes pode ser retomada e, se não, restaura-se a cópia e repete-se o ensaio para saber o que a fez parar.