Plugin WordPress, 100% creado por IA

Si eres desarrollador de WordPress, seguro que ya te has preguntado (si es que no lo has intentado) si se puede crear un plugin de WordPress con alguno de los motores de Inteligencia Artificial que existen.

Hasta ahora

He de reconocer que desde que está ChatGPT… seguramente desde la versión 3.x, he usado mis conversaciones para mejorar, optimizar, intentar replantear partes de código, pero siempre con muchísima supervisión, porque te la acababa liando parda.

Hasta ahora.

Probar un experimento

Hace unas semanas que llevaba dándole vueltas a un experimento que, como no, tenía un trasfondo útil: necesitaba un plugin de SMTP para WordPress que hiciera todo lo que hacen muchos plugins premium, pero de una forma mucho más simple.

Y también descubrí cómo hacer funcionar de una manera más o menos decente Codex, la herramienta específica de ChatGPT especializada en programación.

Como se puede sincronizar GitHub con ChatGPT, hice algunas pruebas con el plugin de WPVulnerability, ya que necesitaba mejorar algunas cosas… y me sirvió para entender cómo funcionaba la herramienta. Eso sí, todo esto se basaba en todo el código que ya tenía hecho previamente, así que no dejaba de ser una evolución de ese «pedirle cosas a ChatGPT» pero creando PRs.

Un plugin ¿desde cero?

La cuestión era… ¿Se podría crear un plugin desde cero? Ya os adelanto que la respuesta es que sí, aunque hay muchos «peros».

Lo principal: tener claro qué se quiere, sobre todo a nivel de funcionalidad, y esto incluye cuál sería la creación del mínimo producto viable, en qué orden crearlo, cuáles serían las distintas fases, milestones, llámalo como quieras, para hacer el producto poco a poco. Porque ese es el secreto.

La otra cosa es que hay que saber programar y entender un poco de Git… principalmente para poder ir probando en tiempo real todo. Yo me monté un WordPress en un servidor, y sincronicé directamente el Git con la web. De esa forma, cada vez que había un PR o cualquier cambio podía ver el código en tiempo real. A esto le sumamos un entorno de desarrollo, sin cachés, y con todos los logs de errores activos.

También hay que saber cómo funciona WordPress. No es suficiente con saber cómo se programa en PHP, sino también de las propias funciones de WordPress.

Algunas reglas

Un detalle importante es darle reglas claras desde un buen principio. Al final son buenas prácticas a la hora de desarrollar y para facilitarle la vida.

Por ejemplo, siempre le digo que revise todo con PHPCS (PHP Coding Standards) y WPCS (WordPress Coding Standards), pero como Codex programa con espacios, le dije además que no usase espacios, sino tabulaciones para el indentado. Si no, se pasa muchísimo rato, simplemente, corrigiéndose a sí mismo.

También le dije que fuera bastante estricto en cuanto al uso de una versión concreta de PHP (en este casi PHP 8.2 hasta PHP 8.4), y que intentase usar funciones de WordPress mayores a la versión 6.6, aunque posteriormente pude detectar que el código funcionaba bien con WordPress 6.0 o superior.

Y, la regla principal: pídele pocas cosas lo más concretas posible.

En mi caso le iba diciendo lo que íbamos a hacer, a grandes rasgos, pero, la última línea era algo como «no crees todo, vamos a ir paso a paso, primero haz esto». De esa forma tiene la idea general, y deja algunos placeholders, que vienen muy bien para posteriormente ir llenando esos huecos.

La seguridad

Sin duda, otro de los grandes elementos que hay que tener en cuenta desde el principio es pedirle que siga las reglas estándar de seguridad de WordPress, sobre todo en lo que respecta al uso de los nonces, sanitización y validación de datos, porque a veces se vuelve un poco loco y no sabe corregir sus propios errores.

Esto me deja ver también que, partiendo de la base de que estos modelos de IA se basan en código existente, la gente que hace plugins, lo de la seguridad no lo lleva bien. Pensaba que no era tanto, pero sí, creo que es mucho más de lo que parece.

Así que, dedicadle mucho cariño, sobre todo al pedirle código nuevo.

Documentar todo

Otro detalle que le he ido pidiendo todo el rato, también como base, es que documente todo con PHPDoc, que es el estándar en general que se usa en WordPress y en muchos proyectos.

Esto permite que también que él mismo entienda y sepa qué hace cada función, ya que cuando crea los entornos de desarrollo se lee todo el código, y si encima de cada función hay una explicación, él mismo es capaz de entenderse mejor.

AGENTS.md

Otro de los descubrimientos fue que existe algo llamado «agents.md». Este es un fichero en Markdown que básicamente los agentes (como Codex) leen cada vez que crean un entorno, y que no deja de ser un fichero con instrucciones.

Vendría a ser el «robots.txt» para los buscadores, sumados a un «Sitemap».

Vendría a res el README que tenemos los humanos para entender un proyecto.

La diferencia es que es un fichero que puedes explicar las cosas a tu manera. Incluso, le puedes decir a ChatGPT o al propio Codex que lo cree con base en un proyecto existente.

Este fichero ya es un estándar para Codex, Gemini, Copilot… as´que deberías tenerlo en tu proyecto, incluso para otros usuarios que puedan participar en el proyecto de forma externa y no sepan muy bien qué hacen… pues que las IA sí que lo sepan.

Algunas cosas a añadir: el entorno, versiones a usar, etc., cómo quieres que programe, si quieres que use algún tipo de validación para comprobar el código…

El resultado

Después de varios días y muchas horas (creo que le he dedicado más de 24 horas a este proyecto) ha salido un plugin para WordPress de SMTP que tiene varias cosas.

Soporte MultiSite: con esto en un WordPress simple va, y en el MultiSite te permite una configuración global o una por sitio.

Configuración SMTP: con un formulario en el que se piden los datos básicos de cualquier envío SMTP.

Guardar los logs de los envíos: siempre con una de dos limitaciones posibles, ya sea por cantidad de correos, o por cantidad de días. De esta forma nunca será ilimitado, ya que guarda los mensajes como si fueran «posts».

Prueba de envío de correo: que hace tanto cuando añades la configuración, como de forma específica con un botón.

Visualización de logs: porque si el correo falla, que no se pierdan los mensajes.

Y varias herramientas: que miran los registros MX, el SPF, DKIM, DMARC, un detalle más amplio de una petición SMTP, y listas negras.

Autoactualización (no usa WordPress.org)

Otra de las reglas de este plugin es que no iba a subirlo a WordPress.org. Entre otras muchas cosas porque ni tiene telemetría, la idea es que sea un plugin de uso interno (aunque es descargable y público) y que he creado para los sitios propios de ROBOTSTXT, los de colegas que quieran usarlo, y los de algunos clientes que siempre tienen problemas con los correos…

Además, hace un tiempo me dijeron que «hay demasiados plugins de SMTP en el repo», por lo que ni me voy a molestar en enviarlo.

Eso sí: necesito que se actualice automáticamente.

Y para ello hay 4 funciones sencillas que lo permiten, de forma muy sencilla. Y es creando un fichero JSON donde estén los datos del plugin, y donde se le indica la versión y la URL de descarga.

En el plugin se le dice que cuando WordPress revise si hay versiones nuevas de cosas, lo mire, y si hay una versión nueva, se actualiza. Simple y fácil. Más de lo que me pensaba, que hay gente que monta la NASA para hacer cosas así, y no es para tanto.

Amazon SES

Uno de nuestros clientes usa Amazon SES para el envío de correos… así que ¿por qué no dar soporte a Amazon si ya tengo un plugin que hace los envíos?

La cosa es que no quería llenar el plugin base con mil funcionalidades innecesarias, y código que no se va a usar nunca… por lo que «hagamos un add-on para nuestro plugin base».

Y así salió la idea de complementar el plugin SMTP con el de SMTP Amazon SES. La idea es la misma, que usando las funciones, tests y otras herramientas, se «sustituya» el formulario de los datos del SMTP por los datos de la API de Amazon.

Esto implicó hacer cambios en la manera en la que se gestiona el repositorio, ya que tenía que compartir el código base… pero tras varias idas y reorganizaciones, ambos plugins están en el mismo repo.

Esto implica que para usar el plugin de Amazon SES es necesraio disponer del plugin principal SMTP.

Información y descarga

Al no ser un plugin que está en el repositorio, tenía que poner un poco de contenido en algún sitio, así que dentro de la propia web de ROBOTSTXT hay una sección de plugins, donde hemos añadido estos nuevos.

¿Estoy contento?

Pues la verdad es que sí. Por un lado, porque si tienes un poco de conocimiento, puedes hacer plugins o elementos de WordPress de una calidad más que razonable y competir con lo que hacen plugins premium de alto nivel. No voy a mentir si dugo que me he fijado en como hacen muchas cosas muchos otros plugins.

Lo siguiente, porque veo un potencial de mejorar lo que algunos clientes necesitan con plugins sencillos que hacen algo muy concreto, sin sobrecargar el WordPress.

Y para acabar, porque ha sido una experiencia que merece la pena ser contada.

En producción

Seguramente te puedes estar preguntando: pero ¿y se puede usar el plugin? Y sí, la respuesta es sí.

Ahora mismo lo tengo puesto en producción en más de 30 sitios web y en todos está funcionando perfectamente… al menos por ahora.

Ideas futuras y roadmap

Poco a poco se me van ocurriendo algunas mejoras a hacer. Tampoco es que haya una hoja de ruta muy grande o muy clara… seguramente mejorar algunas herramientas, y validar que para cada versión de WordPress funciona. por ejemplo, ahora en WordPress 6.9 habrá cambios en el PHPMailer, así que hay que estar atentos a que no se rompa nada.