Plugin a medida para WooCommerce: cuándo compensa frente a uno comprado

Elegir entre un plugin a medida para WooCommerce o seguir sumando plugins comprados casi nunca se decide de golpe. La tienda arranca con una docena de extensiones, cada problema nuevo se resuelve con otra y, un par de años después, nadie recuerda qué hace cada una ni cuál rompió el checkout la última vez que se actualizó. En esta guía repasamos cuándo tiene sentido comprar, cuándo escribir código propio y dónde debe vivir ese código para que aguante las actualizaciones.

Lo que cuesta mantener muchos plugins en WooCommerce

Cada extensión añade código que se carga en algunas páginas o en todas, ajustes propios, a veces tablas en la base de datos y un calendario de actualizaciones que no controlas. Con pocos plugins apenas se nota, pero cuando se acumulan, cualquier actualización de WooCommerce o de WordPress obliga a una ronda de pruebas antes de tocar producción.

Los costes que no aparecen en la factura de la licencia suelen ser estos:

• Conflictos entre plugins que actúan sobre el mismo punto, por ejemplo dos extensiones que modifican el carrito.
• Scripts y estilos que se cargan en páginas donde no hacen nada.
• Funciones solapadas: varios plugins que hacen algo parecido porque cada uno cubría un detalle distinto.
• Licencias caducadas que dejan un plugin sin actualizaciones de seguridad.
• Plugins abandonados por su autor que siguen activos porque nadie se atreve a quitarlos.

Imagina una tienda que usa un plugin para añadir campos al checkout, otro para reglas de envío y otro para mostrar esos campos en la factura. Si el primero cambia el nombre interno de un campo en una actualización, los otros dos dejan de encontrarlo. El fallo aparece días después en las facturas, lejos del cambio que lo provocó.

Cuándo un plugin comprado es la mejor opción

Para necesidades que comparten miles de tiendas, comprar suele ser lo sensato. Pasarelas de pago, transportistas conocidos, feeds para marketplaces o copias de seguridad tienen extensiones mantenidas por equipos que se dedican solo a eso y que siguen los cambios de la plataforma antes que tú.

Antes de instalar uno, revisa:

• Fecha de la última actualización y si declara compatibilidad con tu versión de WooCommerce (la cabecera WC tested up to).
• Si declara compatibilidad con HPOS, el sistema de almacenamiento de pedidos que WooCommerce activa por defecto en las instalaciones nuevas.
• Si carga sus recursos solo en las páginas donde los usa.
• Qué deja en la base de datos al desinstalarlo.
• Si resuelve tu caso con configuración o te obliga a cambiar tu proceso para adaptarte a él.

El último punto es el que más se pasa por alto. Un plugin que cubre casi todo pero exige un paso manual en cada pedido acaba saliendo caro aunque la licencia sea barata, porque ese paso lo hace alguien del equipo a mano todos los días.

Cuándo compensa un plugin a medida para WooCommerce

Un plugin a medida para WooCommerce compensa cuando la regla que hay que programar es tuya: depende de cómo vendes, de tus clientes o de otro sistema, y ningún plugin genérico la conoce. Algunos casos habituales:

• Precios o descuentos que se calculan con datos de un ERP o de una tarifa negociada.
• Reglas de envío que combinan tipo de producto, almacén de salida y código postal.
• Validaciones de pedido propias, como cantidades por caja, productos que no pueden ir juntos o clientes que necesitan aprobación.
• Integraciones con almacén, logística o facturación que deben registrar cada error.
• Sustituir varios plugins que se pisan por una sola pieza que hace exactamente lo que necesitas.

El último caso es más frecuente de lo que parece. A menudo el plugin a medida reúne en un único sitio lo que estaba repartido entre tres o cuatro extensiones, con menos código cargado y un solo responsable, sin añadir ninguna función que la tienda no tuviera ya.

También compensa cuando alguien ya ha adaptado un plugin comprado editando sus archivos. A partir de ese momento no se puede actualizar sin perder los cambios, así que tendrás que mantener ese código igualmente, sin documentación y mezclado con el del autor.

functions.php frente a un plugin propio

Buena parte del código a medida de WooCommerce acaba pegado en el archivo functions.php del tema, porque es lo que proponen la mayoría de tutoriales. Para un ajuste visual pequeño puede valer, siempre dentro de un tema hijo.

El problema es que functions.php pertenece al tema. Si cambias de tema, el código desaparece con él, y si alguien lo añadió al tema padre, la siguiente actualización del tema lo borra. Con el tiempo, además, ese archivo mezcla retoques de diseño con reglas de precios, envíos y correos, y cuesta saber qué depende de qué.

Un plugin propio, aunque sea pequeño, evita esos problemas:

• Funciona igual con cualquier tema.
• Se puede desactivar para descartar que un fallo venga de ahí.
• Tiene su propio número de versión y puede vivir en un repositorio con historial de cambios.
• Puede declarar compatibilidad con HPOS y con la versión de WooCommerce probada, igual que un plugin publicado.

Si el código cambia cómo se ve la tienda, puede ir en el tema hijo. Si cambia cómo funciona (precios, stock, pedidos, envíos o integraciones), su sitio es un plugin.

Los plugins de fragmentos de código son un término medio razonable para retoques pequeños. Ten en cuenta que guardan el código en la base de datos, sin control de versiones, y que muchos fragmentos sueltos acaban creando el mismo desorden que functions.php.

Hooks: cómo se amplía WooCommerce sin tocar su código

WooCommerce está lleno de puntos de enganche, los hooks. Las acciones permiten ejecutar código en un momento concreto: cuando se crea un pedido, cuando cambia de estado o al pintar el formulario de pago. Los filtros permiten modificar un dato antes de que se use, como un precio, el texto de un botón o las tarifas de envío disponibles.

Un plugin bien escrito se apoya en esos hooks y no modifica archivos de WooCommerce ni de otros plugins. Cuando WooCommerce se actualiza, tu código sigue enganchado en el mismo punto. Si un hook cambia o se marca como obsoleto, el aviso suele llegar con antelación en las notas de versión y el ajuste queda localizado en tu plugin.

Lo que conviene evitar:

• Editar archivos de WooCommerce o de un plugin comprado, porque la siguiente actualización los sobrescribe.
• Copiar plantillas de WooCommerce al tema para cambiar una línea. Cada copia hay que revisarla cuando WooCommerce modifica la original, y el informe de estado del sistema avisa de las que se han quedado desfasadas.
• Leer y escribir pedidos directamente en la base de datos o con funciones de WordPress pensadas para entradas. Con HPOS los pedidos viven en tablas propias y ese código deja de ver datos o escribe donde nadie lee. Lo contamos en la guía sobre HPOS en WooCommerce y cómo migrar sin romper plugins.

Compatibilidad con actualizaciones de WooCommerce, WordPress y PHP

Después de instalar un plugin a medida, WooCommerce y WordPress seguirán publicando versiones y el servidor acabará cambiando de versión de PHP. Para que esas actualizaciones no se conviertan en un problema, el encargo debería contemplar desde el principio:

• Uso exclusivo de las funciones y clases públicas de WooCommerce para pedidos, productos y clientes.
• Declaración de compatibilidad con HPOS.
• Versión mínima de PHP y de WooCommerce indicada en la cabecera del plugin.
• Registro de errores legible, que diga qué pedido o producto se ha visto afectado.
• Una lista de pruebas que se repite antes de cada actualización: compra completa, cupón, cambio de estado y reembolso.

Con esa base, actualizar pasa a ser una tarea de rutina dentro del mantenimiento WooCommerce, con un entorno de pruebas donde aplicar primero cada versión.

Qué pedir si encargas un plugin a medida

Cuando un desarrollo a medida sale mal, a menudo el alcance cabía en dos frases. Antes de pedir presupuesto, describe el proceso con ejemplos concretos: qué pasa en el caso normal, qué pasa cuando algo falla y quién debe enterarse.

En la entrega deberías recibir:

• El código fuente completo, en un repositorio al que tengas acceso.
• Instrucciones de instalación, configuración y desinstalación limpia.
• Versiones de WooCommerce, WordPress y PHP con las que se ha probado.
• Una descripción de los hooks que usa y de los datos que guarda, para que otro desarrollador pueda continuar.
• Pruebas de los casos excepcionales si el plugin afecta a pedidos, stock o precios.

En plugins WooCommerce a medida explicamos cómo planteamos estos encargos. Si el proyecto implica más piezas que un plugin, como cambios en el tema, integraciones o una reorganización del catálogo, encaja mejor en un desarrollo WooCommerce completo.

Checklist para decidir entre plugin comprado y desarrollo propio

• Haz inventario de los plugins activos y anota para qué sirve cada uno y quién lo pidió.
• Marca los que llevan tiempo sin actualizarse o no declaran compatibilidad con HPOS.
• Busca solapamientos: varias extensiones que actúan sobre el carrito, el checkout o los pedidos.
• Revisa el functions.php del tema y separa la lógica de negocio que haya acabado ahí.
• Para cada necesidad nueva, decide si es común a muchas tiendas o es una regla de tu negocio.
• Si es común y hay un plugin mantenido que la cubre con configuración, cómpralo.
• Si es tuya, depende de otro sistema o genera trabajo manual a diario, valora un plugin propio.
• Prepara una copia de la tienda para probar cualquier cambio antes de llevarlo a producción.

Si el inventario te devuelve una lista larga y no sabes por dónde empezar, una auditoría técnica te dice qué plugins sobran y cuáles conviene sustituir por código propio.