La tabla de configuración global de PrestaShop facilita que la rutina de desinstalación de un módulo borre ajustes que pertenecen a extensiones completamente ajenas. Una sola llamada a Configuration::deleteByName('width') puede eliminar el valor de ancho personalizado de otra tienda, dejando al comerciante desconcertado y al módulo infractor aparentemente inofensivo.

Por qué es importante la tabla de configuración compartida

PrestaShop almacena los ajustes de cada módulo en una única tabla que solo contiene una clave y un valor. La tabla no tiene ninguna columna que registre qué módulo creó una fila, y no impone ninguna convención de nomenclatura. Como resultado, dos módulos que coincidan en el uso de la misma clave —por ejemplo, “width” o “API_DATE_FROM”— leerán y escribirán en la misma fila de la base de datos. La última escritura prevalece, y cualquier eliminación posterior elimina la fila para ambas partes.

Cuando el código de desinstalación se convierte en una herramienta de borrado de datos

Un método de desinstalación típico se ve así:

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

La intención es limpiar la propia configuración del módulo, pero como la clave no tiene un espacio de nombres (namespace), la sentencia elimina cualquier fila llamada “width”. No se registra ninguna advertencia ni se lanza ninguna excepción; la fila simplemente desaparece. El otro módulo del comerciante pierde silenciosamente su ajuste y puede empezar a comportarse de forma extraña.

El problema se vuelve especialmente tentador durante una actualización de versión. Un desarrollador que pasa de la versión 1.0 a la 2.0 podría empezar a guardar valores bajo una clave con prefijo, como MY_MODULE_WIDTH. Para "limpiar" las entradas antiguas sin prefijo, añaden una llamada de eliminación a la rutina de desinstalación, creyendo que solo están eliminando datos heredados. En realidad, también están eliminando cualquier otra extensión que haya almacenado datos bajo la misma clave genérica.

Lo que reveló la auditoría

Una auditoría de 57 repositorios de módulos públicos reveló un patrón recurrente:

  • Muchos módulos utilizan claves genéricas como “width”, “height” o “API_DATE_FROM” sin ningún prefijo derivado del nombre del módulo.
  • Varios métodos de desinstalación contienen llamadas a Configuration::deleteByName que apuntan a estas claves genéricas.
  • El problema no se limita a un único desarrollador o a un tipo particular de módulo; el diseño de la tabla compartida lo convierte en un riesgo sistémico.

La auditoría no encontró ningún registro ni mensaje de error que alertara al propietario de la tienda de que se había eliminado la configuración de otro módulo. El único síntoma es una pérdida repentina de ajustes que el comerciante puede atribuir a un problema de caché o a un error en su propio código.

Prácticas más seguras para desarrolladores de módulos

  1. Asignar un espacio de nombres (namespace) a cada clave – anteponga el nombre técnico del módulo a cada clave de configuración (por ejemplo, my_module_width). Esto crea un identificador único sin depender de una columna de propiedad separada.
  2. Evitar la eliminación de claves antiguas sin prefijo – dejar algunas filas obsoletas en la tabla no cuesta prácticamente nada en términos de almacenamiento y elimina el riesgo de daños colaterales.
  3. Verificar la propiedad antes de la eliminación – si una eliminación es realmente necesaria, compruebe primero que el valor de la clave fue establecido por su propio código (por ejemplo, almacene un valor de marcador que solo su módulo conozca).
  4. Auditar los métodos de desinstalación – busque llamadas a deleteByName en el código fuente. Cada aparición debe examinarse para confirmar que la clave tiene un espacio de nombres único.
  5. Documentar la convención de nomenclatura – incluya una breve guía en el README del módulo para que los futuros colaboradores comprendan la importancia de las claves con prefijo.

Pruebas para detectar eliminaciones accidentales entre módulos

Una forma práctica de detectar el error antes de que llegue a una tienda en producción:

  • Sembrar la tabla de configuración con una clave que pertenezca a un módulo diferente (por ejemplo, other_module_setting => test).
  • Ejecutar la rutina de desinstalación del módulo en un entorno controlado.
  • Comprobar (assert) que la clave sembrada todavía existe una vez completada la desinstalación.

Automatizar esta comprobación en la suite de pruebas unitarias del módulo garantiza que cualquier cambio futuro que introduzca una llamada accidental a deleteByName falle la prueba, lo que obligará a realizar una revisión.

A qué deben prestar atención los propietarios de tiendas

Los propietarios de tiendas rara vez ven las filas internas de la base de datos, pero pueden detectar el síntoma: tras desactivar o desinstalar un módulo, otra extensión vuelve repentinamente a la configuración predeterminada. Si eso sucede, pida al desarrollador que verifique que el código de desinstalación del módulo respeta la tabla de configuración global. Solicite una lista de todas las claves de configuración que utiliza el módulo; cualquier clave sin un prefijo claro es una señal de alerta.

Conclusión

El diseño de PrestaShop convierte la tabla de configuración en un recurso compartido, y una rutina de desinstalación descuidada puede borrar la configuración de otro módulo sin dejar rastro. Mediante el uso de namespaces para las claves, evitando limpiezas agresivas y añadiendo una prueba sencilla que proteja las entradas ajenas, los desarrolladores pueden prevenir la pérdida silenciosa de datos y mantener la estabilidad de las tiendas de los comerciantes. El esfuerzo requerido es mínimo, pero el coste de una configuración perdida —quejas de clientes, tickets de soporte y una reputación dañada— puede ser mucho mayor.