PrestaShop multitienda: cómo cambiar una tienda sin tocar las demás

Gestionar varios escaparates desde una sola instalación de PrestaShop multitienda ahorra trabajo: tienes un único backoffice, reutilizas el catálogo, instalas los módulos una vez y mantienes un solo servidor. A cambio, cada modificación, por pequeña que sea, se ejecuta dentro de un contexto, y ese contexto decide si el cambio afecta a una tienda, a un grupo de tiendas o a todas. Casi nadie lo explica al principio.

Antes de publicar, comprueba en qué tienda funciona el cambio y en cuáles no debería haber cambiado nada.

Los tres niveles de contexto de PrestaShop

PrestaShop organiza la multitienda en tres niveles: todas las tiendas, grupos de tiendas y tienda individual. En el backoffice, el selector de contexto de la parte superior determina dónde se aplica lo que guardas. Si estás en "Todas las tiendas" y cambias un valor de configuración, ese valor puede pasar a ser el predeterminado de todas las tiendas que no lo tengan sobrescrito.

Pongamos una empresa con dos escaparates, uno para consumidor final y otro para profesionales, donde los precios se muestran sin IVA. Alguien ajusta cómo se muestran los precios con el contexto equivocado y la tienda de consumidor empieza a enseñar precios sin impuestos. Nadie ha tocado código: bastó con guardar un formulario en el nivel incorrecto.

Por eso el equipo tiene que saber qué contexto usa, y por qué, antes de cualquier desarrollo o ajuste. Si además hay desarrollo PrestaShop multitienda a medida, el propio código debe respetar esa regla.

Qué elementos pueden compartirse en PrestaShop multitienda

Tener dominios distintos no separa los datos. Según la versión y cómo estén configurados los grupos de tiendas, se pueden compartir muchas cosas, así que antes de desarrollar haz inventario de al menos estas:

• Productos y categorías, que pueden estar asociados a varias tiendas con una parte de datos común y otra propia de cada tienda.
• Precios y combinaciones. El precio base, los impuestos y las reglas de precio pueden variar por tienda o heredarse.
• El stock. Si el grupo de tiendas comparte existencias, una venta en una tienda reduce las unidades disponibles en la otra.
• Clientes y pedidos, que también pueden compartirse a nivel de grupo y afectan a cuentas, carritos e historial.
• Idiomas, monedas y transportistas, activos o no según la tienda.
• Empleados y permisos, es decir, quién puede ver y editar cada tienda desde el backoffice.
• La configuración general y la de los módulos, con valores globales, por grupo o por tienda.

Datos comunes y datos por tienda

En la base de datos, muchas entidades tienen una tabla principal y otra asociada por tienda (la de producto y su equivalente con sufijo de tienda, por ejemplo). Unos campos viven en la tabla común y otros en la específica. Si un desarrollador modifica directamente la tabla común, cambia el dato en todos los escaparates aunque solo quisiera ajustar uno.

Documentar este reparto, aunque sea en una hoja sencilla, te ahorra muchos sustos. También es lo primero que conviene revisar en una auditoría técnica ecommerce cuando una instalación multitienda ha crecido sin documentación.

Cómo deben guardar su configuración los módulos

Los módulos son la fuente más habitual de cambios cruzados, sobre todo los que se desarrollaron sin pensar en multitienda o se adaptaron después. Estos son los fallos típicos:

• Guardan la configuración sin indicar grupo ni tienda, y el valor se aplica a todas.
• La leen sin contexto, de modo que una tienda acaba usando el valor de otra.
• Crean tablas propias sin columna de tienda y mezclan los datos de todos los escaparates.

Un módulo bien hecho toma del contexto actual el identificador de tienda y de grupo, guarda los valores en ese ámbito y muestra en su pantalla de configuración en qué nivel estás editando. Si tiene tablas propias, cada registro debe saber a qué tienda pertenece.

Qué revisar en un módulo existente

• Cómo se comporta su configuración con el selector en "Todas las tiendas", en un grupo y en una tienda concreta.
• Si sus hooks filtran los datos por tienda o devuelven resultados de todas.
• Si sus overrides o sus cambios de plantilla afectan a temas que usan otras tiendas.
• Qué pasa al instalarlo o desinstalarlo: si se activa en todas las tiendas o solo en la actual.

Si un módulo comprado no pasa esta revisión, lo normal es corregirlo o sustituirlo por módulos PrestaShop a medida pensados desde el principio para varios contextos.

Cron, importaciones y feeds: cómo fijar la tienda

En el backoffice hay un empleado que ha elegido un contexto. Un cron, un script de importación o un endpoint que genera un feed no tienen a nadie que lo elija por ellos. Si la tarea no fija la tienda de forma explícita, PrestaShop usará un contexto por defecto que quizá no sea el que esperas.

Un caso típico: un script nocturno importa precios desde el ERP y funciona sin problemas durante meses con una sola tienda. Se añade un segundo escaparate con otra tarifa y, sin que nadie toque el script, los precios de la tienda nueva se sobrescriben cada noche con los de la primera.

Para evitarlo, cada tarea automática debería:

• Recibir la tienda (o el grupo) como parámetro, o recorrerlas una a una de forma explícita.
• Establecer el contexto antes de leer o escribir datos.
• Dejar en el log qué tienda procesó, cuántos registros tocó y si hubo errores.
• Fallar de forma visible cuando no sabe a qué tienda pertenece un dato, en vez de suponer una.

Lo mismo vale para cualquier integración externa, ya sea un ERP, un marketplace, la herramienta de email o la plataforma logística. Si trabajas con integraciones ecommerce, deja documentado qué tienda corresponde a cada canal.

Plan mínimo de pruebas en multitienda

Probar solo la tienda que querías cambiar cubre la mitad del trabajo. La otra mitad consiste en comprobar que las demás siguen igual. Este plan sirve para casi cualquier cambio:

• En la tienda objetivo, verifica el cambio en ficha de producto, listado, carrito y checkout.
• En el resto de tiendas, revisa precio, impuestos, idioma, moneda, URL, disponibilidad y transportistas de esos mismos productos.
• Si comparten productos, haz un cambio común y otro exclusivo, y comprueba que cada uno aparece solo donde debe.
• Revisa la confirmación de pedido, la factura y las plantillas de email, porque cada tienda tiene que salir con su marca y sus datos.
• En el backoffice, repite la configuración con cada nivel del selector de contexto.

Trata este listado como un documento vivo y añade un caso cada vez que aparezca un error nuevo. Un entorno de preproducción con la misma estructura de tiendas que producción es casi imprescindible, porque en una copia con una sola tienda los cambios cruzados no pueden aparecer.

Cambios en temas y plantillas

Si varias tiendas comparten tema, un ajuste de CSS o de plantilla pensado para una llega a todas. Puedes usar temas hijos o condiciones por tienda y, en cualquier caso, revisar cada escaparate a ojo después de desplegar.

Cuándo compensa separar instalaciones

La multitienda sigue siendo la mejor opción cuando los escaparates comparten gran parte del catálogo, la operativa es parecida y el equipo es el mismo. Plantear instalaciones separadas empieza a tener sentido cuando:

• Las tiendas necesitan módulos o versiones incompatibles entre sí.
• Las diferencias de precios, logística o fiscalidad obligan a excepciones constantes.
• Cada cambio exige probar tantas combinaciones que el mantenimiento se ralentiza.
• Las integraciones con terceros se complican porque tienen que distinguir tiendas en todo momento.

Para decidir, pesa el coste de mantenimiento, el riesgo de cambios cruzados y las integraciones que ya tienes, además del número de tiendas. Con un buen mantenimiento PrestaShop puedes medir ese coste con datos reales de incidencias antes de tomar la decisión.

Checklist antes de publicar un cambio

• Sé en qué contexto (todas, grupo, tienda) se aplica el cambio.
• He revisado qué datos comparte la tienda afectada con las demás.
• El código guarda y lee la configuración indicando tienda y grupo.
• Las tareas automáticas fijan la tienda de forma explícita y lo registran.
• He probado la tienda objetivo y las que no deberían cambiar.
• Hay un plan de vuelta atrás si algo falla tras desplegar.

Si tu instalación ya muestra cambios cruzados o vas a añadir un escaparate nuevo, revisa la arquitectura antes de seguir acumulando excepciones.