He creado CartoBlocks for Leaflet, un plugin para acercar los mapas profesionales en WordPress a todo el público. Por supuesto, lo he hecho con la ayuda de la IA, y te cuento aquí cómo ha sido este viaje.
Cualquiera que me conozca desde hace tiempo, sabe que, en mi vida profesional anterior, trabajé como geólogo y analista GIS. Los mapas me han acompañado y han sido mi pasión durante mucho tiempo. Y así sigue siendo. Pero también el mundo web y, en especial, WordPress eran mi otra pasión y parte de mi profesión.
En todo este tiempo, uno de mis objetivos era llegar a fusionar ambas pasiones, pero tengo mis limitaciones y, si bien llevo tocando código desde que era un niño, no siempre llegaba a pasar de cositas pequeñas. Y programar para GIS no es precisamente fácil. O al menos a mí no me resultaba fácil.
Desde hace ya algún tiempo tenía claro que si quería hacer algo en WordPress, debía hacerlo creando un plugin de mapas con Leaflet. Pero esto ya estaba hecho, y además era muy bueno. Me refiero al plugin, del que ya he hablado aquí más de una vez, Leaflet Map, de Bozdoz. Este plugin me encanta, especialmente porque es lo que más se acerca a un GIS en WordPress, al menos a la hora de crear un mapa. Porque puedes crear un mapa a partir de múltiples capas, sumando elementos hasta hacer mapas bastante complejos.
Pero hay algo que suponía un punto de fricción para el público general, y es que crear un mapa complejo a base de shortcodes puede llegar a ser muy lioso, especialmente para alguien que no esté familiarizado con el concepto.
Idea y punto de partida
Como digo, yo quería crear un plugin de mapas, pero no quería reinventar la rueda. El mejor plugin de mapas para WordPress con Leaflet estaba ya creado. Yo no iba a aportar nada nuevo en este sentido, pero sí que podía facilitar su uso. Este plugin tiene de bueno que permite que se le añadan plugins adicionales con los que añadirle funcionalidades. De hecho, existe Extensions for Leaflet Map, otra maravilla de plugin que permite retorcer más las posibilidades del plugin original, hasta llegar a hacer mapas verdaderamente profesionales.
Mi idea fue añadirle a Leaflet Map una capa por encima que facilitara al usuario su uso. Es decir, crear un bloque de mapa que permitiese crear un mapa con la experiencia del editor de bloques de WordPress, pero utilizando como motor Leaflet Map. Esta idea rondó por mi cabeza mucho tiempo, mi problema eran mis conocimientos de programación, y en concreto de programación para WordPress.
Programar para WordPress puede ser fácil o difícil, aquí el problema estaba en que mi parte iba a ser mayoritariamente la programación de un bloque para el editor de bloques. Es decir, React, JavaScript. Y ahí estoy mucho más limitado. Estuve aprendiendo, hice el curso de programación de plugins de Learn WordPress, con objeto de entender cómo se programa un plugin, también aprendí JavaScript, pero aquí fue donde vi que la cosa se complicaba mucho, que programar bloques son palabras mayores.
Pero en todo este tiempo, llegó la inteligencia artificial, y me di cuenta de que podría ayudarme a hacerlo (estamos hablando de los primeros momentos). Hice pruebas pero todo era un desastre. Pero, como todos sabemos, en cuestión de dos a tres años, hemos vivido varias vidas en una. Y estaba yo todavía con ChatGPT cuando empecé a hacer mis primeras pruebas en serio para esta fase del plugin. También probé con Gemini, pero fue un desastre, con este modelo hice la primera versión inicial del plugin, y fue penoso. Quiso crearlo todo desde cero, sin tener en cuenta el plugin original, con lo que se creaba un bloque que se lo guisaba y se lo comía todo solito y además, lo hacía mal.
Entonces, siguiendo los consejos de Fernando Tellado, que tuvo a bien dedicarme parte de su tiempo, y me orientó con Claude. Me dio buenos consejos (ahí todavía no estaba claro ni qué estaba haciendo), y generosamente compartió su curso de programación para WordPress (no solo conmigo, sino con los primeros que en el 20 aniversario de AyudaWP se lo pidiéramos). Y ahí aprendí muchas cosas.
Así que finalmente me pasé a Claude, y específicamente a Claude Code.
Preparación del entorno y estándares
Me monté mi entorno de programación con Laravel Herd y DBngin. Sí es raro, pero esto lo aprendí en el curso de Learn WordPress, y me ha ido muy bien. Por otro lado, al principio empecé chateando con Claude (y anteriormente los anteriores modelos de IA) y pegando código, pero eso era vivir como los salvajes, hasta que por fin me pasé a Claude Code, y ahí empezó a fluir todo. Lo único es que tuve que aprender a lidiar con la frustración de llegar a los límites de tokens cada dos por tres. Era como cuando de niño negociaba las horas de tele o de ordenador.
También tuve que aprender a montar el entorno con los ficheros CLAUDE.md (global y de proyecto), a configurarle los estándares WPCS, inculcarle las medidas de seguridad. Para eso también me sirvieron muchísimo las skills de Fernando Tellado. Especialmente las tres de wp-plugin.
Por cierto, un aporte que supuso un antes y un después, especialmente en mi economía de tokens, fue el que hizo Álex Castellón, desarrollador de Close.marketing, cuando me aconsejó utilizar Caveman, una skill que le cierra el pico a Claude y hace que hable como una persona normal y no como un político borracho venido arriba. Esto fue clave.
Dificultades
Una de las primeras dificultades fue hacerle entender a Claude cómo debía lanzar las versiones (o se le olvidaba o sacaba una versión por cada línea que escribía), pero lo peor fue hacerle entender que tenía que respetar el plugin de Leaflet Map, que nosotros solo éramos una capa entre el usuario y el plugin original, y que el que iba a renderizar el mapa en el frontend iba a ser el propio Leaflet Map y no Cartoblocks for Leaflet.
Se barajaron tres arquitecturas hasta dar con la buena:
- ServerSideRender: el problema es que el mapa no se reinicializaba, y era un verdadero peñazo hacer nada. No valía.
- Renderizado client-side con Leaflet nativo en el editor: había un montón de bugs de instanceof entre frames, los tiles de OpenStreetMap devolviendo 403 por falta de cabecera Referer, y eso no estaba bonito. Daba la sensación de trabajar con un plugin pirata.
- Iframe con endpoint AJAX: ésta fue la definitiva. El iframe cargaba una página real de WordPress ejecutando los shortcodes de verdad. Además, resolvía el 403 y garantizaba que la vista previa fuese idéntica al frontend.
Otra dificultad fue el tratar de evitar la sincronización entre bloques, es decir, que si incluías varios bloques, cada uno fuera independiente del otro, y así se pudiesen crear diferentes mapas en una misma página.
Una vez resuelto todo esto, que todavía conseguía pintar un mapa y ya, fue el momento de dar el pistoletazo de salida y empezar a implementar características. Si te recorres el panel del bloque, podrás imaginar todo lo que supuso.
Además, le añadí controles de calidad al plugin, con tests, linting y Cl:
- PHPCS + PHPStan + Jest + GitHub Actions desde v0.5.
- Suite PHPUnit posterior (115 tests / 304 aserciones), con tests de caracterización para los sanitizadores.
- Hardening de seguridad: validación de origen en postMessage, wp_safe_remote_get, esc_url en overlays.
En la versión 1.1.0 (esto ya indica que no íbamos bien con las versiones, de cara al lanzamiento en el repositorio de WordPress.org), tuve que hacer una refactorización a fondo, aprovechando los tres días que tuvimos de Fable 5 (el bueno). De esta forma, el fichero principal pasó de 1450 a 95 líneas y render.php de 614 a 105. Y así pude arreglar otras muchas cosas. Además, le añadí la internacionalización.
La revisión de WordPress.org
Llegar a este punto me parecía poco menos que imposible, pero al final llegué. Para preparar el plugin, recomiendo mucho leer este artículo de David Pérez, que me vino bien. Pero fue clave una herramienta que conocí a través de un tweet que se me cruzó de Jamie Marsland. Se trata de PressShip, que facilita muchísimo la primera subida del plugin para su revisión. Le pasé la documentación a la IA, y con algunos prompts, hice la subida.
Ahí empezó la revisión, en la que inicialmente me pidieron cambiar dos tonterías (una se trataba de una cagada por mi parte, por no tener conocimientos de programación).
- Cambiar el nombre original «Blocks for Leaflet Map» a otro, y se me ocurrió llamarlo «CartoBlocks for Leaflet«.
- Por otro lado, la IA me había metido la librería TGMPA, en lugar de usar el header nativo Requires Plugins (WP 6.5+). Esto hace que, al instalar mi plugin, te exija instalar Leaflet Map, ya que es una dependencia de CartoBlocks for Leaflet. Bueno, esta fue mi novatada.
Hubo dos revisiones más, con algunos detalles más del plugin, y finalmente el despliegue del plugin. Era una de las cosas a las que más miedo le tenía, ya que no tenía ni idea de SVN, que es el sistema de versiones que se utiliza en el repositorio para subir los plugins. Pero de nuevo vino David al rescate con este mini-tutorial explicando cómo se publica un plugin directamente desde GitHub en SVN. Espectacular.
Con estas ayudas y acompañado de Claude Code, finalmente hoy tengo mi plugin publicado en el repositorio de WordPress.org.
Ah, y por supuesto, ya está traducido al español, por lo que se puede disfrutar también en nuestro idioma.
