Привет,
Есть ли способ отключить якорные ссылки на заголовки в Markdown? (появились в версии 2.7.0)
Мы используем фрагмент кода для запроса тем (с помощью плагина Data Explorer), но эти якорные ссылки нарушают процесс. Мы хотели бы обновить наш Discourse, но застряли из-за этого фрагмента кода.
Спасибо, Мишель
Привет, Мишель. 
Настроек для конфигурации якорных ссылок нет.
Возможно, мы сможем помочь вам с нашей стороны: что именно в якорных ссылках ломает ваш запрос? 
Спасибо, Маики, за вашу поддержку
Хорошо, мы используем это программное обеспечение: GitHub - canonical/canonicalwebteam.discourse · GitHub
Оно использует запрос Data Explorer, но не может справиться с якорными ссылками.
Поэтому я вижу два возможных пути:
Наш сервер сейчас на версии 2.9.0 beta10. Контента там немного, поэтому перенос на другой сервер будет очень простым, это не проблема.
Я попытался запустить новый сервер (в Docker) с:
#version: tests-passed
заменённым на
version: f73cdbbd2f20460ea6330930f97cdce59fb984be (последний коммит 2.6.7)
Но, к сожалению, он отказывается запускаться:
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
...
Есть какие-нибудь предложения?
Нельзя возвращаться к предыдущим версиям таким образом. Миграции данных делают состояние базы данных несовместимым, поэтому поддерживается только переход вперёд.
Привет, Фалько,
Я подумал о запуске совершенно нового сервера, а не о понижении версии.
Для текущих данных это не проблема: всего несколько вещей, которые легко перенести на новый сервер.
Ветка Discourse 2.6 была выпущена почти 2 года назад, поэтому возможно, что она просто не работает с текущей версией базового образа контейнера, который мы используем. Для диагностики мне понадобятся логи ./launcher rebuild logs попытки пересборки версии 2.6.7 на чистой установке.
Однако запуск версии Discourse, для которой больше не выпускаются исправления безопасности, — очень плохая идея, поэтому правильный путь — исправить программное обеспечение, которое вы используете для этой интеграции.
Может быть, вы сможете поделиться SQL-запросом, который нужно исправить?