Abbiamo creato un piccolo plugin di accompagnamento per l’RSS Polling (discourse-rss-onebox): i post del blog importati vengono renderizzati come un onebox dell’articolo, con riepiloghi facoltativi dei feed, descrizioni di YouTube e formati del titolo. Tre lacune ci hanno costretto a wrappare i metodi core invece di utilizzare gli hook documentati.
-
Nessun plugin outlet nel modulo del feed. rss-polling-feed-form.gjs#L287-L351 non dispone di un
PluginOutlete il contratto di aggiornamento accetta un insieme fisso di attributi (update.rb#L9-L14). Un plugin non può aggiungere un’opzione per singolo feed, quindi il nostro necessitava di una pagina di amministrazione separata. Un outlet insieme a un modo per persistere campi aggiuntivi (ad esempio, campi personalizzati del feed) risolverebbe questo problema. -
L’ID del feed non raggiunge mai l’importazione. Il job di polling conosce
rss_feed_id, maTopicEmbed.import(poll_feed.rb#L110) e il modificatoretopic_embed_import_create_args(topic_embed.rb#L108) non lo ricevono mai. Wrappiamo il job di polling per catturarlo. Passarlo come opzione consentirebbe ai plugin di agire per singolo feed. -
Nessun hook sul percorso di aggiornamento. Quando il contenuto di un elemento del feed cambia,
TopicEmbed.importrevisiona il post con il contenuto del feed (topic_embed.rb#L147-L152), eludendo ciò che il modificatore di creazione aveva fatto. Un blogger che modifica un post trasforma silenziosamente un topic formattato dal plugin di nuovo in testo del feed. Un modificatore sui cambiamenti di aggiornamento, che specchitopic_embed_import_create_args, chiuderebbe questa lacuna.
La soluzione temporanea per i punti 2 e 3 è il prepending di TopicEmbed.import e del job di polling. Questo approccio è fragile: main ha successivamente aggiunto una keyword truncate: a TopicEmbed.import, che rompe qualsiasi wrapper che specchi la firma del 2026.7 - abbiamo dovuto rilasciare una versione solo per passarla correttamente. Gli hook documentati eviterebbero questa classe di interruzioni.