La tabella di configurazione globale di PrestaShop rende facile per la routine di disinstallazione di un modulo cancellare impostazioni appartenenti a estensioni completamente non correlate. Una singola chiamata a Configuration::deleteByName('width') può eliminare il valore personalizzato della larghezza di un altro negozio, lasciando il commerciante perplesso e il modulo colpevole apparentemente innocuo.

Perché la tabella di configurazione condivisa è importante

PrestaShop memorizza le impostazioni di ogni modulo in un'unica tabella che contiene solo una chiave e un valore. La tabella non ha una colonna che registri quale modulo abbia creato una riga e non impone alcuna convenzione di denominazione. Di conseguenza, due moduli che utilizzano per caso la stessa chiave — ad esempio "width" o "API_DATE_FROM" — leggeranno e scriveranno sulla stessa riga del database. L'ultima scrittura prevale e qualsiasi eliminazione successiva rimuove la riga per entrambe le parti.

Quando il codice di disinstallazione si trasforma in uno strumento di cancellazione dati

Un tipico metodo di disinstallazione appare così:

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

L'intenzione è quella di pulire la configurazione del modulo stesso, ma poiché la chiave non è "namespaced" (ovvero non ha un prefisso univoco), l'istruzione rimuove qualsiasi riga chiamata "width". Non viene registrato alcun avviso, non viene lanciata alcuna eccezione; la riga semplicemente scompare. L'altro modulo del commerciante perde silenziosamente la sua impostazione e potrebbe iniziare a comportarsi in modo anomalo.

Il problema diventa particolarmente insidioso durante un aggiornamento di versione. Uno sviluppatore che passa dalla versione 1.0 alla 2.0 potrebbe iniziare a salvare i valori sotto una chiave con prefisso, come MY_MODULE_WIDTH. Per "pulire" le vecchie voci senza prefisso, aggiunge una chiamata di eliminazione alla routine di disinstallazione, convinto di rimuovere solo i dati legacy. In realtà, sta eliminando anche qualsiasi altra estensione che abbia memorizzato dati sotto la stessa chiave generica.

Cosa ha rivelato l'audit

Un audit di 57 repository di moduli pubblici ha rivelato un pattern ricorrente:

  • Molti moduli utilizzano chiavi generiche come "width", "height" o "API_DATE_FROM" senza alcun prefisso derivato dal nome del modulo.
  • Diversi metodi di disinstallazione contengono chiamate Configuration::deleteByName che puntano a queste chiavi generiche.
  • Il problema non è limitato a un singolo sviluppatore o a un particolare tipo di modulo; il design della tabella condivisa lo rende un rischio sistemico.

L'audit non ha trovato log o messaggi di errore che avvisino il proprietario del negozio che la configurazione di un altro modulo è stata rimossa. L'unico sintomo è una perdita improvvisa di impostazioni che il commerciante potrebbe attribuire a un problema di cache o a un bug nel proprio codice.

Pratiche più sicure per gli sviluppatori di moduli

  1. Namespace per ogni chiave – anteponi il nome tecnico del modulo a ogni chiave di configurazione (ad es. my_module_width). Ciò crea un identificatore univoco senza fare affidamento su una colonna di proprietà separata.
  2. Evita di eliminare le vecchie chiavi senza prefisso – lasciare alcune righe obsolete nella tabella non costa quasi nulla in termini di spazio di archiviazione ed elimina il rischio di danni collaterali.
  3. Verifica la proprietà prima dell'eliminazione – se un'eliminazione è davvero necessaria, verifica prima che il valore della chiave sia stato impostato dal tuo codice (ad esempio, memorizza un valore segnaposto che solo il tuo modulo conosce).
  4. Effettua l'audit dei metodi di disinstallazione – cerca nel codice sorgente le chiamate deleteByName. Ogni occorrenza dovrebbe essere esaminata per confermare che la chiave sia univocamente namespaced.
  5. Documenta la convenzione di denominazione – includi una breve linea guida nel README del modulo, in modo che i futuri collaboratori comprendano l'importanza delle chiavi con prefisso.

Test per le eliminazioni accidentali tra moduli

Un modo pratico per individuare il bug prima che raggiunga un negozio online:

  • Popola la tabella di configurazione con una chiave che appartiene a un modulo diverso (ad es. other_module_setting => test).
  • Esegui la routine di disinstallazione del modulo in un ambiente controllato.
  • Verifica che la chiave inserita esista ancora dopo il completamento della disinstallazione.

Automatizzare questo controllo nella suite di unit-test del modulo garantisce che qualsiasi modifica futura che introduca una chiamata deleteByName errata faccia fallire il test, richiedendo una revisione.

Cosa dovrebbero monitorare i proprietari dei negozi

I proprietari dei negozi raramente vedono le righe interne del database, ma possono notare il sintomo: dopo aver disabilitato o disinstallato un modulo, un'altra estensione torna improvvisamente alle impostazioni predefinite. Se ciò accade, chiedi allo sviluppatore di verificare che il codice di disinstallazione del modulo rispetti la tabella di configurazione globale. Richiedi un elenco di tutte le chiavi di configurazione utilizzate dal modulo; qualsiasi chiave senza un prefisso chiaro è un segnale di allarme.

In sintesi

Il design di PrestaShop rende la tabella di configurazione una risorsa condivisa, e una routine di disinstallazione imprudente può cancellare le impostazioni di un altro modulo senza lasciare traccia. Utilizzando il namespacing delle chiavi, evitando pulizie aggressive e aggiungendo un semplice test che protegga le voci esterne, gli sviluppatori possono prevenire la perdita silenziosa di dati e mantenere stabili i negozi dei commercianti. L'impegno richiesto è minimo, ma il costo di un'impostazione persa — reclami dei clienti, ticket di assistenza e reputazione danneggiata — può essere molto più elevato.