Una de las grandes ventajas de WordPress es precisamente la cantidad de cosas que podemos resolver sin desarrollar prácticamente nada desde cero. Hay plugins para formularios, reservas, SEO, seguridad, tiendas online, áreas privadas, mapas, calendarios, automatizaciones y casi cualquier funcionalidad que podamos imaginar. Esto permite construir proyectos bastante complejos con tiempos y costes razonables, y es una de las razones por las que sigo considerando WordPress una herramienta perfectamente válida para una parte muy importante de las webs profesionales.
El problema aparece cuando confundimos esa enorme disponibilidad de plugins con la idea de que siempre debe existir uno que encaje exactamente con lo que necesitamos.
En bastantes proyectos llega un momento en el que buscar otro plugin deja de ser la solución y empieza a formar parte del problema. Instalamos uno porque resuelve un 70 % de lo que necesitamos, añadimos otro para cubrir el 20 % restante y terminamos colocando algún fragmento de código para corregir el último 10 %. A partir de ahí empiezan las incompatibilidades, las configuraciones duplicadas y esa sensación bastante habitual de que una funcionalidad relativamente sencilla está sostenida por demasiadas piezas.
Es precisamente en ese punto cuando merece la pena plantearse si no sería mejor desarrollar un plugin personalizado.
Un plugin personalizado no debería ser la primera opción
Cuando empiezo una web en WordPress no parto de la idea de programar todo desde cero. Sería absurdo.
Si WooCommerce resuelve correctamente una tienda online, no tiene sentido crear un sistema de comercio electrónico propio. Si Elementor permite construir una determinada estructura visual, tampoco merece la pena programarla manualmente salvo que haya un motivo concreto. Lo mismo ocurre con formularios, SEO, copias de seguridad o caché.
Utilizar herramientas maduras permite aprovechar años de desarrollo, pruebas, compatibilidad y mantenimiento que sería imposible replicar razonablemente en un proyecto normal.
Por eso, para mí, la pregunta correcta no es si podemos crear un plugin personalizado, sino si hacerlo simplifica realmente el proyecto.
Hay veces en las que desarrollar algo propio sería innecesariamente caro. En otras, sin embargo, unas pocas horas de desarrollo pueden sustituir varios plugins, eliminar configuraciones que nadie utiliza y dejar una herramienta mucho más fácil de mantener.
La diferencia suele estar en lo específica que sea la necesidad.
Cuando el cliente necesita una herramienta, no simplemente una funcionalidad
Una diferencia importante que he encontrado con los años es que muchas veces una web deja de ser simplemente una colección de páginas y empieza a convertirse en una pequeña herramienta de trabajo.
Puede ocurrir, por ejemplo, que una empresa necesite gestionar ubicaciones sobre un mapa, introducir información desde el panel de WordPress y mostrarla posteriormente siguiendo unas reglas concretas. Evidentemente existen muchos plugins de mapas, algunos muy completos, pero precisamente esa amplitud de opciones puede convertirse en una desventaja cuando el cliente necesita algo mucho más específico.
Un ejemplo es el plugin de mapas configurables que desarrollé en Premiero.
La necesidad no era simplemente colocar Google Maps o un mapa con varios marcadores. El objetivo era disponer de un sistema integrado en WordPress que permitiera gestionar determinadas ubicaciones y presentarlas exactamente de la forma que necesitaba el proyecto. En un caso así, adaptar continuamente un plugin genérico puede acabar resultando más complicado que desarrollar una solución pequeña específicamente diseñada para ese trabajo.
Y esta es, probablemente, una de las mejores señales para plantearse un desarrollo personalizado: cuando tenemos que dedicar más esfuerzo a impedir que un plugin haga cosas que no necesitamos que a configurar las que sí necesitamos.
Cuando la información tiene una lógica muy concreta
Otro escenario habitual aparece cuando WordPress tiene que gestionar información estructurada que no encaja demasiado bien dentro del modelo habitual de páginas y entradas.
Supongamos que una empresa publica todas las semanas una serie de menús. Es posible hacerlo creando entradas, duplicando plantillas, editando páginas o utilizando campos personalizados. Técnicamente todas esas soluciones pueden funcionar.
Pero también podemos preguntarnos cuál será la experiencia dentro de seis meses para la persona que tenga que actualizar la web.
Si cada lunes alguien tiene que copiar una página, cambiar fechas, modificar varios bloques de Elementor y asegurarse de que el menú anterior desaparezca correctamente, quizá hemos construido una web que funciona para el desarrollador pero no una buena herramienta para quien tiene que utilizarla.
Por este motivo desarrollé también Premiero Menús Semanales, un plugin pensado para resolver una necesidad muy concreta sin obligar a gestionar ese contenido como si fueran páginas convencionales.
Este tipo de desarrollos no buscan competir con plugins comerciales que sirven para miles de webs diferentes. Buscan exactamente lo contrario: resolver muy bien un problema que aparece dentro de un proyecto determinado.
Y muchas veces eso permite simplificar enormemente el mantenimiento posterior.
Cuando empezamos a acumular demasiados plugins
No soy partidario de esa regla bastante extendida de que una web WordPress es mala simplemente porque tenga muchos plugins instalados. El número, por sí solo, dice bastante poco.
Una web con treinta plugins bien desarrollados y correctamente mantenidos puede funcionar perfectamente, mientras que otra con ocho puede tener problemas constantes.
Lo que sí considero una señal de alerta es empezar a instalar varios plugins para construir entre todos una única funcionalidad.
Imaginemos que necesitamos crear un pequeño sistema interno para gestionar solicitudes. Instalamos un plugin para crear un tipo de contenido personalizado, otro para los campos, otro para modificar las columnas del administrador, otro para permitir ciertas acciones y terminamos añadiendo código adicional para conectar todo.
La solución funciona, pero hemos creado una dependencia entre cuatro herramientas diferentes que evolucionarán de forma independiente.
En determinadas situaciones, un plugin personalizado de unos cientos o unos pocos miles de líneas puede resultar mucho más sencillo.
Además, permite que toda la lógica relacionada con esa funcionalidad esté en el mismo lugar. Si dentro de un año hay que modificar algo, sabemos exactamente dónde buscar.
Cuando WordPress empieza a formar parte de un proceso interno
Otra situación donde cada vez encuentro más sentido al desarrollo personalizado es cuando WordPress deja de ser únicamente la web pública y comienza a interactuar con procesos internos de la empresa.
Puede tratarse de enviar determinados datos a un CRM, generar registros automáticamente, conectar formularios con herramientas externas, importar información, crear pequeños paneles internos o automatizar tareas que anteriormente se hacían manualmente.
En estos proyectos es relativamente habitual que no exista un plugin que resuelva exactamente el flujo necesario, porque ese flujo pertenece a la propia empresa.
Podemos encontrar plugins que conectan WordPress con Salesforce, por ejemplo, pero otra cuestión diferente es que reproduzcan exactamente la lógica comercial, los campos, los estados y las automatizaciones que necesita un proyecto determinado.
Cuanto más específica sea la relación entre la web y los procesos internos, más posibilidades hay de que un desarrollo personalizado termine siendo más limpio que una sucesión de integraciones genéricas.
También tiene otra ventaja importante: podemos controlar qué ocurre en cada paso.
Cuando trabajamos con varios plugins conectados entre sí, en ocasiones resulta complicado determinar dónde se ha producido un error. Con una integración propia podemos registrar procesos, validar datos y gestionar errores teniendo en cuenta la lógica real del proyecto.
El usuario que administra la web también importa
Hay algo que a veces se olvida al diseñar una web: WordPress no termina cuando publicamos la página.
Después alguien tendrá que utilizarla.
Una de las cosas que intento tener en cuenta al desarrollar herramientas propias es que la persona que gestione posteriormente el contenido no debería necesitar conocer cómo está construida la web.
Si para publicar una información tiene que recordar que debe crear una entrada, seleccionar una categoría concreta, editar tres campos personalizados, modificar un widget de Elementor y después borrar manualmente la información anterior, probablemente podemos hacerlo mejor.
Un plugin personalizado permite diseñar también la experiencia dentro del administrador.
Podemos crear exactamente los campos necesarios, ponerles nombres comprensibles, ocultar opciones que no se utilizan y automatizar determinadas tareas. El objetivo debería ser que la persona encargada de actualizar la web tenga que pensar en su trabajo, no en WordPress.
En algunos proyectos esta mejora puede justificar por sí sola el desarrollo.
Si una tarea que se realiza todas las semanas pasa de necesitar quince minutos y varias comprobaciones a completarse en dos minutos desde un formulario sencillo, el tiempo invertido en desarrollar esa herramienta termina amortizándose rápidamente.
Cuando una función se va a utilizar durante años
También hay que pensar en la vida útil de lo que estamos construyendo.
Un desarrollo personalizado puede no tener demasiado sentido para una campaña que va a durar tres semanas. En ese caso probablemente sea mejor adaptar las herramientas existentes y resolver el proyecto rápidamente.
Pero si estamos creando una funcionalidad central que la empresa utilizará durante años, la decisión cambia.
Una pequeña inversión inicial puede evitar durante mucho tiempo licencias innecesarias, procesos manuales, incompatibilidades entre plugins y configuraciones difíciles de mantener.
Esto es especialmente relevante cuando hablamos de herramientas muy concretas del negocio: directorios, gestores de campañas, sistemas de reservas especiales, importadores, pequeñas intranets, paneles internos o automatizaciones.
En estos casos suelo valorar el coste no únicamente desde el punto de vista del desarrollo inicial, sino también desde el mantenimiento futuro.
También hay razones para no crear un plugin
Por supuesto, desarrollar algo propio no siempre es la mejor decisión.
Un plugin personalizado implica asumir cierta responsabilidad sobre ese código. Hay que mantenerlo compatible con nuevas versiones de WordPress y PHP, revisar posibles problemas de seguridad y actualizarlo cuando cambian las necesidades del proyecto.
Por eso considero importante distinguir entre funcionalidades específicas y problemas generales.
No desarrollaría un sistema propio de comercio electrónico, un plugin completo de SEO o una solución de seguridad para una web convencional. Existen herramientas excelentes dedicadas específicamente a eso y mantener una alternativa propia tendría muy poco sentido.
Tampoco desarrollaría un plugin únicamente para evitar pagar una licencia de 50 o 100 euros al año. Si una herramienta comercial resuelve exactamente el problema, tiene un buen soporte y se mantiene actualizada, normalmente esa licencia será bastante más barata que mantener nuestro propio código.
La personalización merece la pena cuando existe una ventaja real, no simplemente porque técnicamente podamos hacerla.
¿Cómo decidir entonces?
Normalmente hay algunas preguntas que ayudan bastante a tomar la decisión.
Podemos analizar si existe ya un plugin que cubra realmente la necesidad, cuánto tendremos que modificar para adaptarlo, cuántas herramientas adicionales necesitamos instalar, cuánto tiempo va a utilizarse esa funcionalidad y quién tendrá que gestionarla posteriormente.
También conviene preguntarse qué ocurrirá cuando haya que modificarla.
Si cambiar una pequeña regla obliga a revisar configuraciones repartidas entre varios plugins, probablemente estamos creando una solución demasiado compleja.
En cambio, si una herramienta comercial cubre perfectamente el flujo de trabajo y únicamente necesita una pequeña configuración inicial, desarrollar algo propio no aportará demasiado.
No existe un número de horas o una regla matemática que indique cuándo merece la pena dar el paso. Es fundamentalmente una cuestión de complejidad y mantenimiento.
El mejor plugin personalizado suele ser bastante pequeño
Existe además cierta tendencia a imaginar un plugin personalizado como un enorme desarrollo de software. En realidad, algunos de los desarrollos más útiles que hago son bastante pequeños.
Su valor no está en la cantidad de código, sino en eliminar pasos.
Un plugin puede limitarse a crear un tipo de contenido específico, añadir varios campos, automatizar una fecha y proporcionar un shortcode para mostrar los datos. No es una plataforma enorme, pero quizá sustituye un proceso manual que el cliente llevaba años realizando.
Este tipo de herramientas encajan especialmente bien con WordPress porque podemos aprovechar todo lo que la plataforma ya proporciona: usuarios, permisos, base de datos, administración, editor, API REST y sistema de plugins.
No necesitamos reconstruir WordPress. Simplemente añadir la pieza que falta.
Y para mí esa es precisamente la forma más interesante de abordar estos desarrollos.
WordPress funciona mejor cuando sabemos hasta dónde utilizar cada herramienta
Después de trabajar durante años con WordPress he terminado viendo los plugins personalizados menos como una alternativa a los plugins comerciales y más como un complemento.
Hay proyectos donde prácticamente todo puede resolverse utilizando herramientas existentes. Hay otros donde una pequeña pieza desarrollada a medida simplifica de manera importante el conjunto.
La experiencia está en saber distinguirlos.
Instalar un nuevo plugin es muy fácil, y precisamente por eso conviene detenerse de vez en cuando y pensar si realmente estamos simplificando el proyecto o simplemente desplazando la complejidad hacia otro sitio.
Cuando una funcionalidad es específica del negocio, se utilizará durante mucho tiempo, requiere conectar varios procesos o necesita una experiencia de administración especialmente sencilla, desarrollar un plugin personalizado puede ser una inversión perfectamente razonable.
No porque WordPress no tenga suficientes plugins.
Probablemente tenga demasiados.
Sino porque algunas veces la solución más sencilla es dejar de buscar uno que haga aproximadamente lo que necesitamos y construir uno que haga exactamente eso.