Hace unos 4 años (ya ni lo recuerdo) comencé un pequeño proyecto en el que la idea era simple: listar los eventos cercanos (España) para crear un mini-calendario en el que saber cuándo y dónde estaban los eventos WordPress.
La primera versión incluía sólo los eventos Meetup y si no recuerdo mal, los de Catalunya. En definitiva, una web «para mi», porque pretendía listar los eventos más cercanos.
Además, he de decir, que es un proyecto que no usa WordPress, y que es muy mejorable (todavía sigo usando el código de la primera versión, con mil parches) y es muy espagueti code.
Como me gusta trabajar las REST API, y me gusta WordPress, el proyecto creció para tener todos los eventos de España e incluso creé algunas integraciones con boletines que se mandaban a las Meetup informando de eventos cercanos a las distintas comunidades.
Después de eso, siguiendo con las ganas de aprender, añadí los eventos WordCamp desde las API de la Comunidad, e incluso pude montar unas excepciones para añadir «eventos que no vienen de API», es decir, eventos sobre WordPress que se hacen por el mundo, pero que «no son oficiales» (entre comillas). Así que: Meetup, WordCamp y Otros.
Hace un par de años Meetup cambió sus API y, para hacer lo que yo hacía, requería tener un Meetup Pro. 30 euros al mes por un proyecto sin publicidad (y no he querido poner, aunque me han ofrecido), y centrado sólo en un país. Además del uso que yo le daba, sé que algunas otras webs y podcast usaban esa lista para comunicar los eventos a sus lectores y oyentes.
La duda, en aquel momento, fue: ¿vale la pena pagar 360 euros/año para un proyecto como este? Amigos y otras personas de la Comunidad WordPress me invitaron a plantear el proyecto global, multi-idioma.
Así que, revisando otros proyectos, y haciendo un poco de ampliación, al final la web se quedó sólo en inglés (a nivel navegación) y consiguiendo añadir todos los países, con todas sus Meetup, añadiendo las redes sociales de las comunidades (principalmente Twitter) e incluso relacionando las Comunidades locales con las Comunidades WordCamp, para saber que, por ejemplo, la WordCamp Barcelona, la lleva el equipo de WordPress Barcelona.
Todo cambió hace poco más de un año. Llegó marzo de 2020 y, todos encerrados en casa, nos tuvimos que poner las pilas para hacer cambios. Que si ponemos [ONLINE] al principio del título de los eventos, que si Meetup ha cambiado su sistema… todos los que estábamos directa o indirectamente relacionados con el equipo de Comunidad corrimos de un lado al otro para que los eventos se hicieran desde casa. Y, permitidme que os diga: nos ha salido muy bien. Y añado: hay gente muy profesional en esto del vídeo en línea.
Entre el trabajo de día a día, mi mayor participación en el Hosting Team y algo de agotamiento tras 6 años gestionando WordPress Barcelona (y otros años menos con Santa Coloma y la recién creada L’Hospitalet) decidí alejarme de la parte de eventos, aunque he seguido participando cuando me lo han pedido.
Ha pasado un año y la situación es similar pero distinta. Por un lado, mucho trabajo. Por otro, más trabajo de administración de sistemas WordPress que ya ocupa gran parte de mi día, además de la creación de WPNoticias y WPpodcast y mi incorporación a WPRadio además de ayudar al equipo Meta de WordPress España, y por supuesto mi nombramiento de Hosting Team Rep.
WPCalendar es un proyecto que «va sólo». Hay que revisar un día a la semana por si aparecen más Meetup o WordCamp u otros eventos, revisar los horarios de los programas de las WordCamp y añadirlos (como digo, un día a la semana dedicándole 15 minutos suele ser suficiente). Simple y fácil para una herramienta como esta.
Pero hace unos días llegó un correo de Meetup diciendo que van a cambiar todo su sistema de API, eliminando la REST API y pasando a GraphQL. Me parece bien, está correcto mejorar la tecnología aunque no entiendo la razón del cambio, ya que, personalmente, creo que no aporta absolutamente nada mejorable a la API en sí. Seguro que ellos opinan lo contrario.
¿Problema? Tiempo y conocimiento. Como decía antes, WPCalendar no es un software que esté exquisítamente bien hecho. Es un sitio que funciona, va rápido y hace lo que ha de hacer de forma sencilla, pero, es un proyecto que se ha creado en mucho tiempo, del que ya en su día tuve que revisar mucho la documentación e «inventar» porque Meetup documenta muy mal, y en general me parece una muy mala plataforma, pero es la que se usa. Así que me puse a revisar cómo poder actualizar toda la fontanería de la web (la parte interna) para usar su nueva API.
Me he sentado delante de su documentación y es bastante abrumador. Por un lado porque GraphQL no es algo que domine, pero no debería ser un bloqueo; lo que sí que lo hace es la mezcla de no conocer GraphQL y una documentación que no entiendo y con unos ejemplos que no se parecen a la realidad que yo uso en la API (una API pensada para automatizar la creación de grupos y eventos, y no tanto para leer datos).
Desde que publiqué el mensaje de «parada» del servicio el 1 de agosto, me han llegado muchos mensajes de apoyo, e incluso de varias empresas de la Comunidad WordPress que quieren apoyar el proyecto. Y, por segunda vez en unos meses, me doy cuenta de lo grande y potente que es WordPress y la gente que está metida en el mundillo.
Ahora queda la duda de ¿qué hacer? Sin duda un primer planteamiento que voy a hacer es extender, al menos hasta el 1 de enero de 2022 el pago de la API y que todo siga generándose igual. Un parche, pero que nos da 5-6 meses de margen.
La segunda es cómo plantearme la evolución del proyecto. Personalmente creo que WordPress debería plantearse invertir lo que invierte la Fundación en los costes en desarrollar un proyecto interno, ya sea un plugin, ya sean unos Custom Post Type o lo que sea. Yo tengo bastante claro el modelo de datos en la cabeza, y a partir de ahí, construir, debería ser fácil. Nota: soy de sistemas, no programador WordPress (aunque sé programar PHP, no conozco tanto las profundidades de WordPress como para crear eso yo sólo).
Y siguiendo en este camino, lo siguiente es rehacer las APIs actuales y usar el GraphQL y dejar la REST-API. Esto sería la primera fase porque, después, y gracias a las API de WordPress que se han añadido en las últimas versiones, no descartaría (aunque lo tenga que hacer mediante plugins tipo Advanced Custom Fields) crear yo mismo esa «plataforma» y meter todos los datos históricos que tengo en un WordPress, y de paso hacerlo accesible a la comunidad.
En este último caso, requeriría reservar parte de mi jornada laboral al proyecto (no debería ser difícil acomodarlo) y es un proyecto que me motiva, pero la situación es que el tiempo va en contra de WPCalendar.
Deja una respuesta