satonotdead introduced the Wiki Coeditors theme component, which credits everyone who edited a wiki post by listing their avatars under the first post. While Discourse retains full edit history, it does not display contributors by default. This component fills that gap by ranking editors based on recent revisions, excluding the post author, system, and discobot. It supports localization (English/Spanish), works for signed-out users, and offers extensive configuration via settings like target_categories, target_tags, label, and excluded_users. The number of displayed avatars and revisions checked are configurable, with defaults of 5 avatars and 20 revisions.
The component has notable limitations due to its architecture. It fetches one request per revision on every page view to compute diffs, which impacts performance on heavily edited wikis. To stay within Discourse’s default rate limit of 50 requests per 10 seconds, the component caps revision checks at 40 (default 20), meaning older contributors on long-edit-history posts are not credited. Additionally, non-standard bots must be manually excluded, and only the first post in a topic is processed.
In response to NateDhaliwal’s inquiry about whether the high number of requests could be optimized via a plugin or caching, satonotdead confirmed the issue. The current method computes server-side diffs that are discarded, necessitating the request cap. They proposed that a plugin could solve this by executing a single indexed SQL GROUP BY user_id query on post_revisions, adding the results directly to the post serializer for zero extra requests and full history coverage. However, they noted the trade-off: plugins require a site rebuild and are incompatible with some hosted Discourse plans, whereas theme components can be installed instantly from the admin panel. The developer plans to monitor live traffic before deciding whether to migrate the functionality to a plugin, viewing the current component as an exploratory starting point.
Discourse keeps every wiki edit, but never shows who contributed. This component lists them under the post, so the people who keep a wiki up to date get credit for it.
Shows “Co-edited by” and the editors’ avatars under the first post of a wiki topic.
Ranks editors by how many edits they made in recent revisions. The post’s author, system and discobot aren’t listed.
Opens each person’s profile card on click.
Past a set number of avatars, the rest go behind “+N more”.
Works for signed-out visitors: a wiki’s edit history is public even with edit_history_visible_to_public off.
English and Spanish localizations are included.
Settings
Setting
Default
target_categories
empty
Categories whose wikis show the list
target_tags
empty
Tags whose wikis show the list, in any category. With no categories or tags set, every wiki shows it.
label
empty
Text before the avatars. Empty uses the viewer’s language.
label_overrides
none
Different wording per category
excluded_users
empty
Usernames never listed
max_avatars
5
Avatars shown before “+N more”
max_revisions
20
Recent revisions read, up to 40
Known limits
One request per revision on each view, so only recent revisions are read: earlier editors of a heavily edited wiki drop off. The cap is 40 because Discourse blocks a visitor past 50 requests in 10 seconds by default.
Other bots, such as AI ones, can’t be detected automatically: they needs to be added to excluded_users.
Any revision counts, including one that only changed the title, tags or category.
Only the first post is credited.
excluded_users only hides names. Their edits stay in the post’s history.
For a leaderboard instead of per-post credit, the README includes a Data Explorer query. Bug reports and PRs are welcome.
If the edit history is long, wouldn’t the number of requests be problematic? Is there a chance of this being converted to a plugin, say, using an SQL query or some caching?
Yes, it is one request per revision (plus one), on every page view, each computing a server-side diff that gets discarded. That’s why it reads only the most recent 20 revisions by default, capped at 40 to stay under core’s 50 requests core IP limit, so on long histories older contributors drop off.
A plugin removes all of that: one indexed GROUP BY user_id on post_revisions, added to the post serializer for the first post of wiki topics. Zero extra requests, full history, no diffs. Caching likely isn’t needed at that cost; if it were, contributor ids could live in a post custom field updated on revision.
The trade-off is that a plugin needs a rebuild to install and can’t run on some Discourse’s hosted plans, while the component installs from the admin panel anywhere.
I’ll think about it once I’ve tested it with more live traffic and I might decide to turn it into a plugin. In the meantime, the component is our starting point for exploration.
