Desactivar enlace de anclaje a encabezados de markdown

Soporte
1

Hola,

¿Hay alguna forma de deshabilitar los enlaces de anclaje a los encabezados de markdown (introducidos en la v2.7.0)?

Usamos un fragmento de código que consulta temas (usando el plugin Data Explorer), pero estos enlaces de anclaje rompen el proceso. Nos gustaría actualizar nuestro Discourse pero estamos atascados con este fragmento de código.

Gracias, Michel

2

Hola Michel. :wave:

No hay ninguna configuración para configurar los enlaces de anclaje.

Quizás podamos ayudarte desde este lado: ¿qué es lo que rompe tu consulta con los enlaces de anclaje? :slight_smile:

3

Gracias Maiki por tu apoyo :slight_smile:

Ok, estamos usando este software: GitHub - canonical/canonicalwebteam.discourse
Utiliza una consulta de Explorador de Datos, pero luego no puede manejar los enlaces de anclaje.

Desde ahí veo 2 posibles caminos:

  • Enviar un PR a Canonical
  • Tener nuestro servidor Discourse en 2.6.7

Nuestro servidor está actualmente en 2.9.0 beta10. No hay mucho contenido allí, por lo que sería súper fácil transferirlo a otro, sin grandes problemas.

He intentado iniciar un nuevo servidor (en Docker) con:
#version: tests-passed
reemplazado por
version: f73cdbbd2f20460ea6330930f97cdce59fb984be (último commit de la 2.6.7)

Pero desafortunadamente, se niega a iniciarse:

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

¿Alguna sugerencia?

4

No puedes retroceder versiones de esa manera. Las migraciones de datos hacen que el estado de la base de datos sea incompatible, por lo que solo se admite avanzar.

5

Hola Falco:

Estaba pensando en empezar un servidor completamente nuevo, no en degradar uno existente.
No es un gran problema para los datos actuales, solo algunas cosas, fáciles de volver a poner en un servidor nuevo.

6

La rama Discourse 2.6 fue hace casi 2 años, por lo que existe la posibilidad de que simplemente no funcione con la versión actual de la imagen base del contenedor que enviamos actualmente. Para solucionar problemas, necesitaría los ./launcher rebuild logs de intentar reconstruirla como 2.6.7 en una instalación completamente nueva.

Sin embargo, ejecutar una versión de Discourse que ya no recibe correcciones de seguridad es una muy mala idea, por lo que la forma correcta de avanzar es solucionar el software que utiliza para manejar esta integración.

¿Quizás puedas compartir la consulta SQL que necesita ser corregida?

2 Me gusta