Cuándo sacar una funcionalidad del theme y convertirla en un plugin de WordPress

En WordPress es bastante habitual que una funcionalidad empiece siendo algo pequeño.

Un shortcode, unas cuantas funciones en functions.php, un Custom Post Type, algo de JavaScript y unas reglas CSS. En ese momento parece razonable mantenerlo dentro del theme, especialmente si la funcionalidad se ha creado específicamente para esa web.

El problema aparece cuando esa pequeña personalización empieza a crecer.

De repente tiene su propio tipo de contenido, taxonomías, configuración, diferentes formas de visualización, traducciones, permisos o incluso gestión de archivos.

En ese punto conviene hacerse una pregunta: ¿sigue formando parte del diseño de la web o se ha convertido en una funcionalidad independiente?

Theme y plugin no deberían resolver el mismo problema

La separación conceptual es bastante sencilla.

El theme debería encargarse principalmente de cómo se presenta el contenido: estructura visual, estilos, plantillas y componentes relacionados con la interfaz.

Un plugin, en cambio, debería encargarse de funcionalidades que deberían seguir existiendo aunque mañana cambiáramos completamente el diseño de la web.

Por ejemplo, si tenemos un sistema para gestionar documentación técnica compuesto por:

• un tipo de contenido propio;
• categorías;
• archivos asociados;
• campos de configuración;
• buscadores;
• distintos layouts;
• y un shortcode para mostrarlo;

probablemente ya no estemos ante una simple característica del theme.

Estamos ante una pequeña aplicación dentro de WordPress.

El problema de acumular funcionalidad en functions.php

functions.php es muy cómodo.

Precisamente por eso acaba convirtiéndose con facilidad en el lugar donde se añade cualquier cosa.

El riesgo no está en tener unas cuantas funciones. El problema aparece cuando empezamos a introducir lógica que representa una parte importante del funcionamiento de la web.

Esto genera varias dependencias innecesarias.

La primera es evidente: si se cambia de theme, la funcionalidad desaparece.

Pero existen otras menos visibles.

El mantenimiento se vuelve más complicado, porque código visual y lógica funcional terminan mezclados. También resulta más difícil detectar dependencias, reutilizar componentes o modificar una parte del sistema sin afectar a otras.

Y a medida que pasan los años, esa deuda técnica se acumula.

Algunas señales de que ha llegado el momento de crear un plugin

No existe una regla absoluta, pero hay varias señales bastante claras.

La funcionalidad tiene sus propios datos

Si hemos creado Custom Post Types, taxonomías, tablas propias o estructuras de datos específicas, estamos probablemente ante algo que debería sobrevivir al theme.

Tiene una pantalla de configuración

Cuando una funcionalidad empieza a necesitar opciones propias en el administrador de WordPress, deja de ser únicamente una cuestión de presentación.

Tiene distintos modos de funcionamiento

Por ejemplo, varios layouts, filtros, categorías, permisos o parámetros configurables.

Cuanto mayor sea su lógica interna, más sentido tiene aislarla.

Gestiona archivos o información sensible

Sistemas de descargas, documentación privada, formularios internos, portales de usuario o contenidos protegidos deberían estar especialmente desacoplados del theme.

Podríamos imaginarla funcionando con otro diseño

Es probablemente la prueba más sencilla.

Si mañana cambiáramos completamente el diseño de la web y la funcionalidad siguiera teniendo sentido, probablemente debería ser un plugin.

Convertirlo en plugin no significa rehacerlo todo

Uno de los miedos habituales al separar una funcionalidad existente es perder información.

Pero si la migración se plantea correctamente, los contenidos existentes pueden mantenerse intactos.

Los Custom Post Types y las taxonomías no pertenecen físicamente al theme. Sus datos están almacenados en la base de datos de WordPress.

Por tanto, es posible trasladar el código que los registra desde el theme a un plugin manteniendo exactamente los mismos identificadores.

Lo mismo ocurre con muchos campos personalizados, relaciones y configuraciones.

La clave está en preservar la estructura de datos existente y cambiar únicamente el lugar desde el que se registra y gestiona.

Una arquitectura mucho más mantenible

Una funcionalidad que ha crecido lo suficiente suele agradecer una estructura independiente.

Por ejemplo:

• registro del Custom Post Type;
• registro de taxonomías;
• lógica de administración;
• configuración;
• shortcodes o bloques;
• assets CSS y JavaScript;
• gestión de archivos;
• permisos;
• funciones auxiliares.

No hace falta crear una arquitectura exageradamente compleja.

El objetivo simplemente es que cada parte tenga una responsabilidad clara.

A partir de ahí resulta mucho más sencillo evolucionar el sistema.

También facilita futuras mejoras

Separar correctamente una funcionalidad no solo mejora el código actual.

También abre posibilidades.

Podemos sustituir un shortcode por un bloque sin tocar el modelo de datos. Podemos añadir una API. Podemos cambiar completamente el diseño. Podemos reutilizar determinadas piezas. Podemos crear nuevas vistas.

La funcionalidad deja de depender de cómo estaba construida originalmente la página.

Y eso es especialmente importante en proyectos que llevan muchos años funcionando.

No todo necesita convertirse en un plugin

Tampoco conviene caer en el extremo contrario.

Una pequeña función relacionada exclusivamente con el comportamiento visual de un theme puede vivir perfectamente dentro de él.

Crear un plugin para cada pequeño ajuste únicamente aumenta la complejidad.

La cuestión no es cuántas líneas de código tiene una funcionalidad, sino qué responsabilidad cumple dentro del proyecto.

Una cuestión de arquitectura, no de preferencias

En proyectos WordPress que evolucionan durante años es normal que algunas soluciones iniciales terminen creciendo mucho más de lo previsto.

No significa necesariamente que se plantearan mal.

Simplemente las necesidades han cambiado.

Lo importante es detectar cuándo una personalización ha dejado de ser parte del theme y se ha convertido en una pieza independiente del sistema.

En ese momento, moverla a un plugin propio suele ser una de esas decisiones que apenas ve el usuario final, pero que facilita enormemente todo lo que viene después.