Plugin a mida per a WooCommerce: quan compensa davant d'un de comprat

Triar entre un plugin a mida per a WooCommerce o continuar sumant plugins comprats gairebé mai es decideix de cop. La botiga arrenca amb una dotzena d'extensions, cada problema nou es resol amb una altra i, un parell d'anys després, ningú no recorda què fa cadascuna ni quina va trencar el checkout l'última vegada que es va actualitzar. En aquesta guia repassem quan té sentit comprar, quan escriure codi propi i on ha de viure aquest codi perquè aguanti les actualitzacions.

El que costa mantenir molts plugins a WooCommerce

Cada extensió afegeix codi que es carrega en algunes pàgines o en totes, ajustos propis, de vegades taules a la base de dades i un calendari d'actualitzacions que no controles. Amb pocs plugins gairebé no es nota, però quan se n'acumulen, qualsevol actualització de WooCommerce o de WordPress obliga a fer una ronda de proves abans de tocar producció.

Els costos que no apareixen a la factura de la llicència solen ser aquests:

• Conflictes entre plugins que actuen sobre el mateix punt, per exemple dues extensions que modifiquen la cistella.
• Scripts i estils que es carreguen en pàgines on no fan res.
• Funcions encavalcades: diversos plugins que fan una cosa semblant perquè cadascun cobria un detall diferent.
• Llicències caducades que deixen un plugin sense actualitzacions de seguretat.
• Plugins abandonats pel seu autor que continuen actius perquè ningú no s'atreveix a treure'ls.

Imagina una botiga que fa servir un plugin per afegir camps al checkout, un altre per a regles d'enviament i un altre per mostrar aquests camps a la factura. Si el primer canvia el nom intern d'un camp en una actualització, els altres dos deixen de trobar-lo. L'error apareix dies després a les factures, lluny del canvi que el va provocar.

Quan un plugin comprat és la millor opció

Per a necessitats que comparteixen milers de botigues, comprar sol ser el més assenyat. Passarel·les de pagament, transportistes coneguts, feeds per a marketplaces o còpies de seguretat tenen extensions mantingudes per equips que només es dediquen a això i que segueixen els canvis de la plataforma abans que tu.

Abans d'instal·lar-ne un, revisa:

• Data de l'última actualització i si declara compatibilitat amb la teva versió de WooCommerce (la capçalera WC tested up to).
• Si declara compatibilitat amb HPOS, el sistema d'emmagatzematge de comandes que WooCommerce activa per defecte a les instal·lacions noves.
• Si carrega els seus recursos només a les pàgines on els fa servir.
• Què deixa a la base de dades quan el desinstal·les.
• Si resol el teu cas amb configuració o t'obliga a canviar el teu procés per adaptar-te a ell.

L'últim punt és el que més es passa per alt. Un plugin que cobreix gairebé tot però exigeix un pas manual a cada comanda acaba sortint car encara que la llicència sigui barata, perquè aquest pas el fa algú de l'equip a mà cada dia.

Quan compensa un plugin a mida per a WooCommerce

Un plugin a mida per a WooCommerce compensa quan la regla que s'ha de programar és teva: depèn de com vens, dels teus clients o d'un altre sistema, i cap plugin genèric no la coneix. Alguns casos habituals:

• Preus o descomptes que es calculen amb dades d'un ERP o d'una tarifa negociada.
• Regles d'enviament que combinen tipus de producte, magatzem de sortida i codi postal.
• Validacions de comanda pròpies, com quantitats per caixa, productes que no poden anar junts o clients que necessiten aprovació.
• Integracions amb magatzem, logística o facturació que han de registrar cada error.
• Substituir diversos plugins que es trepitgen per una sola peça que fa exactament el que necessites.

L'últim cas és més freqüent del que sembla. Sovint el plugin a mida reuneix en un únic lloc el que estava repartit entre tres o quatre extensions, amb menys codi carregat i un sol responsable, sense afegir cap funció que la botiga no tingués ja.

També compensa quan algú ja ha adaptat un plugin comprat editant-ne els fitxers. A partir d'aquell moment no es pot actualitzar sense perdre els canvis, així que hauràs de mantenir aquest codi igualment, sense documentació i barrejat amb el de l'autor.

functions.php davant d'un plugin propi

Bona part del codi a mida de WooCommerce acaba enganxat al fitxer functions.php del tema, perquè és el que proposen la majoria de tutorials. Per a un ajust visual petit pot servir, sempre dins d'un tema fill.

El problema és que functions.php pertany al tema. Si canvies de tema, el codi desapareix amb ell, i si algú el va afegir al tema pare, la següent actualització del tema l'esborra. Amb el temps, a més, aquest fitxer barreja retocs de disseny amb regles de preus, enviaments i correus, i costa saber què depèn de què.

Un plugin propi, encara que sigui petit, evita aquests problemes:

• Funciona igual amb qualsevol tema.
• Es pot desactivar per descartar que un error vingui d'aquí.
• Té el seu propi número de versió i pot viure en un repositori amb historial de canvis.
• Pot declarar compatibilitat amb HPOS i amb la versió de WooCommerce provada, igual que un plugin publicat.

Si el codi canvia com es veu la botiga, pot anar al tema fill. Si canvia com funciona (preus, estoc, comandes, enviaments o integracions), el seu lloc és un plugin.

Si hi afegeixes l'opció de comprar, les tres vies es comparen així:

Els plugins de fragments de codi són un terme mitjà raonable per a retocs petits. Tingues en compte que guarden el codi a la base de dades, sense control de versions, i que molts fragments solts acaben creant el mateix desordre que functions.php.

Hooks: com s'amplia WooCommerce sense tocar-ne el codi

WooCommerce és ple de punts d'enganxament, els hooks. Les accions permeten executar codi en un moment concret: quan es crea una comanda, quan canvia d'estat o en pintar el formulari de pagament. Els filtres permeten modificar una dada abans que es faci servir, com un preu, el text d'un botó o les tarifes d'enviament disponibles.

Un plugin ben escrit es basa en aquests hooks i no modifica fitxers de WooCommerce ni d'altres plugins. Quan WooCommerce s'actualitza, el teu codi continua enganxat al mateix punt. Si un hook canvia o es marca com a obsolet, l'avís sol arribar amb antelació a les notes de versió i l'ajust queda localitzat al teu plugin.

El que convé evitar:

• Editar fitxers de WooCommerce o d'un plugin comprat, perquè la següent actualització els sobreescriu.
• Copiar plantilles de WooCommerce al tema per canviar una línia. Cada còpia s'ha de revisar quan WooCommerce modifica l'original, i l'informe d'estat del sistema avisa de les que han quedat desfasades.
• Llegir i escriure comandes directament a la base de dades o amb funcions de WordPress pensades per a entrades. Amb HPOS les comandes viuen en taules pròpies i aquest codi deixa de veure dades o escriu on ningú no llegeix. Ho expliquem a la guia sobre HPOS a WooCommerce i com migrar sense trencar plugins.

Compatibilitat amb les actualitzacions de WooCommerce, WordPress i PHP

Després d'instal·lar un plugin a mida, WooCommerce i WordPress continuaran publicant versions i el servidor acabarà canviant de versió de PHP. Perquè aquestes actualitzacions no es converteixin en un problema, l'encàrrec hauria de preveure des del principi:

• Ús exclusiu de les funcions i classes públiques de WooCommerce per a comandes, productes i clients.
• Declaració de compatibilitat amb HPOS.
• Versió mínima de PHP i de WooCommerce indicada a la capçalera del plugin.
• Registre d'errors llegible, que digui quina comanda o quin producte n'ha quedat afectat.
• Una llista de proves que es repeteix abans de cada actualització: compra completa, cupó, canvi d'estat i reemborsament.

Amb aquesta base, actualitzar passa a ser una tasca de rutina dins del manteniment WooCommerce, amb un entorn de proves on aplicar primer cada versió.

Què demanar si encarregues un plugin a mida

Quan un desenvolupament a mida surt malament, sovint l'abast cabia en dues frases. Abans de demanar pressupost, descriu el procés amb exemples concrets: què passa en el cas normal, què passa quan alguna cosa falla i qui se n'ha d'assabentar.

En el lliurament hauries de rebre:

• El codi font complet, en un repositori al qual tinguis accés.
• Instruccions d'instal·lació, configuració i desinstal·lació neta.
• Versions de WooCommerce, WordPress i PHP amb què s'ha provat.
• Una descripció dels hooks que fa servir i de les dades que guarda, perquè un altre desenvolupador pugui continuar.
• Proves dels casos excepcionals si el plugin afecta comandes, estoc o preus.

A plugins WooCommerce a mida expliquem com plantegem aquests encàrrecs. Si el projecte implica més peces que un plugin, com canvis al tema, integracions o una reorganització del catàleg, encaixa millor en un desenvolupament WooCommerce complet.

Checklist per decidir entre plugin comprat i desenvolupament propi

• Fes inventari dels plugins actius i anota per a què serveix cadascun i qui el va demanar.
• Marca els que fa temps que no s'actualitzen o no declaren compatibilitat amb HPOS.
• Busca encavalcaments: diverses extensions que actuen sobre la cistella, el checkout o les comandes.
• Revisa el functions.php del tema i separa la lògica de negoci que hi hagi anat a parar.
• Per a cada necessitat nova, decideix si és comuna a moltes botigues o és una regla del teu negoci.
• Si és comuna i hi ha un plugin mantingut que la cobreix amb configuració, compra'l.
• Si és teva, depèn d'un altre sistema o genera feina manual cada dia, valora un plugin propi.
• Prepara una còpia de la botiga per provar qualsevol canvi abans de portar-lo a producció.

Si l'inventari et torna una llista llarga i no saps per on començar, una auditoria tècnica et diu quins plugins sobren i quins convé substituir per codi propi.