El WordPress Plugin Boilerplate en 2026: ¿sigues debiendo usarlo?

El WordPress Plugin Boilerplate de 2014 enseñó a una generación de developers cómo estructurar un plugin. En 2026, con la IA haciendo scaffolding en segundos, ¿merece la pena partir de él? La respuesta honesta es más interesante que un sí o un no.

Lo que el boilerplate nos dio

Cuando los plugins de WordPress eran un amasijo de functions.php, el boilerplate imponía cosas que realmente faltaban: separación clara entre admin y público, clase loader para hooks, fichero de uninstall, setup de internacionalización, y convención de nombres basada en el slug.

Dos de esas siguen valiendo. La separación admin/público evita toda una clase de bugs donde lógica admin corre en el front. El fichero de uninstall mantiene limpia la BD. Las otras tres son discutiblemente obsoletas: el loader es solución a un problema de PHP 5.2 que ya no existe, la i18n en 2026 se maneja mejor desde los JSON del editor de bloques, y las convenciones de nombres las impone cualquier linter moderno.

Lo que la generación con IA te da en su lugar

Cuando describes un plugin a una IA, te saltas el scaffolding. Obtienes solo las clases y ficheros que el plugin realmente necesita. Para un plugin con tres shortcodes públicos y sin admin, no heredas seis stubs vacíos que no vas a rellenar.

No es una cosa menor. He visto plugins con boilerplate donde el 40% de los ficheros están vacíos porque nadie los escribió. Esos huecos se vuelven code smell: los lectores asumen que son importantes, salen en las búsquedas y confunden al futuro mantenedor.

Dónde el boilerplate aún gana

Si construyes algo complejo con un equipo de devs no todos senior, el boilerplate les da un mapa consistente. Todos saben dónde va el admin. Todos saben dónde añadir un hook. Esa uniformidad es difícil de replicar con salidas de IA, que es buena produciendo una estructura sólida pero no recordará qué estructura usaste la vez pasada sin decírselo.

El boilerplate también facilita el onboarding. Un dev nuevo puede leer el readme y saber la arquitectura de cualquier plugin construido sobre él. Los generados con IA, incluso por la misma persona con los mismos prompts, varían ligeramente.

El enfoque híbrido que recomiendo

Tened un documento de convenciones de equipo. No un boilerplate completo, una o dos páginas describiendo cómo queréis estructurar los plugins: dónde va el admin, cómo manejar opciones, cómo atar cron, cómo gestionar i18n. Pasa esas convenciones como contexto a tu agente de IA.

La IA producirá código que encaje con las convenciones del equipo sin que mantengas 40 ficheros vacíos en un repo template. Lo mejor de ambos mundos: velocidad de IA + consistencia de equipo.

Ejemplo concreto

El documento de convenciones de mi equipo son 600 palabras. Dice cosas como "pon todas las opciones de WordPress detrás de YourPluginName_Options::get(key) por si migramos el storage", o "todos los endpoints REST en includes/rest/ con una clase por familia de endpoint". La IA las sigue cada vez porque son parte del prompt.

Hace más de un año que no uso el boilerplate clásico. Tampoco he recibido queja alguna de inconsistencia en plugins generados, que era el problema que resolvía el boilerplate.

¿Y los bloques?

Aquí el boilerplate se nota más su edad. Se diseñó cuando los bloques no existían. Intentar atornillar bloques sobre él parece retrofit. Los plugins generados con IA que incluyen bloques siguen los patrones de @wordpress/create-block, que es ahora el estándar casi oficial para esa parte del código.

Si tu plugin es principalmente extensiones del editor de bloques, sáltate el boilerplate. El block editor tiene sus propias convenciones y no encajan bien con el scaffold de 2014.

Uninstall y deactivation siguen siendo innegociables

Uses boilerplate o generes con IA, asegúrate de que tu plugin limpia lo que deja atrás. Opciones, tablas custom, eventos cron, transients. El número de plugins que he auditado que dejan basura tras la desactivación es deprimente. El boilerplate tenía stub de uninstall.php. Hagas lo que hagas, rellénalo.

Entonces: ¿lo uso o no?

Si eres nuevo en desarrollo de plugins y no has publicado ninguno, lee las fuentes del boilerplate. Entiende por qué se estructura como se estructura. Luego descártalo y genera tu primer plugin con IA usando las lecciones de arquitectura del boilerplate como contexto. Acabarás con algo más limpio y específico que cualquiera de los dos por separado.

Si tienes equipo, el trabajo real está en documentar vuestras propias convenciones, no en clonar las de otros. El boilerplate no puede saber las preferencias de tu equipo. Un agente de IA, con vuestras convenciones como contexto, las aplica perfectamente en cada nuevo plugin.

El boilerplate fue buena respuesta a un problema real en 2014. El problema se ha movido. La respuesta también debería.