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!
Dit is geen misleidende lovende post, zoals mijn vorige🙈, want
Discourse ondersteunt een bypass_bump-vlag bij het reviseren van een post; het voorkomt dat de bumpdatum van het onderwerp verandert, zelfs als je de laatste (of de eerste en enige) post bewerkt. Dit staat expliciet vermeld in de PostRevisor-opties (“- bypass_bump: bump het onderwerp niet, zelfs niet als het de laatste post is”).
Dit lovende onderwerp bestaat en beschrijft precies dat gebruiksscenario.
Historisch gezien gebruikten mensen de workaround /t/{id}/reset-bump-date omdat deze optie niet algemeen bekend/gedocumenteerd was in de API-documentatie, maar deze is nog steeds beschikbaar indien nodig.
Praktische opmerking: wanneer je /posts/{post_id}.json PUT met de nieuwe ruwe tekst en bypass_bump=true toevoegt, zal de bewerking het onderwerp niet in /latest laten zien. (Officiële documentatie specificeert deze parameter niet, maar deze is server-side via PostRevisor ingesteld.)
Ik ben nog steeds niet 100% zeker van de officiële status van bypass_bump in de API-documentatie — het verschijnt nergens duidelijk.\n\nMaar als ik naar de logs van Ethsim12’s Python sync-script kijk, zijn die leerzaam. Het script probeert de API aan te roepen met bypass_bump=true. Als die parameter genegeerd of ongeldig zou zijn, is het enige dat onnodige bumps voorkomt de fallback die ze hebben toegevoegd: een handmatige aanroep naar\n\n\n/t/{topic_id}/reset-bump-date\n\n\nDus de loguitvoer zelf wordt sterk bewijs. Als de log laat zien dat topics worden bijgewerkt zonder in /latest te verschijnen (en zonder de reset fallback nodig te hebben), is dat een goed bewijs dat bypass_bump actief en werkend is. Als de log altijd terugvalt op reset-bump-date, dan is het dat misschien niet.\n\nMet andere woorden: de logs van dit script dragen er in grote mate aan bij om te bevestigen of bypass_bump bestaat en daadwerkelijk wordt gerespecteerd door de server.
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.
