PrestaShop multibotiga: com canviar una botiga sense tocar les altres

Gestionar diversos aparadors des d'una sola instal·lació de PrestaShop multibotiga estalvia feina: tens un únic backoffice, reutilitzes el catàleg, instal·les els mòduls una vegada i mantens un sol servidor. A canvi, cada modificació, per petita que sigui, s'executa dins d'un context, i aquest context decideix si el canvi afecta una botiga, un grup de botigues o totes. Gairebé ningú no ho explica al principi.

Abans de publicar, comprova en quina botiga funciona el canvi i en quines no hauria d'haver canviat res.

Els tres nivells de context de PrestaShop

PrestaShop organitza la multibotiga en tres nivells: totes les botigues, grups de botigues i botiga individual. Al backoffice, el selector de context de la part superior determina on s'aplica el que deses. Si ets a «Totes les botigues» i canvies un valor de configuració, aquest valor pot passar a ser el predeterminat de totes les botigues que no el tinguin sobreescrit.

Posem una empresa amb dos aparadors, un per al consumidor final i un altre per a professionals, on els preus es mostren sense IVA. Algú ajusta com es mostren els preus amb el context equivocat i la botiga de consumidor comença a ensenyar preus sense impostos. Ningú no ha tocat codi: n'hi ha hagut prou de desar un formulari al nivell incorrecte.

Per això l'equip ha de saber quin context fa servir, i per què, abans de qualsevol desenvolupament o ajust. Si a més hi ha desenvolupament PrestaShop multibotiga a mida, el mateix codi ha de respectar aquesta regla.

Quins elements es poden compartir a PrestaShop multibotiga

Tenir dominis diferents no separa les dades. Segons la versió i com estiguin configurats els grups de botigues, es poden compartir moltes coses, així que abans de desenvolupar fes inventari, com a mínim, d'aquestes:

• Productes i categories, que poden estar associats a diverses botigues amb una part de dades comuna i una altra pròpia de cada botiga.
• Preus i combinacions. El preu base, els impostos i les regles de preu poden variar per botiga o heretar-se.
• L'estoc. Si el grup de botigues comparteix existències, una venda en una botiga redueix les unitats disponibles a l'altra.
• Clients i comandes, que també es poden compartir dins del grup i afecten comptes, cistelles i historial.
• Idiomes, monedes i transportistes, actius o no segons la botiga.
• Empleats i permisos, és a dir, qui pot veure i editar cada botiga des del backoffice.
• La configuració general i la dels mòduls, amb valors globals, per grup o per botiga.

Dades comunes i dades per botiga

A la base de dades, moltes entitats tenen una taula principal i una altra d'associada per botiga (la de producte i la seva equivalent amb sufix de botiga, per exemple). Uns camps viuen a la taula comuna i d'altres a l'específica. Si un desenvolupador modifica directament la taula comuna, canvia la dada a tots els aparadors encara que només en volgués ajustar un.

Documentar aquest repartiment, encara que sigui en un full senzill, t'estalvia molts ensurts. També és el primer que convé revisar en una auditoria tècnica ecommerce quan una instal·lació multibotiga ha crescut sense documentació.

Com han de desar la configuració els mòduls

Els mòduls són la font més habitual de canvis creuats, sobretot els que es van desenvolupar sense pensar en la multibotiga o que es van adaptar després. Aquests són els errors típics:

• Desen la configuració sense indicar grup ni botiga, i el valor s'aplica a totes.
• La llegeixen sense context, de manera que una botiga acaba fent servir el valor d'una altra.
• Creen taules pròpies sense columna de botiga i barregen les dades de tots els aparadors.

Un mòdul ben fet agafa del context actual l'identificador de botiga i de grup, desa els valors en aquest àmbit i mostra a la pantalla de configuració en quin nivell estàs editant. Si té taules pròpies, cada registre ha de saber a quina botiga pertany.

Què cal revisar en un mòdul existent

• Com es comporta la configuració amb el selector a «Totes les botigues», en un grup i en una botiga concreta.
• Si els seus hooks filtren les dades per botiga o retornen resultats de totes.
• Si els seus overrides o els canvis de plantilla afecten temes que fan servir altres botigues.
• Què passa en instal·lar-lo o desinstal·lar-lo: si s'activa a totes les botigues o només a l'actual.

Si un mòdul comprat no passa aquesta revisió, el normal és corregir-lo o substituir-lo per mòduls PrestaShop a mida pensats des del principi per a diversos contextos.

Cron, importacions i feeds: com fixar la botiga

Al backoffice hi ha un empleat que ha triat un context. Un cron, un script d'importació o un endpoint que genera un feed no tenen ningú que el triï per ells. Si la tasca no fixa la botiga de manera explícita, PrestaShop farà servir un context per defecte que potser no és el que esperes.

Un cas típic: un script nocturn importa preus des de l'ERP i funciona sense problemes durant mesos amb una sola botiga. S'afegeix un segon aparador amb una altra tarifa i, sense que ningú toqui l'script, els preus de la botiga nova se sobreescriuen cada nit amb els de la primera.

Per evitar-ho, cada tasca automàtica hauria de:

• Rebre la botiga (o el grup) com a paràmetre, o recórrer-les una per una de manera explícita.
• Establir el context abans de llegir o escriure dades.
• Deixar al log quina botiga ha processat, quants registres ha tocat i si hi ha hagut errors.
• Fallar de manera visible quan no sap a quina botiga pertany una dada, en lloc de suposar-ne una.

El mateix val per a qualsevol integració externa, sigui un ERP, un marketplace, l'eina de correu electrònic o la plataforma logística. Si treballes amb integracions ecommerce, deixa documentat quina botiga correspon a cada canal.

Pla mínim de proves en multibotiga

Provar només la botiga que volies canviar cobreix la meitat de la feina. L'altra meitat consisteix a comprovar que les altres continuen igual. Aquest pla serveix per a gairebé qualsevol canvi:

• A la botiga objectiu, verifica el canvi a la fitxa de producte, al llistat, a la cistella i al checkout.
• A la resta de botigues, revisa el preu, els impostos, l'idioma, la moneda, l'URL, la disponibilitat i els transportistes d'aquests mateixos productes.
• Si comparteixen productes, fes un canvi comú i un altre d'exclusiu, i comprova que cadascun apareix només on toca.
• Revisa la confirmació de comanda, la factura i les plantilles de correu, perquè cada botiga ha de sortir amb la seva marca i les seves dades.
• Al backoffice, repeteix la configuració amb cada nivell del selector de context.

Tracta aquest llistat com un document viu i afegeix-hi un cas cada vegada que aparegui un error nou. Un entorn de preproducció amb la mateixa estructura de botigues que producció és gairebé imprescindible, perquè en una còpia amb una sola botiga els canvis creuats no poden aparèixer.

Canvis en temes i plantilles

Si diverses botigues comparteixen tema, un ajust de CSS o de plantilla pensat per a una arriba a totes. Pots fer servir temes fill o condicions per botiga i, en tot cas, revisar cada aparador a ull després de desplegar.

Quan compensa separar instal·lacions

La multibotiga continua sent la millor opció quan els aparadors comparteixen bona part del catàleg, l'operativa és semblant i l'equip és el mateix. Plantejar instal·lacions separades comença a tenir sentit quan:

• Les botigues necessiten mòduls o versions incompatibles entre si.
• Les diferències de preus, logística o fiscalitat obliguen a fer excepcions constantment.
• Cada canvi exigeix provar tantes combinacions que el manteniment s'alenteix.
• Les integracions amb tercers es compliquen perquè han de distingir botigues en tot moment.

Per decidir, sospesa el cost de manteniment, el risc de canvis creuats i les integracions que ja tens, a més del nombre de botigues. Amb un bon manteniment PrestaShop pots mesurar aquest cost amb dades reals d'incidències abans de prendre la decisió.

Checklist abans de publicar un canvi

• Sé en quin context (totes, grup, botiga) s'aplica el canvi.
• He revisat quines dades comparteix la botiga afectada amb les altres.
• El codi desa i llegeix la configuració indicant la botiga i el grup.
• Les tasques automàtiques fixen la botiga de manera explícita i ho registren.
• He provat la botiga objectiu i les que no haurien de canviar.
• Hi ha un pla de marxa enrere si alguna cosa falla després de desplegar.

Si la teva instal·lació ja mostra canvis creuats o hi afegiràs un aparador nou, revisa l'arquitectura abans de continuar acumulant excepcions.