A tabela de configuração global do PrestaShop facilita que a rotina de desinstalação de um módulo apague configurações que pertencem a extensões completamente não relacionadas. Uma única chamada a Configuration::deleteByName('width') pode apagar o valor de largura personalizado de outra loja, deixando o lojista confuso e o módulo causador aparentemente inofensivo.

Por que a tabela de configuração compartilhada é importante

O PrestaShop armazena as configurações de cada módulo em uma única tabela que contém apenas uma chave e um valor. A tabela não possui uma coluna que registre qual módulo criou uma linha, e não impõe nenhuma convenção de nomenclatura. Como resultado, dois módulos que por acaso utilizem a mesma chave — por exemplo, “width” ou “API_DATE_FROM” — lerão e escreverão na mesma linha do banco de dados. A última gravação prevalece, e qualquer exclusão posterior remove a linha para ambas as partes.

Quando o código de desinstalação se torna uma ferramenta de limpeza de dados

Um método de desinstalação típico se parece com isto:

public function uninstall()
{
    return Configuration::deleteByName('width');
}

A intenção é limpar a própria configuração do módulo, mas como a chave não possui um namespace, a instrução remove qualquer linha chamada “width”. Nenhum aviso é registrado, nenhuma exceção é lançada; a linha simplesmente desaparece. O outro módulo do lojista perde silenciosamente sua configuração e pode começar a se comportar de forma estranha.

O problema torna-se especialmente tentador durante uma atualização de versão. Um desenvolvedor que migra da versão 1.0 para a 2.0 pode começar a salvar valores sob uma chave com prefixo, como MY_MODULE_WIDTH. Para “limpar” as entradas antigas sem prefixo, eles adicionam uma chamada de exclusão à rotina de desinstalação, acreditando que estão removendo apenas dados legados. Na realidade, eles também estão excluindo o que quer que outras extensões tenham armazenado sob a mesma chave genérica.

O que a auditoria revelou

Uma auditoria de 57 repositórios de módulos públicos revelou um padrão recorrente:

  • Muitos módulos usam chaves genéricas como “width”, “height” ou “API_DATE_FROM” sem qualquer prefixo derivado do nome do módulo.
  • Vários métodos de desinstalação contêm chamadas Configuration::deleteByName que visam essas chaves genéricas.
  • O problema não se limita a um único desenvolvedor ou a um tipo específico de módulo; o design da tabela compartilhada torna isso um risco sistêmico.

A auditoria não encontrou logs ou mensagens de erro que alertassem o proprietário da loja de que a configuração de outro módulo havia sido removida. O único sintoma é uma perda repentina de configurações que o lojista pode atribuir a um problema de cache ou a um bug em seu próprio código.

Práticas mais seguras para desenvolvedores de módulos

  1. Use namespaces para cada chave – acrescente o nome técnico do módulo a cada chave de configuração (ex: my_module_width). Isso cria um identificador único sem depender de uma coluna de propriedade separada.
  2. Evite excluir chaves antigas sem prefixo – deixar algumas linhas obsoletas na tabela não custa virtualmente nada em armazenamento e elimina o risco de danos colaterais.
  3. Verifique a propriedade antes da exclusão – se uma exclusão for realmente necessária, verifique primeiro se o valor da chave foi definido pelo seu próprio código (por exemplo, armazene um valor de marcação que apenas o seu módulo conheça).
  4. Audite os métodos de desinstalação – procure no código-fonte por chamadas deleteByName. Cada ocorrência deve ser examinada para confirmar que a chave possui um namespace exclusivo.
  5. Documente a convenção de nomenclatura – inclua uma breve diretriz no README do módulo para que futuros colaboradores entendam a importância das chaves com prefixo.

Testando para exclusões acidentais entre módulos

Uma maneira prática de detectar o bug antes que ele chegue a uma loja em produção:

  • Popule a tabela de configuração com uma chave que pertença a um módulo diferente (ex: other_module_setting => test).
  • Execute a rotina de desinstalação do módulo em um ambiente controlado.
  • Verifique se a chave inserida ainda existe após a conclusão da desinstalação.

Automatizar essa verificação na suíte de testes unitários do módulo garante que qualquer alteração futura que introduza uma chamada deleteByName perdida falhe no teste, solicitando uma revisão.

O que os proprietários de lojas devem observar

Os proprietários de lojas raramente veem as linhas internas do banco de dados, mas podem notar o sintoma: após desativar ou desinstalar um módulo, outra extensão subitamente retorna às configurações padrão. Se isso acontecer, peça ao desenvolvedor para verificar se o código de desinstalação do módulo respeita a tabela de configuração global. Solicite uma lista de todas as chaves de configuração que o módulo utiliza; qualquer chave sem um prefixo claro é um sinal de alerta.

Conclusão

O design do PrestaShop torna a tabela de configuração um recurso compartilhado, e uma rotina de desinstalação descuidada pode apagar as configurações de outro módulo sem deixar rastros. Ao aplicar namespaces às chaves, evitar limpezas agressivas e adicionar um teste simples que proteja entradas de terceiros, os desenvolvedores podem evitar a perda silenciosa de dados e manter as lojas dos lojistas estáveis. O esforço necessário é mínimo, mas o custo de uma configuração perdida — reclamações de clientes, tickets de suporte e reputação prejudicada — pode ser muito maior.