Continuar com o PrestaShop 1.6 ou 1.7: que riscos tem e como avaliá-los

«Se funciona, não mexas» é um bom conselho para quase tudo, menos para software exposto à Internet que recebe pagamentos com cartão. Uma loja em PrestaShop 1.6 ou 1.7 pode vender todos os dias sem um único erro visível e, ao mesmo tempo, acumular riscos que não se notam até rebentarem.

Não se trata de assustar. Trata-se de perceber o que significa estar sem suporte, para que a decisão de continuar ou migrar seja sua e baseada em dados.

O que significa «sem suporte» na prática

O núcleo já não recebe patches

O ramo 1.6 terminou com a 1.6.1.24 e o ramo 1.7 com a 1.7.8.11. Quando se descobre uma vulnerabilidade nova no núcleo, a correção é publicada para os ramos mantidos. Para o seu, no melhor dos casos, alguém escreve um patch não oficial; no pior, não há nada.

E mesmo que esteja na 1.7, em que 1.7 está? Muitas lojas continuam numa 1.7.6 ou numa 1.7.7 sem as correções posteriores do próprio ramo, que incluíram correções de segurança.

Os módulos vão ficando para trás

Os programadores de módulos concentram o seu trabalho nas versões atuais. Com o tempo acontece isto:

• As novas versões dos módulos deixam de ser compatíveis com a sua loja.
• Quando é publicada uma falha de segurança num módulo, a versão corrigida exige um PrestaShop mais recente.
• Alguns autores abandonam os seus módulos e ninguém os volta a rever.
• Os gateways de pagamento mudam as suas API e os seus requisitos, e os módulos antigos deixam de funcionar ou perdem funções.

Este é, na prática, o maior risco. As campanhas em massa contra o PrestaShop costumam explorar vulnerabilidades em módulos, e uma loja que não pode instalar a versão corrigida fica exposta indefinidamente.

PHP sem suporte

O PrestaShop 1.7.8 chega no máximo ao PHP 7.4, e as versões anteriores a menos. O PHP 7.4 deixou de receber patches de segurança há anos. Isso significa que a própria linguagem em que a sua loja corre tem falhas conhecidas que não vão ser corrigidas.

Além disso, os alojamentos retiram as versões antigas de PHP dos seus servidores. Chega o dia em que o fornecedor avisa que vai subir a versão, ou sobe-a diretamente, e a loja deixa de funcionar. Migrar à pressa por causa disso é a pior forma de migrar.

Como avaliar o seu risco

Nem todas as lojas antigas têm o mesmo risco. Estas perguntas ajudam a situar-se:

Uma loja com muita faturação, muitos módulos de terceiros e sem vigilância é a que mais tem a perder e a que tem mais probabilidades de ser atacada com sucesso.

O que se pode fazer entretanto

Se a migração não puder ser imediata, há medidas que reduzem o risco:

• Suba para a última versão do seu ramo: a 1.7.8.11 se estiver na 1.7. É muito menos trabalho do que uma migração e fecha falhas conhecidas.
• Suba o PHP para a versão mais alta que o seu PrestaShop admite, testando antes numa cópia.
• Faça o inventário dos módulos e retire os que não usa, incluindo as pastas dos desinstalados.
• Atualize os módulos que tenham versão compatível, sobretudo os que têm controladores públicos.
• Bloqueie a execução direta de PHP em modules/ e nas pastas de dados.
• Ative a vigilância de ficheiros, funcionários e configuração de pagamentos, para saber cedo se acontecer algo.
• Cópias de segurança diárias, fora do servidor e testadas.

Tudo isto compra tempo. Não transforma uma loja sem suporte numa loja com suporte. E quanto mais se adia, mais cara fica a saída: cada ano que passa há mais distância entre a sua versão e a atual, mais módulos sem equivalente direto e mais dados para levar. As migrações mais simples que fazemos são as de lojas que deram o salto quando ainda podiam escolher o momento, não as que esperaram que algo deixasse de funcionar.

Como planear a saída

1. Decida o destino. Hoje o razoável é saltar diretamente para o PrestaShop 9, sem paragem intermédia na 8, a não ser que algum módulo imprescindível ainda não exista para a 9.
2. Faça o inventário de funções, não de módulos. Liste o que a loja faz (faturação, envios, ERP, pagamentos, SEO) e, para cada coisa, que módulo o resolve hoje e qual o fará na 9. Muitas vezes, uma boa parte está a mais.
3. Calcule o trabalho do tema. Um tema da 1.6 não serve na 9, e um da 1.7 raramente serve tal como está. É a maior parcela de muitas migrações.
4. Escolha o momento. Evite as campanhas fortes do seu setor. Uma migração bem planeada precisa de semanas de testes, não de dias.
5. Faça um ensaio completo numa cópia antes do dia da mudança.

A vantagem de planear com tempo é que é você quem escolhe o calendário. Se esperar que o alojamento retire o PHP 7.4 ou que chegue um incidente, outro escolherá por si.

Como resolvê-lo no PrestaShop

Na Rekire trabalhamos diariamente com lojas em 1.6, 1.7, 8 e 9, e com os pacotes de horas de suporte fazemos exatamente este trabalho: uma auditoria da versão, do PHP e dos módulos da sua loja com uma avaliação do risco, a atualização para a última versão do seu ramo se quiser ganhar tempo, e o plano de migração para o PrestaShop 9 com o inventário de funções, os módulos substitutos e o trabalho do tema. As horas são consumidas conforme o trabalho real, e pode começar pela auditoria e decidir depois.