مرحباً، أي شخص ينقر على صفحات شروط الخدمة أو الأسئلة الشائعة أو الخصوصية الخاص بي ينتقل إلى صفحة فارغة مع مؤشر “مشغول” يدور بشكل دائم.
كيف يمكنني تصحيح هذا؟
كيف يمكنني جعل هذه المعلومات متاحة وجذب انتباه أي مستخدم محتمل يزور عنوان موقع الويب ولكن لم يسجل بعد للحصول على وصول محمي بكلمة مرور؟
حاليًا، لا يرى الزائر سوى مربع حوار تسجيل الدخول الأساسي كصفحة هبوط، دون أي تلميح قبل التسجيل عما إذا كان المنتدى ذا صلة بهم أو ما هي الشروط المطبقة.
الآن بعد أن تم إعداد الموقع والبريد الإلكتروني بالكامل وعملهما على نطاق المنتدى، فإنني متردد في المخاطرة بإفساد كل شيء عن طريق إعادة توجيه النطاق إلى صفحة ويب أخرى مستضافة بشكل منفصل كصفحة رئيسية، ونقل المنتدى إلى نطاق فرعي أو ما شابه - كما تم اقتراح ذلك. كما أنني متردد في إنفاق 47 دولارًا سنويًا على إضافة مدفوعة لإضافة معلومات إضافية قليلاً إلى صفحة هبوط النطاق.
كحل بديل غير أنيق ومزعج، أضفت دليلًا مخصصًا للأشخاص الذين يفكرون في التسجيل، من خلال تخصيص نص نافذة تسجيل الدخول نفسها.
إذا قررت المضي قدمًا ونقل المنتدى إلى نطاق فرعي، فكم من المتاعب يمكنني توقعها بصفتي مبتدئًا في:
إعداد صفحة هبوط على النطاق الرئيسي واستضافتها أيضًا داخل قطرة Digital Ocean الخاصة بي؟ (حتى لا أضطر لدفع ثمن خدمة أخرى)
ضمان عمل البريد الوارد والصادر عبر Mailgun واستمرار جميع الوظائف دون انقطاع؟
المشكلة الخلفية هي أنني أفضل بكثير إدارة محتوى صفحة الهبوط وتحديثه من داخل لوحة تحكم المسؤول، بالإضافة إلى تضمينها في النسخ الاحتياطية التلقائية، وهو ما يبدو صعبًا للغاية إذا لم نستخدم نفس النطاق، ناهيك عن نفس البرنامج.
أود حقًا رؤية توفر بعض وظائف صفحة الهبوط البسيطة على الأقل في نواة Discourse، لأولئك الذين لا يرغبون أو لا يحتاجون إلى موقع آخر لإدارته.
هل هذه الحالة تنطبق على المستخدمين المسجلين كما تنطبق على المجهولين (غير المسجلين)؟ إذا كان الأمر كذلك، فهذا يشير إلى مشكلة جوهرية لا ينبغي أن تتأثر بالتلاعب بالنطاق أو النطاقات الفرعية.
في حالتنا، نرغب بالتأكيد في وجود Discourse في النطاق الجذر لأنه المركز المطلق لما نقوم به. لذا، كنت أنا أيضًا أبحث عن أفضل طريقة لتحسين /admin/customize/site_texts/login_required.welcome_message والعناصر الأخرى في تلك الصفحة.
الخبر السار هو أنه يمكنك استخدام جميع عناصر Markdown وغيرها في هذا النص؛ مما يتيح مرونة أكبر بكثير. أقوم بذلك عن طريق كتابته في موضوع في قناة Staff ثم نسخه إلى قسم التخصيص. @codinghorror - سيكون من المفيد للغاية للأشخاص في وضعنا أن يتصرف النظام بنفس طريقة صفحات الأسئلة الشائعة وما شابه.
أيضًا، يمكنك توفير روابط لصفحات الخصوصية وشروط الخدمة (التي يجب أن تكون مرئية للمستخدمين المجهولين) باستخدام مكون السمة Custom Header Links (مع بعض CSS إضافي). بالطبع، لست راضيًا عن ذلك وأرغب في أن يرى المجهولون أيضًا صفحات الأسئلة الشائعة ومن نحن (مع الحفاظ على خصوصية المنتدى)، لذا طلبت بعض المساعدة:
هذا صحيح بالنسبة للمستخدمين المسجلين دخولهم. أما المستخدمون الذين لم يسجلوا دخولهم، فلا توجد لديهم أي طريقة لرؤية أي شيء غير نافذة تسجيل الدخول (إلا إذا كنت أغفلت شيئًا ما؟)
قمت بتنظيف الفئات التي بدت فارغة أو غير مختلفة بما يكفي عن الفئات الأخرى. من الواضح أنها ليست فارغة في الواقع.
بافتراض أنه يمكنني نسخ محتوى هذه المواضيع من هذا الموقع وإعادة إنشائها تحت إحدى الفئات المتبقية في موقعي، كيف يمكنني إعادة ربطها بعناصر القائمة الخاصة بها؟ أم أنني سأقوم ببساطة بإعادة إنشاء فئة ‘إدارة’؟
آسف، أقصد على الأرجح Staff. لقد قمت بالتلاعب بها في نسختنا أيضًا، لكنني حفظت المواضيع. تُسمى هذه المواضيع “الأسئلة الشائعة/الإرشادات” (معرف الموضوع 5)، “شروط الخدمة” (معرف الموضوع 4)، و"سياسة الخصوصية الخاصة بـ اسم منتداك" (معرف الموضوع 6).
أظن أن هناك شيئًا خاصًا بها - فقط المسؤولون يمكنهم تعديل المنشور الأول في كل منها، بغض النظر عن إعدادات الفئة. قد يكون إعادة إنشائها أمرًا معقدًا بعض الشيء. بالتوفيق!
لم يتم حذف فئة #Staff أبدًا، لكن يبدو أن المواضيع قد اختفت بطريقة ما.
أما بالنسبة لمحتوى تلك المواضيع، ولا سيما مواضيع شروط الخدمة وسياسة الخصوصية، فإن مجرد نسخ ما وجدته في موقع Discourse Meta لا يبدو فعالًا، حيث أن كلاهما منحرفان/مخصصان بشكل كبير للولاية القضائية والسياق غير المنطبق على منتداي. هل توجد مصادر أكثر عمومية (حتى تلك ذات الصلة بنيوزيلندا؟) يمكن الاعتماد عليها؟
كما أؤكد أن مجرد إضافة فئة ‘المشرفين’ ثم إنشاء موضوع ‘الأسئلة الشائعة’ فيها لم ينجح - فرابط الأسئلة الشائعة لا يزال يُنتج شاشة فارغة ومؤشر ماوس يدور.
حسناً، بناءً على ذلك، عند النظر إلى عناوين URL المستخدمة في الأسئلة الشائعة الأصلية، يبدو أن موضوع الأسئلة الشائعة يقع مباشرة في مجلد فرعي يحمل اسم ‘faq’ — على سبيل المثال:
https://meta.discourse.org/faq#civilized
بينما إذا قمت بإنشاء موضوع أسئلة شائعة جديد ولصق المحتوى فيه، فإنه ينتقل إلى شيء مثل:
https://nzarchitecture.net.nz/t/faq/15074
كيف يمكنني إنشاء المجلد الفرعي الصحيح أو وضع المواضيع بداخله؟ لا أرى أي شيء أعرفه كبنية مجلد تقليدية مباشرة لمحتوى موقع Discourse عندما أتصل بـ Digital Ocean Droplet الخاص بي عبر FileZilla، لذا أفترض أن هناك بعض الحيل الغامضة في Ruby on Rails تعمل على توليد هذه عناوين URL/المسارات.
وجدت حلاً مؤقتاً في هذه الأثناء، وهو استخدام أي عنوان URL يتم توليده عند إعادة إنشاء هذه المواضيع المفقودة، ولصقها في حقول ‘مصدر خارجي بديل’ ذات الصلة في إعدادات لوحة التحكم/القانونية.
سيظل من الجيد ترتيب الأمور بشكل صحيح إذا كانت هناك طريقة — لا أعرف ما هي التداعيات الأخرى التي قد تنتج عن الإعداد الأصلي التالف أو المفقود.
شكرًا لك يا ستيفن. للأسف، لا أعرف من أين أبدأ في التلاعب بقاعدة بيانات PostgreSQL.
هل كان من الممكن حتى أن أتمكن من حذفها إذا كانت مدمجة في النظام وليست ضمن أي فئة قابلة للتعديل أو الوصول مباشرة من قبل المستخدم؟
ألاحظ أيضًا أنه حتى عندما كانت هذه المواضيع موجودة لدي، بدا أنها تتجاهل معلومات “الحقول المطلوبة” المقدمة أثناء الإعداد لاسم الشركة، والقانون الحاكم، ومدينة النزاعات، مما يشير إلى أن هناك مشكلة قائمة بالفعل.
وجميع هذا قد يكون قانونيًا بلا جدوى، إذا لم يكن لدى المستخدم أي طريقة لعرض شروط الخدمة قبل التسجيل، وهو ما قد يمثل مشكلة جوهرية محتملة لجميع منتديات Discourse المحمية بكلمة مرور.
أهلاً بك يا ناثان.
من المثير للاهتمام/المشجع أنني أستطيع ربطه دون الحاجة لتسجيل الدخول.
أرغب بشدة في وجود روابط فعالة للأسئلة الشائعة وشروط الخدمة وما شابهها في نافذة التسجيل/تسجيل الدخول، لكن حتى الآن، جميع الروابط تُظهر للمستخدمين غير المسجلين رسالة “ليس لديك إذن”.
يمكنك تحقيق ذلك باستخدام حل بديل آخر:
اجعل جميع فئاتك مرئية فقط لمستوى الثقة 0 (أو أكثر تقييدًا) باستثناء الفئة التي تحتوي على منشورات المعلومات الخاصة بك (اجعلها مرئية للجميع). ثم اجعل المنتدى عامًا. بالطبع، لن ينتقل المستخدمون بعد الآن إلى صفحة تسجيل الدخول، وهذه طريقة جذرية إلى حد ما لتحقيق هذا الهدف.
هل يمكن لأي شخص تقديم نصيحة حول كيفية إعادة المواضيع القانونية المدمجة والمعرفات الخاصة بها (أو حتى مجرد وضع منشورات فارغة قابلة للتحرير في عناوين URL الصحيحة/الأصلية لكل موضوع قانوني مدمج)، عبر postgres أو بأي طريقة أخرى؟
إن إنشاء نسخ جديدة بنفس الاسم في فئة الموظفين لا يعمل - حيث تكون عناوين URL الناتجة مختلفة ولا يمكن للمستخدم الجديد الوصول إليها أثناء التسجيل (فإن النقر على الرابط في مربع حوار التسجيل يعيدهم فقط إلى مربع حوار تسجيل الدخول).
حسناً، يبدو أن لا أحد يستطيع المساعدة في هذا الأمر. هل سيساعد إعادة إنشاء المنتدى من الصفر ثم استعادة نسخة احتياطية محفوظة من قاعدة البيانات؟ أم أن استعادة النسخة الاحتياطية ستنشر عمليات الحذف مرة أخرى؟
في مكان ما داخل قاعدة البيانات توجد قطعة صغيرة من البيانات يجب عليك تغييرها لجعل تلك المنشورات تظهر مرة أخرى. وفي الواقع هنا:
في جدول ‘topics’، ستحتوي حقل deleted_at على طابع زمني للمعرفات 4 و5 و6. إذا تمكّنت من حذف هذه القيم (استبدالها بـ لا شيء/فارغ) فستعود الأمور إلى نصابها.
أعلم أنه يمكن القيام بذلك عبر Ruby/Rails، لكن هذا خارج نطاق مهاراتي حتى الآن — لكن بالنسبة لشخص يمتلك المهارات المناسبة، ستكون هذه المهمة من مهام خمس دقائق. ربما يتمكن الشخص الذي قام بإعداد النسخة لديك من المساعدة.
شكرًا لك يا ناثان.
للأسف، قمت بإعداد نفسي بناءً على الدليل الرسمي، مع فهم ضئيل للموضوع.
كان لدي مطوّر نقل بعض المواد لي في وقت مبكر، وقد تواصلت معه بخصوص هذا الأمر قبل أسبوع، لكن لم أتحصل على أي رد حتى الآن.
ما أود معرفته هو هل توجد تطبيق سطح مكتب مفتوح المصدر يتصل بقواعد البيانات في Digital Ocean ويسمح بعرض وتعديل جداول PostgreSQL؟ أم حتى تطبيق يمكنه قراءة وتعديل نسخة احتياطية تم تحميلها، ثم استعادتها؟
** تعديل - بعد إعادة قراءة الردود على استفسار مشابه، يبدو أن الإجماع هو استخدام لغة Ruby عند القيام بأي شيء، بدلاً من استخدام واجهة رسومية (GUI) سهلة الاستخدام لتطبيقات قواعد البيانات.
مع ذلك، ما هي الأوامر التي يجب إصدارها في PuTTY للوصول إلى قاعدة البيانات وحذف الطوابع الزمنية للمواضيع ذات المعرفات 4 و5 و6 في عمود ‘deleted_at’ من جدول ‘topics’؟ (بعد أخذ نسخة احتياطية)؟