تعطيل رابط الارتساء لعناوين markdown

مرحباً،

هل هناك طريقة لتعطيل روابط التثبيت لعناوين markdown؟ (تم تقديمها في الإصدار 2.7.0)

نحن نستخدم جزءًا من التعليمات البرمجية يستعلم عن المواضيع (باستخدام إضافة Data Explorer)، ولكن روابط التثبيت هذه تعطل العملية. نود ترقية Discourse الخاص بنا ولكننا عالقون بهذا الجزء من التعليمات البرمجية.

شكراً، ميشيل

مرحباً ميشيل. :wave:

لا يوجد إعداد لتهيئة روابط الارتكاز.

ربما يمكننا مساعدتك من هذا الجانب: كيف تعطل روابط الارتكاز استعلامك؟ :slight_smile:

شكراً مايكي على دعمك :slight_smile:

حسنًا، نحن نستخدم هذا البرنامج: GitHub - canonical/canonicalwebteam.discourse
إنه يستخدم استعلام مستكشف البيانات، ولكنه بعد ذلك لا يتمكن من التعامل مع روابط الإشارة.

لذلك من هناك أرى مسارين محتملين:

  • إرسال طلب سحب إلى Canonical
  • جعل خادم Discourse الخاص بنا في 2.6.7

خادمنا حاليًا في 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 كان قبل عامين تقريبًا، لذلك هناك احتمال أنه لا يعمل مع الإصدار الحالي لصورة الحاوية الأساسية التي نشحنها حاليًا. لتصحيح الأخطاء، سأحتاج إلى سجلات ./launcher rebuild عند محاولة إعادة بنائه كـ 2.6.7 في تثبيت جديد تمامًا.

ومع ذلك، فإن تشغيل إصدار Discourse لا يتلقى إصلاحات أمنية لم يعد فكرة سيئة حقًا، لذا فإن الطريقة الصحيحة للمضي قدمًا هي إصلاح البرنامج الذي تستخدمه للتعامل مع هذا التكامل.

ربما يمكنك مشاركة استعلام SQL الذي يحتاج إلى إصلاح؟

إعجابَين (2)