Existe um tipo específico de chamado de suporte que aprendi a temer. Um lojista atualiza um módulo; a atualização parece ser concluída com sucesso, mas então algo para de funcionar. Nunca a loja inteira. Pode ser uma página específica do controlador do PrestaShop com comportamento inadequado, ou um valor de configuração que se recusa a salvar, ou uma coluna de listagem que se esvazia sozinha. Quando verifico, o código do módulo está na nova versão, mas o banco de dados subjacente ainda está na versão antiga.
É exatamente essa lacuna que este artigo aborda. Um módulo do PrestaShop não é apenas o código PHP que você enviou, mas sim esse código PHP acrescido das tabelas e colunas que o PHP espera encontrar. Se você ignorar a atualização do banco de dados do PrestaShop que deve ser incluída em uma nova versão do código, o resultado será um módulo instalado, aparentemente funcionando, mas com problemas ocultos.
Eu já fiz isso comigo mais de uma vez. O que se segue é o que aprendi sobre Atualizações do banco de dados de módulos do PrestaShop, da maneira mais difícil.
1.0 Como as atualizações de módulos do PrestaShop realmente lidam com o banco de dados
[Caption id = “attachment_840862” align = “aligncenter” width = “1237”]
Circulam muitas suposições por aqui, e algumas estão erradas.
Adicione uma nova versão ao seu dispositivo. /módulos/ e sua rotina de instalação não é executada novamente. As tabelas permanecem intactas. O que acontece em vez disso: o PrestaShop lê o módulo. Melhorar/ pasta, encontra os arquivos com o nome atualizar- .php O programa fica entre a versão gravada e a versão declarada pela sua classe de módulo, executando-as em sequência.
Uma loja na versão 1.9.0 que recebe a versão 2.1.0 executa três scripts, em sequência.
Disso decorrem três coisas, e todas as três são importantes para Alterações no banco de dados do PrestaShop.
A versão na tabela `module` é a fonte da verdade. Não o arquivo no seu arquivo de classe principal. O PrestaShop lê ambos. Ele utiliza o arquivo gravado, e esse arquivo determina quantos scripts de atualização serão executados.
Seu método `install()` destina-se apenas a novas instalações. Digamos que a versão 2.0 precise de uma nova tabela. Coloque-a em instalar() E qualquer pessoa que migrar para a versão 2.0 está coberta. A loja que está na versão 1.9 não recebe nada, porque a instalação foi feita há um ano e nunca mais será executada.
Uma única falha paralisa tudo. Devolução
falso A partir de uma função de atualização, três coisas acontecem: o PrestaShop para de funcionar, registra qual versão apresentou falha e desativa o módulo. Não é possível prosseguir para o próximo script. Isso é intencional, embora signifique que uma alteração de esquema parcialmente aplicada deixe o sistema desativado em vez de completamente inoperante.
O Ativar a atualização automática de módulos Esta página define as regras de nomenclatura de arquivos. Leia-a atentamente uma vez, em vez de tentar memorizá-la.
A armadilha de nomenclatura da função de atualização
Essa me custou uma tarde inteira. Ou… upgrade_module_2_0_1 or upgradeModule201 funciona como um nome de função, e o PrestaShop procura por ambos. O que ele também faz, antes de incluir seu arquivo, é verificar se um desses nomes já existe. Se encontrar, o arquivo é marcado como duplicado e ignorado.
Copiar um script de atualização antigo como modelo é exatamente como as pessoas chegam a esse ponto. O nome dentro do script nunca é alterado. Nada é atualizado e a mensagem de erro não fornece muitas informações.
Migração de banco de dados do PrestaShop 2.0: o que dá errado em lojas reais
Tudo isso aconteceu em lojas onde eu trabalhava.
Alterações no esquema do banco de dados do PrestaShop que divergem entre instalações
A versão 2.0 precisa de uma nova coluna, então você precisa atualizá-la. instalar() e escrever um script de atualização. Ambos corretos. Três versões depois, alguém renomeia a pasta do módulo ou um lojista reinstala. Em algumas instalações, a função `install()` criou essa coluna. Em outras, o caminho de atualização a criou. Duas definições, divergindo, e um único número de versão agora abrange ambas.
Assim, a definição reside em um único método que ambos os caminhos chamam. As alterações no esquema do banco de dados do PrestaShop não podem se propagar se houver apenas um.
Scripts de atualização que partem do princípio de que o ponto de partida está limpo.
ALTERAR TABELA … ADICIONAR COLUNA Se uma coluna que já existe gerar um erro, sua função retornará falso e o módulo será desativado. Interrompa uma atualização anterior, restaure um backup parcial ou sincronize duas vezes a partir do ambiente de teste: qualquer uma dessas situações pode causar problemas.
Agora, toda alteração de esquema que eu escrevo passa por uma verificação prévia. Adicionar uma coluna significa uma MOSTRAR COLUNAS Criar uma tabela previamente significa MOSTRAR TABELAS, um índice significa MOSTRAR ÍNDICEAlgumas linhas, e o script sobrevive a uma segunda execução. Isso é importante, porque o banco de dados de um desconhecido pode estar em qualquer estado. Existe SE NÃO EXISTE em ambos MySQL e MariaDB, mas apenas em algumas operações, então a verificação explícita funciona melhor.
Multiloja: linhas de configuração escritas para apenas uma loja.
Silencioso e desagradável, este aqui. Uma configuração por loja chega na nova versão. A linha padrão foi criada pelo script de atualização, testada pelo desenvolvedor, tudo parecendo correto. Mas apenas uma linha foi criada, para a loja em questão, e o comerciante administra quatro lojas.
Três lojas agora não têm essa informação. Dependendo de como seu código interpreta isso, você recebe um aviso do PHP, um valor vazio tratado como uma configuração real ou um espaço em branco onde deveria haver um preço. documentação multistore Abrange as regras de contexto. Percorra cada ID de loja em qualquer atualização que altere a configuração ou os dados por loja.
Em uma instalação de loja única, esse bug é invisível.
ALTER TABLE bloqueia tabelas de catálogo grandes
Adicionar uma coluna a uma tabela com 400,000 linhas não é um processo instantâneo. Dependendo da operação, da versão do MySQL e do mecanismo de armazenamento, a tabela inteira pode ser copiada. Em uma loja online em funcionamento, durante o horário de negociação, esse bloqueio dura tempo suficiente para que os clientes percebam.
Por isso, verifico o tamanho da tabela antes de escrever a migração. Se for grande: janela de manutenção ou reestruturação para evitar a reconstrução.
A chave de configuração sem valor padrão.
Aquele que vejo com mais frequência nos módulos de outras pessoas, e que não envolve nenhuma tabela.
Você adiciona uma configuração na nova versão. O formulário de administração a lê. O mesmo acontece com o controlador frontal. Ambos foram escritos em uma máquina onde a página de configurações já havia sido salva pelo menos uma vez. Portanto, a chave existe e tudo parece correto. Publique isso e todas as instalações existentes estarão lendo a mesma configuração. Configuração chave que ninguém jamais escreveu.
O que retorna é falsoSeu valor padrão nunca aparece, nem mesmo uma string vazia que você poderia ao menos testar. A partir daí, ele é usado como um número ou passado para uma função que esperava uma string. Com o modo de depuração desativado, muitas vezes você consegue passar despercebido: o lojista vê uma página ligeiramente incorreta e não se importa. Com o modo de depuração ativado, o problema aparece como um aviso ou um erro de tipo. É assim que você recebe a mensagem “o módulo apresenta problemas no modo de depuração”, quando, na verdade, o modo de depuração é o único responsável.
O mesmo código, com e sem o valor padrão escrito.
A solução é tediosa. Cada nova chave de configuração recebe seu valor padrão no script de atualização, para cada loja, e é distribuída junto com o código que a lê. Leia-o com cautela, pois não há como garantir que a atualização foi executada corretamente.
Migração de banco de dados de módulo PrestaShop versus alteração de esquema
As alterações de esquema são a metade fácil. A metade difícil é quando o significado dos dados existentes muda: dividir uma coluna em duas, mover um campo CSV para uma tabela relacionada, recodificar um status.
É aí que tenho visto os maiores danos. Um trabalho malfeito. ALTERAR A TABELA Falha de forma flagrante; uma transformação de dados malfeita é bem-sucedida e gera resultados sem sentido. Uma migração de banco de dados de um módulo do PrestaShop que move dados precisa de uma contagem antes e depois, para então compará-las. É melhor encontrar essa informação no script de atualização do que descobrir com um lojista três semanas depois.
Práticas recomendadas para atualização de módulos do PrestaShop 3.0 que eu realmente defenderia.
Aqueles que me salvaram:
Torne cada migração idempotente.
Nada deve mudar na segunda execução que a primeira já não tenha tratado. Obtenha essa propriedade e toda uma categoria de problemas de suporte desaparece, porque o estado do banco de dados deixa de ser algo que você precisa estabelecer primeiro. Antes de escrever SQL bruto em tabelas principais, o PrestaShop notas da camada de banco de dados valem uma hora.
A versão protegida sobrevive a uma segunda execução.
Registre cada falha em vez de retornar falso silenciosamente.
A nu retorna falso Isso é suficiente para o PrestaShop parar e desativar o módulo. Não é suficiente para você. Portanto, proteja o processo. Capture tudo o que sair dele e passe para o PrestaShopLogger com o nome e a versão do módulo anexados. Caso contrário, o lojista relatará uma falha na atualização e você ficará apenas adivinhando.
No PHP 7 e versões superiores, observe. erro anteriormente Exceção. Se você receber um erro de tipo no seu próprio código de migração, ele chegará como um erro, portanto, um manipulador observando apenas por Exceção deixa passar.
Ofereça suporte a todas as versões que você já lançou.
Um lojista pode estar em qualquer versão que você tenha lançado. Alguém que atualiza da versão 1.4 para a 3.0 executa todos os scripts intermediários, em ordem, então cada um precisa funcionar com o esquema deixado pela versão anterior. É por isso que os arquivos de atualização antigos permanecem no módulo. Alguém que está dois anos atrasado não tem outra opção.
Teste em ambiente de teste, não em uma instalação local limpa.
Uma instalação limpa da nova versão não prova nada sobre a atualização. O ideal seria instalar a versão antiga, inserir dados reais e só então atualizar. Isso também vale para lojas com suporte a múltiplos dispositivos.
Melhor ainda: pegue uma cópia de uma loja real e faça a atualização por meio dela. Sua instalação local tem dados limpos e quatro produtos, por isso não detecta nada. Uma loja real contém importações incompletas, linhas deixadas por um módulo desinstalado há dois anos, colunas adicionadas manualmente por um desenvolvedor anterior e um catálogo grande o suficiente para… ALTERAR A TABELA leva um tempo.
Em seguida, vem o momento certo. Uma atualização que requer seis minutos de antecedência, com base em dados reais, é melhor compreendida durante o agendamento de uma janela de manutenção do que às onze horas de uma sexta-feira.
Faça um backup antes de alterar o esquema e avise-nos.
Nenhum snapshot das suas tabelas é criado antes de uma atualização de módulo. Nem pelo PrestaShop, nem por nenhum outro sistema. Portanto, se o lojista não tiver um backup e a migração for interrompida no meio da transformação dos dados, esses dados serão perdidos. Informe isso no changelog em vez de deixar que a pessoa descubra o problema por conta própria.
Recuperando uma atualização de banco de dados PrestaShop com falha
Uma atualização falhou em uma loja em produção; módulo desativado. Aproximadamente nesta ordem:
Descubra qual versão apresentou falha. Isso fica registrado, e se você escreveu uma mensagem de log, ela também ficará lá. Com essas informações, você sabe qual script abrir e quais alterações foram aplicadas antes da interrupção.
Verifique o esquema real, não o número da versão. Todos os módulo A tabela contém o que foi gravado na última atualização bem-sucedida. As tabelas reais são onde está a resposta, comparadas com o que o script com falha estava tentando fazer.
Corrija para a frente, não para trás. Reverter o número da versão é tentador, mas geralmente um erro, porque os scripts anteriores já foram executados e executá-los novamente em um esquema parcialmente alterado transforma um problema em três. Escreva uma migração corretiva do estado atual do esquema para o estado correto.
Em seguida, descubra por que a migração não foi idempotente. Esse é o verdadeiro problema.
Uma breve lista de verificação antes de enviar uma atualização de módulo.
A lista que eu executo:
- Versão da classe principal, a mais alta atualização-*.php Arquivo: eles correspondem?
- Cada função de atualização recebe o nome da versão do seu respectivo arquivo?
- A cada alteração de esquema, é preciso verificar primeiro se ela já foi aplicada.
- Cada configuração de escrita percorre todas as lojas?
- Cada nova chave de configuração recebe um valor padrão para instalações existentes?
- Já se deparou com uma réplica de uma loja real?
- Versão antiga instalada, dados adicionados e, em seguida, atualizada?
- Mesmo caminho em várias lojas?
- Algo útil registrado antes de cada retorna falso?
- Apanhando erro anteriormente Exceção?
- Arquivos de atualização antigos ainda estão instalados para comerciantes com várias versões de atraso?
- O changelog está instruindo os comerciantes a fazerem backup?
- Em uma mesa grande, qual é o comprimento disso? ALTERAR Segurando uma fechadura?
Os itens 6 e 7 são os que as pessoas geralmente ignoram, e entre eles, elas conseguem capturar a maior parte da informação.
Conclusão
Atualização do módulo PrestaShop Os problemas são complicados por um motivo: nada os anuncia. O módulo reporta sua nova versão sem problemas. A página de administração carrega. Nenhum log, a menos que você os tenha criado. Enquanto isso, seu código espera uma coisa, o banco de dados contém outra, e isso permanece intocado até que alguém use a única funcionalidade que está no meio do processo.
Trate o esquema como parte da versão. Escreva migrações que sobrevivam a uma segunda execução. Registre o que aconteceu. Coloque-o em ambiente de teste antes que qualquer lojista o faça. No lado do framework, o PrestaShop documentação de desenvolvimento de módulos é o lugar para começar.
Se você tiver dúvidas ou precisar de ajuda com o desempenho ou a migração do seu site, nossos especialistas estão à disposição. Entre em contato com a equipe da Knowband em conveyors.au@prok.com Hoje, você encontra plugins de e-commerce confiáveis e personalizados para atender às suas necessidades de comércio eletrônico.