Overrides a PrestaShop: riscos, hooks i com auditar-los

Els overrides a PrestaShop permeten substituir mètodes de les classes i els controladors del nucli sense editar els fitxers originals. Durant anys van ser la manera ràpida de canviar com es calcula un preu, quines dades demana el registre o què passa en desar una comanda, i moltes botigues n'acumulen força, uns instal·lats per mòduls i d'altres afegits a mà, que solen donar problemes en actualitzar. Repassem com funcionen, per què fallen en actualitzar, quines alternatives hi ha amb hooks i serveis i com auditar els que ja té la teva botiga.

Què és un override a PrestaShop

Les classes del nucli de PrestaShop es diuen, per exemple, ProductCore o CartCore, i la resta del codi fa servir Product o Cart. Si no hi ha override, Product és una extensió buida de ProductCore. Si crees un fitxer a la carpeta override/classes que defineix Product estenent ProductCore, PrestaShop fa servir la teva versió, i els mètodes que hi escriguis substitueixen els originals.

El mateix val per als controladors de la botiga i del back office, per a la classe principal d'un mòdul i per als seus controladors. Un mòdul pot portar els seus propis overrides: quan l'instal·les, PrestaShop en copia els mètodes a la carpeta override de l'arrel, i quan el desinstal·les els retira. Els que algú va posar a mà no tenen ningú que els retiri. PrestaShop desa a la memòria cau l'índex de classes, així que després d'afegir o treure un override cal buidar la memòria cau perquè es tingui en compte.

No s'ha de confondre amb sobreescriure plantilles de mòduls des del tema, que és una pràctica normal i es fa millor en un tema fill. Un override de PHP canvia la lògica del nucli; una plantilla al tema canvia el que es veu.

Per què els overrides fallen en actualitzar PrestaShop

Un override substitueix un mètode sencer. El més habitual és copiar el mètode original, canviar-ne dues línies i deixar la resta igual. A partir d'aquest moment la botiga executa la còpia, i qualsevol correcció que PrestaShop faci al mètode original, incloses les de seguretat, no s'arriba a executar mai. Res no avisa: la versió corregida del mètode simplement no es fa servir.

Altres errors sí que es veuen, i solen aparèixer després d'un canvi de versió:

• La signatura del mètode canvia al nucli (paràmetres nous, tipus declarats) i l'override ja no és compatible. A PHP 8 això produeix un error fatal i la pàgina no carrega.
• El mètode o la classe desapareixen o canvien de lloc, i l'override queda orfe o trenca la càrrega de classes.
• Parts del back office han passat a Symfony. Un override d'un controlador antic d'una pàgina migrada deixa d'aplicar-se sense avisar, perquè la pàgina ja fa servir un altre codi.

A més, els overrides són exclusius. Si dos mòduls volen sobreescriure el mateix mètode, un dels dos no podrà instal·lar el seu override o algú acabarà fusionant-los a mà. Per això PrestaShop els desaconsella en mòduls que es distribueixen i no els admet als mòduls dels seus partners. A la guia per actualitzar PrestaShop sense trencar mòduls expliquem on encaixa la seva revisió dins del pla d'actualització.

Hooks: l'alternativa als overrides a PrestaShop

Els hooks són punts del codi on PrestaShop avisa els mòduls que passa alguna cosa o els demana contingut. N'hi ha de dues famílies. Els de visualització, com els de la fitxa de producte o la cistella, permeten afegir contingut en un lloc concret. Els d'acció es disparen abans o després d'un esdeveniment, com desar un objecte, validar una comanda o canviar-ne l'estat, i permeten executar lògica pròpia.

Molts overrides es van escriure per a coses que avui es resolen amb un hook. Imagina un override de la classe Customer que envia les dades de cada client nou a un CRM: el mateix s'aconsegueix amb un mòdul enganxat al hook que es dispara després de crear el client, sense tocar la classe. Si el CRM canvia, canvies el mòdul, i una actualització del nucli no l'afecta mentre el hook continuï existint.

A les pàgines del back office que ja fan servir Symfony hi ha hooks per modificar llistats i formularis, per exemple per afegir una columna al llistat de comandes o un camp al formulari de client. Per a la lògica que no té hook, la via documentada és proposar-lo al repositori del projecte o buscar un altre punt d'entrada; un override continua sent possible, però convé que sigui l'excepció i que estigui documentat.

Serveis de Symfony i classes pròpies en lloc d'overrides

A la part de PrestaShop que funciona amb Symfony, un mòdul pot declarar serveis als seus fitxers de configuració. Pot substituir un servei existent amb el mateix nom, o decorar-lo: el servei nou embolcalla l'original, que continua disponible per cridar-lo. La decoració és l'opció més segura, perquè només canvies el que necessites i la resta del comportament continua sent el del nucli.

Cal saber on funciona cada cosa. El back office migrat té accés al contenidor complet de Symfony, mentre que les pàgines de la botiga continuen fent servir controladors antics amb un contenidor més limitat. Un servei pensat per al back office no està disponible a la botiga si no es declara també per a ella.

Per a dades noves, la recomanació oficial és una taula pròpia amb la seva classe de model dins del mòdul, en lloc d'afegir camps a Product o Customer mitjançant un override. Així les dades del mòdul viuen al mòdul i s'instal·len i es desinstal·len amb ell. Si estàs valorant si et compensa un desenvolupament així, a PrestaShop: mòdul propi o comprat tens els criteris.

Com auditar els overrides de la teva botiga

L'auditoria es fa en una còpia de la botiga, no a producció. L'objectiu és saber què hi ha, d'on ve i què es pot treure abans de la propera actualització.

Per al llistat, revisa les subcarpetes d'override (classes, controladors i mòduls) i anota cada mètode sobreescrit. Per saber-ne l'origen, busca el mateix fitxer dins de la carpeta override de cada mòdul instal·lat. PrestaShop sol deixar un comentari amb el nom del mòdul damunt dels mètodes que instal·la, tot i que no sempre hi és i no convé refiar-se només d'això. El que no apareix a cap mòdul és manual, i és el que necessita més cura perquè ningú no recorda per què hi és.

Després compara cada mètode amb l'original de la teva versió i amb el de la versió a la qual vols actualitzar. Si l'override és una còpia amb un parell de línies canviades, ja saps què fa realment. A l'apartat de rendiment dels paràmetres avançats hi ha, segons la versió, una opció per desactivar tots els overrides. Activar-la a la còpia i repetir una comanda de prova mostra ràpidament què en depèn.

Amb aquesta informació, cada override acaba en un d'aquests destins:

• S'elimina, perquè pertany a un mòdul desinstal·lat o fa una cosa que ja no es fa servir.
• Se substitueix per un hook, un servei decorat o una classe pròpia dins d'un mòdul PrestaShop a mida.
• Es manté de moment, amb una nota del que fa, per què no té alternativa i què cal revisar a cada actualització.

Després de cada canvi, buida la memòria cau i prova una comanda completa amb cada mètode de pagament i transportista. Si la botiga és multibotiga, prova també cada aparador.

Llista de comprovació abans de tocar els overrides de la teva botiga

• Còpia de la botiga restaurada, protegida i desconnectada de pagaments reals, ERP i correus a clients.
• Llistat d'overrides amb el seu mètode, el seu origen i la data en què es va afegir si se sap.
• Comparació amb el nucli de la teva versió actual i de la versió de destinació.
• Mòduls que instal·len overrides identificats, amb la seva versió i si encara es mantenen.
• Alternativa decidida per a cada override: hook, servei, classe pròpia o mantenir-lo documentat.
• Proves de comanda completes després de cada retirada.
• Document final amb els overrides que es queden i per què.

Si vols que fem aquesta revisió amb tu, a manteniment PrestaShop comencem per aquest inventari abans d'actualitzar o de tocar cap mòdul.