I just wanted to add a big thank you to the Discourse team for including the bypass_bump parameter! It’s a small but powerful tool — it allows scripts and plugins to update content behind the scenes without unintentionally surfacing old topics in the latest view.
In our case, we use it for ICS sync scripts, and it ensures only meaningful changes actually bump topics. A thoughtful addition that keeps community forums clean and reader experience undisturbed — thanks again!
this isn’t a misleading praise post, like my last one🙈, because
Discourse supports a bypass_bump flag when revising a post; it prevents the topic’s bump date from changing even if you edit the last (or first-and-only) post. This is explicitly listed in the PostRevisor options (“- bypass_bump: do not bump the topic, even if last post”).
This praise topic exists and states exactly that use case.
Historically people used the /t/{id}/reset-bump-date workaround because this option wasn’t widely known/documented in API docs, but it’s still available if needed.
Practical note: when you PUT /posts/{post_id}.json with the new raw and include bypass_bump=true, the edit won’t surface the topic in /latest. (Official docs don’t spell out this param, but it’s wired up server-side via PostRevisor.)
I’m still not 100% sure about the official status of bypass_bump in the API docs — it doesn’t appear anywhere obvious.
But when I look at the logs from Ethsim12’s Python sync script, they’re instructive. The script tries to call the API with bypass_bump=true. If that parameter were ignored or invalid, the only thing that would prevent unnecessary bumps is the fallback they added: a manual call to
/t/{topic_id}/reset-bump-date
So the log output itself becomes strong evidence. If the log shows topics being updated without appearing in /latest (and without needing the reset fallback), that’s pretty good proof bypass_bump is alive and working. If the log always falls back to reset-bump-date, then maybe it isn’t.
In other words: the logs from this script go a long way toward confirming whether bypass_bump exists and is actually respected by Discourse.
Thanks for sharing this PR, moin — really helpful context.
For my side project (ics_to_discourse.py importer), I actually just committed a change to stop calendar-driven updates from “noisily” bumping topics:
That commit adds some logic to decide whether an edit is “meaningful” (time/location change etc.), and uses bypass_bump plus a reset-bump-date fallback so that routine ICS syncs don’t surface topics unnecessarily.
So this PR lines up perfectly with what I was aiming for — nice to see core moving in the same direction. Once the “do not bump on edit” behaviour is merged, I’ll simplify and drop the extra fallback, but for now the commit keeps things quiet on current Discourse installs.