Ich wollte dem Discourse-Team nur ein großes Dankeschön aussprechen, dass es den bypass_bump-Parameter aufgenommen hat! Es ist ein kleines, aber mächtiges Werkzeug – es ermöglicht Skripten und Plugins, Inhalte im Hintergrund zu aktualisieren, ohne versehentlich alte Themen in der neuesten Ansicht anzuzeigen.
In unserem Fall verwenden wir ihn für ICS-Synchronisationsskripte, und er stellt sicher, dass nur sinnvolle Änderungen Themen tatsächlich nach oben verschieben. Eine durchdachte Ergänzung, die Community-Foren sauber hält und das Leseerlebnis ungestört lässt – nochmals vielen Dank!
Dies ist kein irreführender Lob-Post, wie mein letzter🙈, denn
Discourse unterstützt ein bypass_bump-Flag beim Überarbeiten eines Posts; es verhindert, dass sich das Bump-Datum des Themas ändert, selbst wenn Sie den letzten (oder den ersten und einzigen) Post bearbeiten. Dies ist explizit in den PostRevisor-Optionen aufgeführt (“- bypass_bump: das Thema nicht bumpen, auch wenn es der letzte Post ist”).
Dieser Lob-Thread existiert und beschreibt genau diesen Anwendungsfall.
Früher nutzten die Leute den Workaround /t/{id}/reset-bump-date, weil diese Option nicht allgemein bekannt/in der API-Dokumentation dokumentiert war, aber sie ist bei Bedarf immer noch verfügbar.
Praktischer Hinweis: Wenn Sie /posts/{post_id}.json mit dem neuen Raw-Text per PUT anfordern und bypass_bump=true einschließen, wird die Bearbeitung das Thema nicht in /latest anzeigen. (Die offiziellen Dokumente erläutern diesen Parameter nicht, aber er ist serverseitig über PostRevisor verdrahtet.)
Ich bin mir beim offiziellen Status von bypass_bump in der API-Dokumentation noch nicht zu 100 % sicher – es scheint nirgends offensichtlich auf.
Aber wenn ich mir die Protokolle von Ethsim12s Python-Sync-Skript ansehe, sind diese aufschlussreich. Das Skript versucht, die API mit bypass_bump=true aufzurufen. Wenn dieser Parameter ignoriert oder ungültig wäre, wäre das Einzige, was unnötige Bumps verhindert, der Fallback, den sie hinzugefügt haben: ein manueller Aufruf von
/t/{topic_id}/reset-bump-date
Daher wird die Protokollausgabe selbst zu einem starken Beweis. Wenn das Protokoll zeigt, dass Themen aktualisiert werden, ohne in /latest zu erscheinen (und ohne den reset-fallback zu benötigen), ist das ein ziemlich guter Beweis dafür, dass bypass_bump aktiv und funktionsfähig ist. Wenn das Protokoll immer auf reset-bump-date zurückfällt, dann vielleicht nicht.
Mit anderen Worten: Die Protokolle dieses Skripts tragen wesentlich dazu bei, zu bestätigen, ob bypass_bump existiert und vom Server tatsächlich beachtet wird.
Danke für das Teilen dieses PR, Moin – wirklich hilfreicher Kontext.
Für mein Nebenprojekt (den ics_to_discourse.py-Importer) habe ich gerade eine Änderung vorgenommen, um kalendergesteuerte Updates daran zu hindern, Themen „lärmend“ zu pushen:
Dieser Commit fügt eine Logik hinzu, um zu entscheiden, ob eine Bearbeitung „sinnvoll“ ist (Änderung von Zeit/Ort usw.) und verwendet bypass_bump plus einen Fallback zum Zurücksetzen des Bump-Datums, damit routinemäßige ICS-Synchronisierungen Themen nicht unnötig an die Oberfläche bringen.
Dieser PR passt also perfekt zu dem, was ich angestrebt habe – schön zu sehen, dass der Kern in die gleiche Richtung geht. Sobald das Verhalten „nicht pushen bei Bearbeitung“ zusammengeführt ist, werde ich vereinfachen und den zusätzlichen Fallback fallen lassen, aber vorerst hält der Commit die Dinge auf aktuellen Discourse-Installationen ruhig.
Hmm, ich habe dieses Thema noch einmal gelesen und festgestellt, dass ich eine weitere relevante PR nicht erwähnt habe, als ich an der Universität nicht aktiv war und Zeit zum Programmieren hatte
