Nous avons développé un petit plugin compagnon pour RSS Polling (discourse-rss-onebox) : les articles de blog importés s’affichent sous forme de onebox de l’article, avec des résumés de flux, des descriptions YouTube et des formats de titre optionnels. Trois lacunes nous ont contraints à envelopper des méthodes du cœur plutôt qu’à utiliser des hooks documentés.
-
Aucune sortie de plugin dans le formulaire de flux. rss-polling-feed-form.gjs#L287-L351 ne contient aucun
PluginOutlet, et le contrat de mise à jour n’accepte qu’un ensemble fixe d’attributs (update.rb#L9-L14). Un plugin ne peut pas ajouter une option par flux, ce qui a nécessité une page d’administration séparée pour le nôtre. Une sortie de plugin ainsi qu’un moyen de persister des champs supplémentaires (par exemple, des champs personnalisés de flux) couvriraient ce besoin. -
L’identifiant du flux n’atteint jamais l’import. Le travail de sondage (poll job) connaît
rss_feed_id, maisTopicEmbed.import(poll_feed.rb#L110) et le modificateurtopic_embed_import_create_args(topic_embed.rb#L108) ne le reçoivent jamais. Nous enveloppons le travail de sondage pour le capturer. Le transmettre comme option permettrait aux plugins d’agir par flux. -
Aucun hook sur le chemin de mise à jour. Lorsque le contenu d’un élément du flux change,
TopicEmbed.importrévisé le message avec le contenu du flux (topic_embed.rb#L147-L152), contournant ce que le modificateur de création avait fait. Un blogueur qui modifie un article transforme silencieusement un sujet façonné par un plugin en texte de flux. Un modificateur sur les changements de mise à jour, miroir detopic_embed_import_create_args, comblerait cette lacune.
Le contournement pour les points 2 et 3 consiste à préfixer TopicEmbed.import et le travail de sondage. C’est fragile : main a depuis ajouté un mot-clé truncate: à TopicEmbed.import, ce qui casse tout enveloppement qui reproduit la signature de 2026.7 - nous avons dû publier une version juste pour le transmettre. Des hooks documentés éviteraient ce type de rupture.