هل قمت بالاستعادة وجميع الروابط الداخلية تحتوي على نطاق عنوان URL للاختبار، مما أدى إلى كسر جميع الروابط، ولست متأكدًا من سبب عدم استخدام عنوان URL الصحيح للموقع، دون الدخول في الكود/قاعدة البيانات لإجراء استبدال شامل، هل هناك أي حلول للقيام بذلك بطريقة أخرى؟
كنت أفكر في إجراء استعادة مرة أخرى؟
ستحتاج إلى الدخول إلى قاعدة البيانات وإجراء بحث/استبدال شامل.
توجد أداة لذلك:
RAILS_ENV=production discourse remap //old.domain //new.domain
يمكنك إصلاحه كما هو موضح، ولكن لا ينبغي أن يحدث ذلك.
هل قمت بعمل نسخة احتياطية واستعادتها باستخدام /admin/backups؟
هل تم تعيين اسم المضيف بشكل صحيح في كلا النظامين؟
شكرًا لك. بدا الأمر سهلاً بما فيه الكفاية. أدخلت التطبيق وقمت بتشغيل ذلك ولكن يبدو أنه لم يغير مثيلات عناوين URL في المنشورات.
كان هذا هو إعادة التعيين:
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
تم تشغيل هذا واكتمل على قاعدة البيانات “الافتراضية” ، واستغرق بضع دقائق ثم أبلغ عن “تم” بدون خطأ.
نظرت إلى بعض المنشورات المختارة ولم يتغير أي شيء على روابط عناوين URL لجميع المنشورات.
أعدت بناء البعض للاختبار حيث رأيت dev.domain.com بدلاً من domain.com المباشر في الروابط ، لكنها ظلت كما هي.
ثم قمت بتشغيل نفس الشيء ولكن بدون https:// وحصلت على هذا الخطأ
إعادة تعيين الجداول على الافتراضي...
خطأ: خطأ: قيمة المفتاح المكرر تنتهك القيد الفريد "index_post_hotlinked_media_on_post_id_and_url_md5"
التفاصيل: المفتاح (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) موجود بالفعل.
تم تطبيق إعادة التعيين جزئيًا فقط بسبب الخطأ أعلاه. يرجى إعادة تشغيل البرنامج النصي مرة أخرى.
أعتقد أن هناك رسالة دردشة في قاعدة البيانات تتسبب في توقفها ولكن لست متأكدًا من السبب. أفترض أنني بحاجة إلى رؤية ذلك بطريقة ما في قاعدة البيانات ، كما يمكنك أن تخبرني بأن تحويلي المعتاد في إدارة discourse لا يكون أبدًا في قاعدة البيانات.
أخيرًا ، أعدت تشغيل إعادة التعيين الأصلية ، واستغرقت بضع دقائق وأبلغت عن “تم” بدون أخطاء:
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
ربما أحتاج إلى إعادة بناء المنشورات لرؤية الثمار؟
اعتقدت أن إعادة بناء المنشور كانت نفس الإجراء ولكن على أساس كل منشور على حدة.
أو إعادة بناء التطبيق؟
يجب أن يكون ذلك
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
السبب في // هو أنه يطابق http:// و https:// وعناوين URL بدون بروتوكول، ولا يطابق نطاقات البريد الإلكتروني.
ماذا يحدث عندما تفعل ذلك؟
نعم حسناً، ثم نفس الخطأ مرة أخرى:
إعادة تعيين الجداول افتراضياً...
خطأ: خطأ: قيمة المفتاح المكرر تنتهك القيد الفريد "index_post_hotlinked_media_on_post_id_and_url_md5"
التفاصيل: المفتاح (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) موجود بالفعل.
تم تطبيق إعادة التعيين جزئياً فقط بسبب الخطأ أعلاه. يرجى إعادة تشغيل البرنامج النصي مرة أخرى.
لذلك على الأقل أنا أستخدم أمر الكتابة الصحيح، الأمور تتحسن! 
هل لا توجد أفكار أخرى؟
بصرف النظر عن هذا الجمود في إعادة تعيين rails، فكرت ربما إذا قمت بعمل نسخة احتياطية من قاعدة البيانات وأجريت استعادة مرة أخرى، فقد تعيد تعيين عناوين URL للروابط بشكل صحيح أثناء عملية الاستعادة؟
يبدو أن الخطأ الذي ما زلت أواجهه مشابه جدًا للخطأ الذي توقف هنا والذي كان بحاجة إلى إصلاح:
Error: ERROR: duplicate key value violates unique constraint \"index_post_hotlinked_media_on_post_id_and_url_md5\"
DETAIL: Key (post_id, md5(url::text))=...
عند محاولة إعادة التعيين:
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
ربما لدى @david رؤية هنا؟
هل يبدو هذا خطأ أكثر؟
تلعب تلك الجدول روابط تحتوي على كلا النطاقين، لذلك عندما تحاول إعادة تعيينها تحصل على مفتاح مكرر. هذه ليست مشكلة. أنت تحاول إنشاء مفتاح مكرر.
يمكنك إزالة العناصر من ذلك الجدول التي تحتوي على النطاق الجوي. فكرة أفضل هي استخدام www بدلاً من النطاق الجوي.
شكرا لك. قلقي الوحيد هو أن نشر هذا الخطاب يعاني أيضًا من مشكلة عدم وجود www / SSL، على سبيل المثال How to add ssl to non-www domain? ولكني سأجرب إعادة التعيين التي تقترحها وإذا نجحت فستجبرني على حل مشكلة عدم وجود www أيضًا!
لقد نجحت إعادة التعيين كما اقترح @pfaffman، لكنها كانت في الواقع محفزًا للحل، وليست الحل بحد ذاته، فقد ساعدتني في اكتشاف الخطأ الذي كنت أرتكبه، لقد أعادت تعيين عيني!
لو كنت قد قرأت الخطأ بشكل صحيح، أي انتبهت. لكنت قد حللت هذا منذ وقت طويل حيث كنت سأرى أن المعلومات الرئيسية كانت في رسالة الخطأ.
كل ما كان علي فعله هو تضمين رقم المنشور الذي تم تمييزه بخطأ التوقف …/p/123456789 في عنوان URL للانتقال مباشرة وإصلاح كل منشور يدويًا.
حدث هذا في الغالبية العظمى في تشغيل إعادة تعيين ثانٍ لتحويل www من إعادة التعيين الأولى إلى عنوان URL غير www الأساسي كما كانت الحاجة الأصلية.
الآن يجب أن تتضمن عناوين URL الداخلية روابط أساسية فقط.
هذا يحل بعض إعادة توجيه SSL لـ www حيث كانت هناك العديد من روابط www القديمة الداخلية. لا يحل مشكلة قيام المستخدم بكتابة www في شريط العنوان أو الارتباط الخارجي على WWW نفسه، ولكنه يجب أن يعالج جميع الروابط التي تم إنشاؤها داخليًا. في انتظار رؤية كيف يؤثر ذلك على فهرسة Google قبل القيام بأي شيء آخر بشأن هذه المشكلة.
ربما يكون ذا أهمية للمطورين.
لقد وجدت الكثير من التوقفات بسبب duplicate key value violates unique constraint “unique_post_links”، حدثت هذه عندما تم نقل منشور وتضمين discourse “Continued from …. “ مع رابط مباشر، ولكن إذا تضمنت المنشورات المقسمة كتلًا مقتبسة إلى نفس المكان، فسيؤدي ذلك إلى إيقاف إعادة التعيين.
هذا تسبب في غالبية أخطاء التوقف.
كان الحل هو إزالة أحد الروابط المكررة الداخلية أو وضعها بين أقواس (لم ينجح دائمًا) وستنتقل إعادة التعيين بعد إعادة تشغيلها.
تسببت أخطاء التوقف الأخرى في قيام المستخدمين بإنشاء نفس الشروط في المنشور يدويًا عن طريق إعادة نشر نفس الرابط إلى منشور دون إدراك أن الاقتباس يرتبط أيضًا، ربما تأتي العادات التاريخية أو الأساليب وما إلى ذلك في اللعب هنا، مما يشير إلى أن العديد من المستخدمين لا يدركون حتى الآن مدى تعامل discourse مع الروابط لجعل الحياة أسهل، يا للسخرية!
بعد إعادة التعيين، كان بإمكاني التراجع عن التعديلات، لكنها لم تكن كثيرة بما يكفي لإحداث فرق وكان لا يزال هناك رابط واحد صحيح إلى مصدر discourse الداخلي للمنشور أو الاقتباس.
نأمل أن يعكس هذا الجزء الأكبر من إلغاء فهرسة Google لعشرات الآلاف من الصفحات إلى منطقة رمادية غير مفهرسة.
القليل من المعرفة شيء خطير! 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.