RSS Polling: extension points for plugins (feed form outlet, feed ID in import, update-path hook)

Contribute Feature
1

We built a small companion plugin for RSS Polling (discourse-rss-onebox): imported blog posts render as a onebox of the article, with optional feed summaries, YouTube descriptions and title formats. Three gaps forced us into wrapping core methods instead of using documented hooks.

  1. No plugin outlet in the feed form. rss-polling-feed-form.gjs#L287-L351 has no PluginOutlet, and the update contract accepts a fixed set of attributes (update.rb#L9-L14). A plugin cannot add a per-feed option, so ours needed a separate admin page. An outlet plus a way to persist extra fields (feed custom fields, for example) would cover it.

  2. The feed ID never reaches the import. The poll job knows rss_feed_id, but TopicEmbed.import (poll_feed.rb#L110) and the topic_embed_import_create_args modifier (topic_embed.rb#L108) never receive it. We wrap the poll job to capture it. Passing it through as an option would let plugins act per feed.

  3. No hook on the update path. When a feed item’s content changes, TopicEmbed.import revises the post with the feed content (topic_embed.rb#L147-L152), bypassing whatever the create modifier did. A blogger editing a post silently turns a plugin-shaped topic back into feed text. A modifier on the update changes, mirroring topic_embed_import_create_args, would close this.

The workaround for 2 and 3 is prepending TopicEmbed.import and the poll job. That’s brittle: main has since added a truncate: keyword to TopicEmbed.import, which breaks any wrapper that mirrors the 2026.7 signature - we had to ship a release just to pass it through. Documented hooks would avoid that class of breakage.