Pensé que eran cambios menores en Channel2RSS 💀

Introducción

Dado que los feeds no se pueden modificar y menos los newsletter, muchas veces el feed puede llenarse de spam de botoneras, algo que puede no notarse en los canales originales debido a que mediante bots, estos post son borrados automáticamente cada cierto tiempo. Entonces la mejor opción es directamente ignorar las botoneras. Aun así, no es posible notar un patrón claro en ellas, así que, para evitar ignorar mensajes con botones y mensajes de hablando de las botoneras, se bloquea directamente mensajes de canales que tengan caption y en el caption se mencione la palabra botonera.

Obviamente esto funciona solo para español, pero si encuentro mejores criterios para discriminar este tipo de post, será algo que iré agregando conforme pase el tiempo.

He agregado el botón del ko-fi. Por los loles nada mas, no es que le tenga mucha esperanza XD

Las botoneras y otros bots

El contenido automatizado puede ser un problema por cuanto es difícil determinar cuando es deseado por el usuario o es simple spam. Entiendo que sean necesarios para alcanzar cierta divulgación en un entorno sin algoritmos ni recomendaciones, pero a diferencia del canal donde reside el bot, el feed RSS no puede ser editado (todavia) para borrar la publicidad de la botonera. Esto es especialmente molesto en el modo Newsletter, puesto que alli el contenido si que es permanente. No hay forma de invadir la bandeja del suscriptor solo para borrar la publicidad de la botonera y esta pasa a ser simple y puro spam.

De momento, solo detecto si un mensaje tiene la palabra botonera. Los bots pueden ser utilizados para publicaciones automáticas legitimas, por lo que discriminar por el tipo de usuario, puede ser contraproducente.

Las galerías o grupos de imágenes

Una de las funciones mas recientes pero que pasan desapercibidas son las galerías o grupos de imágenes. Al compartirlas, estas actúan como una sola entrada, pero en realidad son varias imágenes, cada una con su propia entrada y unicamente agrupadas mediante un media_group_id el cual debe ser interpretado por el cliente para mostrar las imágenes agrupadas. Por supuesto, el webhook recibe cada imagen por separado y simplemente las procesa como una entrada independiente cada una, produciendo que se publiquen muchas entradas sin texto y sin relación entre si.

Esto provoca una molesta inundación de post, tanto en el feed como en el newsletter, así que el primer paso para controlar esto fue, ignorar todas las publicaciones que tienen el campo media_group_id activo.

El problema del campo media_group_id es que no indica cuando comienza y cuando termina una galería. Telegram simplemente sigue tirando los mensajes a mi webhook y mi script solo puede procesar un mensaje a la vez. no puede quedarse esperando a la ultima imagen de la galeria y tampoco sabe cuando llegará, por lo que fue necesario crear un nuevo archivo llamado enviar_galeria.php donde se procesaría con mas calma los datos.

A diferencia del webhook, que es activado por un llamado de telegram por una url publica, enviar_galeria.php es llamado por cron usando PHP en la consola, cada minuto.

Me resulta imposible saber cuando llegará la ultima imagen de la galería que se este enviando, pero espero que lo haga en menos de un minuto, para que cuando el sistema lo analice, cree una galería completa, con su respectiva descripción.

He aprendido de paso que puedo ejecutar cron a modo de ruta relativa, algo así tipo:

* * * * * cd /var/www/misitio && php miscript.php

De esta manera, el script puede ejecutarse teniendo en cuenta las rutas relativas que ya tiene de por si.

Mejoras

Sigo estudiando buenas practicas de programación, asi que la creación de este nuevo archivo me ha dado la excusa perfecta para revisar el código y mejorarlo un poco. Al momento, el webhook procesa cada mensaje de forma lineal porque no necesita mas pasos para hacerlo, pero con la creación del enviar_galeria.php ya me di cuenta que hace falta una forma de reciclar el codigo. Especialmente para las funciones de procesar el RSS y enviar las Newsletter. Como primer paso, he creado dos métodos que se encargan de ello y como próximo paso, puede ser que empiece a estudiar como se crean librerías y claro, usarlas. De esta manera puedo tener uniformidad en el código y reciclarlo para que sea mas fácil de mantener.

Curiosidades

• El modo lectura lleva un mes fuera de linea, pero aun siguen llegando peticiones a esas URL. ¿Han quedado registradas en algún lado para algo en especifico?
• Desde las ultimas correcciones, las peticiones se han calmado y ya solo hay para los feeds por parte de mi lector RSS y el webhook de telegram. Como soy el único usándolo, no se si haya fallas para otros usuarios.
• Definitivamente es culpa del IDE Atheos, así que abandono su uso.
• Corregido una vulnerabilidad que expone la base de datos
• Hubo un incidente en el que el IDE reemplazo gran parte del archivo principal con galimatias al guardar. Afortunadamente tenia un archivo anterior con el que pude medio reparar el código, pero la verdad, se perdieron algunos cambios de los que no estoy seguro cuales fueron. Creo que finalmente me decidí en implementar git, pero me da miedo.

Desarrollo de Bots: Channel2RSS

Changelog 22 de noviembre de 2025

• Se ignora todo mensaje de bot que contenga la palabra botonera (case insensitive).
• En el flujo principal, se ignora el procesamiento de los mensajes media_group_id.
• Se crea una nueva tabla galerias en la base de datos.
• En el flujo principal, se almacena recursos en la base de datos en su tabla galerias.
• Se crea un archivo enviar_galeria.php para el procesamiento de los datos de la tabla galerías.
• Se crean los métodos guardar_entrada() y enviar_newsletter() para próxima creación de una librería.
• Editado index.php para mostrar este changelog, claro.

TODO

• Había un error en algún lado pero me olvide donde esta. Tengo que depurar mas pero me da pereza.
• Hay que implementar git.
• Hay que corregir las entradas existentes para cumplir los lineamientos del validador de xml.