Disable anchor link to markdown headers

support
1

Hi there,

Is there a way to disable the anchor links to markdown headers ? (introduced in v2.7.0)

We use a piece of code that queries topics (using the Data Explorer plugin), but these anchor links break the process. We would like to upgrade our Discourse but we’re stuck with this piece of code.

Thanks, Michel

2

Hi Michel. :wave:

There is no setting to configure the anchor links.

Maybe we can assist you from this end: what about the anchor links breaks your query? :slight_smile:

3

Thanks Maiki for your support :slight_smile:

Ok, so we’re using this software : GitHub - canonical/canonicalwebteam.discourse
It uses a Data Explorer query, but then is not able to cope with the anchor links.

So from there I see 2 possible tracks :

  • submit a PR to Canonical
  • have our Discourse server in 2.6.7

Our server is currently in 2.9.0 beta10. Not a lot of content there, so it would be super easy to transfert to another, no big deal.

I’ve tried to start a new server (under Docker) with :
#version: tests-passed
replaced by
version: f73cdbbd2f20460ea6330930f97cdce59fb984be (last commit of the 2.6.7)

But unfortunately, it refuses to start :

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

Any suggestions ?

4

You can’t go back versions like that. The data migrations make the database state incompatible, so only going forward is supported.

5

Hi Falco,

I was thinking starting a brand new server, not downgrading.
No big deal for current data, only a few things, easy to put them back in a new server.

6

Discourse 2.6 branch was almost 2 years ago, so there is a possibility that it just doesn’t work with the current version of the base container image we ship currently. In order to troubleshoot, I would need the ./launcher rebuild logs of trying to rebuild it as 2.6.7 in a brand new install.

However, running a Discourse version that doesn’t receive security fixes anymore is a really bad idea, so the correct way forward is fixing the software you use to handle this integration.

Maybe you can share the SQL query that needs fixing?

2 Likes