Por aquellos días de septiembre del año pasado (o sea, hace 4 meses) explicaba que estaba haciendo algunos experimentos de programar un plugin de WordPress 100% con IA… sí, IA para todo, «sin red».
En Internet 4 meses es como un año, y pensar que hace ya tanto tiempo que hice mis primeras pruebas del plugin de SMTP, parece muy lejano, sobre todo, porque ese plugin ha estado funcionando sin problemas en un centenar de sitios.
En las últimas semanas, he pasado de usar OpenAI Codex (por API) a Claude Code (por API), y eso también ha cambiado el paradigma un poco.
Entender bien cómo programar plugins
El mayor problema, como decía hace unos días, es saber programar plugins ya de antes… si no, plantear cualquier cosa, ya no sólo un plugin de WordPress, se convierte en todo un mundo.
Y es que sobre todo, lo que creo más importante es saber «cómo». La metodología, la experiencia, el saber comenzar desde cero y saber escalar y pedirle las cosas importantes en cada momento. Esto es la clave para que un proyecto, producto, plugin, sitio, o cualquier cosa que se le pida a nivel de código, sea correcto. Saber cuándo hay que preguntar antes de hacer, saber cuándo dejar que cree «a lo loco» y saber cuándo ir con cirugía.
Experimentos que se convierten en producto
Aunque aún me queda bastante por hacer, hemos comenzado a liberar algunos de estos plugins en versión estable, con actualización desde el propio WordPress.
Los primeros plugins liberados son los de SMTP (by ROBOTSTXT), SMTP (by ROBOTSTXT) Amazon SES, y SMTP (by ROBOTSTXT) Newsletter.
Hay que decir que el plugin genérico de SMTP nació como experimento de algo que más o menos controlo, que es el correo y WordPress, y quería ver hasta donde se podría llegar, partiendo de que muchos plugins de SMTP son premium y ofrecen cosas básicas como logs. Al final, la idea es que este plugin incluyese todo lo que siempre me había hecho falta, y más.
La extensión de Amazon SES, también fue un poco por experimentar. Aunque hasta hace poco no nos hemos puesto a usarlo, sí que teníamos algún cliente cons us sistemas configurados, y el hacer un experimento con esta parte parecía divertido. Pero tampoco era plan de crear un plugin desde cero, así que se convirtió en una extensión del plugin de SMTP. Si tienes la extensión de Amazon, el SMTP «tradicional» se reemplaza por el envío de Amazon, pero la parte de estadísticas, herramientas, logs y demás, siguen siendo las generales del plugin «core».
Viendo que hay muchos clientes (incluidos nosotros) que usan Google, Microsoft y otros sistemas, es posible que planteemos extensiones para esos sistemas, y las dejemos también en abierto.
Necesidades que se convierte en producto
Comod ecía, a algún cliente le hemos sustituido sus sistemas de SMTP por el plugin creado… pero al final no deja de ser un reemplazo del wp_mail(). Y ¿qué ocurre con esto? Pues que sigue sin escalar.
WordPress no está pensando para mandar miles de correos, si no mandar correos transaccionales: login, recuperar contraseña, que si alguien deja un comentario, etc., pero no para mandar miles de correos (cientos, aún, no decenas de miles). Y esto es lo que ocurre cuando planteas el envío de boletines desde WordPress.
Es algo que desde hace un tiempo venimos planteando con el plugin Newsletter, que personalmente me gusta mucho y es muy extensible. En ese sentido, la escalabilidad, sin problema. Hasta que llega tener que enviar decenas de miles de correos.
Tras hacer algunas pruebas con el MTA de envíos, todo indicaba que no había problema en mandar muchos mails de forma simultánea… pero eso a WordPress no le gusta, porque está pensado para mandar correos «de uno en uno». Y sí, puedes configurar Newsletter con un servicio de SMTP externo (de pago), pero la idea era usar el MTA del cliente.
¿Solución? Ya tenemos un plugin que manda correos, pero hay que hackear un poco el sistema de envíos cuando es desde Newsletter… así que, preparamos (casi sin documentación) el SMTP (by ROBOTSTXT) Newsletter, que tiene un truco: mantener abiertas las conexiones con el «Keep Alive» de PHPMailer, que es lo que usa de fondo WordPress.
En cualquier caso, no fue sencillo y hubo que entrenar un poco al sistema dándole a leer los otros plugins de SMTP de Newsletter, para que viera «cómo lo hacen los demás» y ver qué funciona y que no, porque se quedó atorado un rato en algo que está documentado, pero que en realidad no funciona.
Más ideas y desarrollos
Aunque los plugins de SMTP son los que ya están públicos, tengo una lista de plugins ya hecha y funcionando de forma aleatoria en algunos sitios, como el plugin de Changelog, 2FA, Firewall, Install by URL…
Tengo la esperanza de poder ir puliéndolos y publicarlos poco a poco, porque alguno de ellos ya me ha salvado el culo en más de una ocasión, y creo que son plugins que pueden ayudar a muchas cosas de administración, con un impacto muy bajo en cuanto a coste tecnológico (la mayoría, ni siquiera afectan al frontal).
Refactorizar y auditar
Otra cosa que estoy haciendo últimamente es auditar e incluso refactorizar plugins de clientes. Ya sea porque los hizo el cuñado de turno (y en esto, me incluyo a mí mismo, de hacer un plugin rápido por parchear algo) o porque lo ha hecho una agencia o un desarrollador externo.
En muchos casos los plugins de los clientes pueden dejar de funcionar por alguna cosa pequeña de compatibilidad de PHP o de WordPress, y a veces con un simple arreglo es suficiente. Y aquí hay que reconocer que la IA ayuda mucho, pero has de saber muy bien qué es lo que haces, porque si no, te reprograma todo entero y deja de funcionar…
Plugins de calidad, siguiendo las buenas prácticas
Si algo estoy aprendiendo, personalmente, de todo esto, ya te digo que noe s programar, que eso ya llevo un par de décadas haciéndolo… pero sí que ayuda a mejorar algunas maneras de programar código que yo siempre hacía de una manera y el sistema te muestra otra, o a encontrar ideas que no se te habían ocurrido…
Eso sí, hacer un plugin bien requiere de mucha cirugía, de mucho trabajo detallista, de entender bien qué se quiere en el futuro, porque no es lo mismo hacer un plugin pequeño con 4 funciones, que algo escalable con clases, o un experimento en el que estoy ahora, con namespaces.
Sin duda es bastante emocionando el momento en el que vivimos… seguro que en unos pocos años esto de programar ha cambiado radicalmente (ya lo ha hecho en 4 meses), pero aun así, creo que de cara a hacer cosas profesionales, es un paso importante. Al final estamos en ese momento de «mi sobrino me hace la web gratis» tan mencionado a finales de los 1990s, principios de los 2000s.
Deja una respuesta