Uma migração de versão maior não se joga no núcleo do PrestaShop, que se atualiza corretamente na maioria dos casos. Joga-se nos seus módulos. Numa loja que conta quarenta, basta que um só toque no funil de encomenda e já não seja compatível para que a migração fique bloqueada.
A auditoria dos módulos deve portanto preceder tudo o resto, incluindo o orçamento.
O que muda realmente
O PrestaShop 9 apoia-se em versões mais recentes do PHP e do Symfony, o que implica três famílias de ruturas.
As ruturas ligadas ao PHP. Tipagem mais estrita, propriedades dinâmicas depreciadas, funções retiradas. Um módulo escrito há cinco anos e nunca retomado produz erros fatais, não avisos.
As ruturas ligadas ao framework. Os módulos que estendem controladores Symfony ou que declaram serviços devem seguir a nova versão. É o caso dos módulos recentes e bem construídos, paradoxalmente mais expostos do que os módulos puramente legacy.
As ruturas próprias do PrestaShop. Métodos suprimidos das classes históricas, hooks retirados ou renomeados, mudanças nos templates do tema por defeito.
O inventário, primeiro entregável
Antes de qualquer manipulação, produza uma tabela com uma linha por módulo e seis colunas.
- Nome técnico e versão instalada.
- Editor, e a sua existência atual. Um editor desaparecido é um módulo condenado.
- Data da última atualização disponível. Para lá de dezoito meses sem publicação, considere o módulo abandonado até prova em contrário.
- Compatibilidade anunciada com a versão alvo, distinguindo o que está escrito na ficha de produto do que é realmente testado.
- Criticidade: o módulo toca no pagamento, no funil, no catálogo, ou apenas numa exibição secundária?
- Presença de overrides, visível na pasta das sobrecargas. É o melhor indicador de fragilidade.
Esta tabela preenche-se em meio dia e determina todo o resto do projeto.
As quatro categorias
Cada módulo cai numa delas, e o tratamento difere.
Compatível e mantido. Atualiza e testa. É o caso mais simples, e raramente representa a maioria.
Compatível anunciado mas não verificado. A menção na ficha de produto não vale como teste de aceitação. Estes módulos devem ser testados em prioridade, porque uma incompatibilidade descoberta tarde custa um adiamento.
Abandonado. Duas saídas: encontrar um substituto, ou mandar retomar o código. A retoma só faz sentido se a funcionalidade for específica da sua atividade.
Substituível por nativo. Categoria sistematicamente subestimada. Cada versão maior integra funções que existiam antes sob a forma de módulos. Uma migração é o bom momento para desinstalar o que já não serve.
Nas auditorias reais, esta última triagem retira muitas vezes entre cinco e dez módulos da lista, o que alivia na mesma medida o projeto.
Verificador de Ligações Mortas PrestaShop 8 e 9: Ligações Partidas e Imagens em FaltaEncontre as ligações mortas e as imagens partidas antes dos seus clientes59,00€
As armadilhas técnicas mais frequentes
Para os programadores e as agências, quatro ruturas voltam constantemente nos módulos a retomar.
O método de tradução disponível diretamente nos controladores desapareceu: é preciso passar pela instância do módulo. As sobrecargas de métodos cuja assinatura mudou produzem erros de compatibilidade, nomeadamente nos métodos de renderização usados para as respostas assíncronas. As chamadas assíncronas aos controladores de administração históricos mudaram de forma e exigem que os parâmetros sejam passados de outra maneira. E os módulos que escreviam diretamente em tabelas do núcleo esbarram nas evoluções de esquema.
Nenhuma destas correções é complexa isoladamente. O custo vem do número.
O ambiente de teste
Não negociável, e no entanto regularmente saltado.
Deve assentar numa cópia recente da base de produção, não num jogo de demonstração. A maioria das incompatibilidades aparece sobre dados reais: produtos com cem variações, clientes com moradas incompletas, encomendas em estados esquecidos.
Duas precauções: anonimize os dados dos clientes antes de copiar, e desative qualquer envio de email a partir desse ambiente. Um teste de migração que envia dois mil emails de mudança de estado a clientes reais é uma história verdadeira e frequente.
O plano de teste
Teste percursos, não páginas. Seis percursos cobrem o essencial.
Uma encomenda completa como visitante não ligado, com pagamento real em ambiente de teste. Uma encomenda com uma conta existente e uma morada guardada. Uma adição ao carrinho a partir de uma página de categoria com filtros ativos. Uma pesquisa interna seguida de uma compra. Uma devolução ou um pedido de pós-venda. E do lado da administração, a criação de um produto com variações e a validação de uma encomenda.
Cada percurso deve ser jogado em desktop e em mobile. Conte um dia para o conjunto, a refazer depois de cada correção significativa.
A passagem e o depois
Preveja a migração fora dos períodos comerciais, com uma janela de retrocesso definida e testada. Uma cópia de segurança que nunca foi restaurada não conta.
Nos dias seguintes, três controlos impõem-se. Os registos de erro do servidor, que revelam as incompatibilidades que o teste não encontrou. As ligações e imagens partidas, porque uma mudança de versão pode afetar os caminhos de imagens e os URL reescritos. E o seguimento das encomendas, a comparar com o nível habitual: uma queda brutal sinaliza um bloqueio no funil que ninguém assinalou.
Neste último ponto, o Verificador de Ligações Mortas para PrestaShop é útil em fase de teste como depois da passagem: deteta as ligações internas partidas e as imagens em falta que a migração possa ter produzido, no PrestaShop 8 como no PrestaShop 9.