Désactiver le lien d'ancrage vers les en-têtes markdown

Soutien
1

Salut,

Y a-t-il un moyen de désactiver les liens d’ancrage vers les en-têtes Markdown ? (introduit dans la v2.7.0)

Nous utilisons un morceau de code qui interroge des sujets (en utilisant le plugin Data Explorer), mais ces liens d’ancrage interrompent le processus. Nous aimerions mettre à niveau notre Discourse mais nous sommes bloqués avec ce morceau de code.

Merci, Michel

2

Salut Michel. :wave:

Il n’y a pas de paramètre pour configurer les liens d’ancrage.

Peut-être pouvons-nous vous aider de ce côté : en quoi les liens d’ancrage cassent-ils votre requête ? :slight_smile:

3

Merci Maiki pour ton soutien :slight_smile:

Ok, nous utilisons ce logiciel : GitHub - canonical/canonicalwebteam.discourse
Il utilise une requête Data Explorer, mais n’arrive pas à gérer les liens d’ancrage.

À partir de là, je vois 2 pistes possibles :

  • soumettre une PR à Canonical
  • avoir notre serveur Discourse en 2.6.7

Notre serveur est actuellement en 2.9.0 beta10. Il n’y a pas beaucoup de contenu, donc ce serait très facile de transférer vers un autre, pas de problème.

J’ai essayé de démarrer un nouveau serveur (sous Docker) avec :
#version: tests-passed
remplacé par
version: f73cdbbd2f20460ea6330930f97cdce59fb984be (dernier commit de la 2.6.7)

Mais malheureusement, il refuse de démarrer :

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

Des suggestions ?

4

Vous ne pouvez pas revenir en arrière comme ça. Les migrations de données rendent l’état de la base de données incompatible, donc seul le passage à une version ultérieure est pris en charge.

5

Salut Falco,

Je pensais plutôt à démarrer un tout nouveau serveur, pas à faire une mise à niveau.
Les données actuelles n’ont pas une grande importance, seulement quelques éléments, faciles à remettre sur un nouveau serveur.

6

La branche Discourse 2.6 date d’il y a près de 2 ans, il est donc possible qu’elle ne fonctionne tout simplement pas avec la version actuelle de l’image de conteneur de base que nous expédions actuellement. Afin de diagnostiquer le problème, j’aurais besoin des ./launcher rebuild logs lors de la tentative de reconstruction en 2.6.7 dans une installation entièrement nouvelle.

Cependant, exécuter une version de Discourse qui ne reçoit plus de correctifs de sécurité est une très mauvaise idée, donc la bonne approche est de corriger le logiciel que vous utilisez pour gérer cette intégration.

Peut-être pouvez-vous partager la requête SQL qui doit être corrigée ?

2 « J'aime »