Ankerlink zu Markdown-Headern deaktivieren

Unterstützung
1

Hallo,

Gibt es eine Möglichkeit, die Ankerlinks zu Markdown-Headern zu deaktivieren (eingeführt in v2.7.0)?

Wir verwenden ein Codefragment, das Themen abfragt (mithilfe des Data Explorer-Plugins), aber diese Ankerlinks unterbrechen den Prozess. Wir möchten unser Discourse aktualisieren, aber wir stecken mit diesem Codefragment fest.

Danke, Michel

2

Hallo Michel. :wave:

Es gibt keine Einstellung, um die Ankerlinks zu konfigurieren.

Vielleicht können wir Ihnen von dieser Seite aus helfen: Was genau brechen die Ankerlinks an Ihrer Abfrage? :slight_smile:

3

Vielen Dank, Maiki, für deine Unterstützung :slight_smile:

Ok, wir verwenden diese Software: GitHub - canonical/canonicalwebteam.discourse
Sie verwendet eine Data Explorer-Abfrage, kann aber dann mit den Ankerlinks nicht umgehen.

Von dort sehe ich 2 mögliche Wege:

  • Ein PR an Canonical übermitteln
  • Unseren Discourse-Server auf 2.6.7 haben

Unser Server ist derzeit auf 2.9.0 beta10. Nicht viele Inhalte dort, daher wäre es super einfach, sie auf eine andere zu übertragen, kein großes Problem.

Ich habe versucht, einen neuen Server (unter Docker) mit Folgendem zu starten:
#version: tests-passed
ersetzt durch
version: f73cdbbd2f20460ea6330930f97cdce59fb984be (letzter Commit von 2.6.7)

Aber leider weigert er sich zu starten:

run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
Started runsvdir, PID is 47
ok: run: redis: (pid 62) 0s
ok: run: postgres: (pid 59) 0s
supervisor pid: 57 unicorn pid: 90
config/unicorn_launcher: line 71: kill: (90) - No such process
config/unicorn_launcher: line 15: kill: (90) - No such process
(57) exiting
timeout: down: redis: 0s, normally up, want up
timeout: down: redis: 1s, normally up, want up
timeout: down: redis: 1s, normally up, want up
timeout: down: redis: 1s, normally up, want up
timeout: down: redis: 0s, normally up, want up
timeout: down: redis: 0s, normally up, want up
timeout: down: redis: 0s, normally up, want up
timeout: down: redis: 0s, normally up, want up
timeout: down: redis: 0s, normally up, want up
timeout: down: redis: 1s, normally up, want up
timeout: down: redis: 0s, normally up, want up
timeout: down: redis: 1s, normally up, want up
timeout: down: redis: 0s, normally up, want up
timeout: down: redis: 1s, normally up, want up
ok: run: redis: (pid 358) 0s
timeout: down: postgres: 0s, normally up, want up
timeout: down: redis: 1s, normally up, want up
...

Irgendwelche Vorschläge?

4

Sie können nicht auf diese Weise zu früheren Versionen zurückkehren. Die Datenmigrationen machen den Datenbankzustand inkompatibel, daher wird nur das Vorwärtsgehen unterstützt.

5

Hallo Falco,

Ich dachte daran, einen brandneuen Server zu starten, nicht zu downgraden.
Kein großes Problem für aktuelle Daten, nur ein paar Dinge, die leicht auf einem neuen Server wiederhergestellt werden können.

6

Der Discourse 2.6-Branch ist fast 2 Jahre alt, daher besteht die Möglichkeit, dass er einfach nicht mit der aktuellen Version des Basiscontainer-Images funktioniert, das wir derzeit ausliefern. Um das Problem zu beheben, benötige ich die ./launcher rebuild logs beim Versuch, ihn als 2.6.7 in einer brandneuen Installation neu zu erstellen.

Es ist jedoch eine sehr schlechte Idee, eine Discourse-Version auszuführen, die keine Sicherheitspatches mehr erhält. Der richtige Weg ist daher, die Software zu reparieren, die Sie für diese Integration verwenden.

Vielleicht können Sie die SQL-Abfrage teilen, die repariert werden muss?

2 „Gefällt mir“