Disabilita il collegamento dell'ancora alle intestazioni markdown

Supporto
1

Ciao,

C’è un modo per disabilitare i link di ancoraggio alle intestazioni markdown? (introdotti in v2.7.0)

Utilizziamo un pezzo di codice che interroga gli argomenti (utilizzando il plugin Data Explorer), ma questi link di ancoraggio interrompono il processo. Vorremmo aggiornare il nostro Discourse ma siamo bloccati con questo pezzo di codice.

Grazie, Michel

2

Ciao Michel. :wave:

Non esiste un’impostazione per configurare i link di ancoraggio.

Forse possiamo assisterti da questo lato: cosa c’è nei link di ancoraggio che interrompe la tua query? :slight_smile:

3

Grazie Maiki per il tuo supporto :slight_smile:

Ok, stiamo usando questo software: GitHub - canonical/canonicalwebteam.discourse
Utilizza una query di Data Explorer, ma poi non è in grado di gestire i collegamenti di ancoraggio.

Da lì vedo 2 possibili percorsi:

  • inviare una PR a Canonical
  • avere il nostro server Discourse in 2.6.7

Il nostro server è attualmente in 2.9.0 beta10. Non c’è molto contenuto lì, quindi sarebbe super facile trasferirlo su un altro, nessun problema.

Ho provato ad avviare un nuovo server (sotto Docker) con:
#version: tests-passed
sostituito da
version: f73cdbbd2f20460ea6330930f97cdce59fb984be (ultimo commit di 2.6.7)

Ma sfortunatamente, si rifiuta di avviarsi:

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
...

Suggerimenti?

4

Non puoi tornare indietro alle versioni in quel modo. Le migrazioni dei dati rendono lo stato del database incompatibile, quindi è supportato solo andare avanti.

5

Ciao Falco,

Stavo pensando di avviare un server nuovo di zecca, non di eseguire un downgrade.
Nessun problema per i dati attuali, solo poche cose, facili da rimettere in un nuovo server.

6

Il branch Discourse 2.6 è di quasi 2 anni fa, quindi c’è la possibilità che semplicemente non funzioni con la versione corrente dell’immagine container di base che spediamo attualmente. Per risolvere il problema, avrei bisogno dei log di ./launcher rebuild tentando di ricompilarlo come 2.6.7 in un’installazione completamente nuova.

Tuttavia, eseguire una versione di Discourse che non riceve più correzioni di sicurezza è una pessima idea, quindi la strada corretta da seguire è correggere il software che si utilizza per gestire questa integrazione.

Forse puoi condividere la query SQL che necessita di correzione?

2 Mi Piace