في community.wanikani.com، توقف فتح أي روابط لمواضيع تحتوي على أحرف يابانية في عنوان URL الكامل عن العمل عند فتحها في علامة تبويب جديدة أو عند نسخ الرابط ولصقه مباشرة. أما النقر على الرابط للتنقل داخل نفس علامة التبويب فيعمل بشكل صحيح.
على سبيل المثال، عند فتح هذا الرابط في علامة تبويب جديدة، يجب أن يتم التوجيه إلى:
إذا كان الرابط مطابقًا تمامًا، فإنه يعمل بشكل صحيح. ولكن بالطبع، مع إعادة تسمية المواضيع، لا يحدث ذلك في كثير من الأحيان.
حاولت أيضًا إعادة إنتاج المشكلة على try.discourse.org، ولكن في هذا التثبيت لا يتم إضافة الأحرف اليابانية إلى عنوان URL أبدًا حتى لو كانت مدرجة في عنوان الموضوع. لست متأكدًا من سبب ذلك، ولكن دون حدوث ذلك لا يمكنني إثبات الخطأ هناك.
نَفَس عميق يبدو أن الأمر قد يكون خطأً آخر في Chrome. إنه يعمل بشكل مثالي بالنسبة لي في كل من Firefox و Edge. الغريب أنه يعمل في المرة الأولى في نافذة التصفح المتخفي، لكنه يفشل في المرة الثانية. نفس الشيء يحدث بعد مسح ذاكرة التخزين المؤقت للموقع وملفات تعريف الارتباط وإعادة تشغيل جهاز الكمبيوتر.
يذكر Chrome أن الخطأ هو وجود عدد كبير جدًا من عمليات إعادة التوجيه.
هل يمكنك التحقق في Chrome للتأكد مما إذا كانت المشكلة عامة هناك وليست فقط مشكلة لي؟ فقط تأكد من محاولة فتح الصفحة عدة مرات لأن المرة الأولى تبدو وكأنها تعمل بشكل جيد. أقدر مساعدتك!
ما زلت تستخدم Chrome؟ أود فقط التأكد قبل إبلاغهم بذلك. أفترض أنه لم يحدث أي تغيير متعلق بهذا الأمر مؤخرًا في Discourse؟ (بغض النظر، فغالبًا ما تظل هذه مشكلة متعلقة بـ Chrome، حيث تحدث فقط هناك، حتى لو حدث تغيير ما في Discourse.)
حسنًا، لقد عدت. بدأت المشكلة مرة أخرى اليوم. لا أعرف كيف تم حلها لفترة قصيرة.
بما أن هذا قد يستغرق وقتًا، فأنا منفتح على وجود حلول بديلة مؤقتًا. لقد ذكرت في المنشور الأصلي أنه عند المحاولة (وقد تحققت من ذلك هنا في قسم الميتا أيضًا)، لا يتم إضافة الأحرف اليابانية إلى عنوان URL أبدًا، مما يتجاوز هذه المشكلة فعليًا. هل هذا إعداد خاص بالموقع أو بالفئة يمكنني مناقشته مع مدير موقعي؟ هل هناك أي اقتراحات أخرى للحل البديل بخلاف ذلك؟
لقد بحثت في قاعدة أكوادنا ويبدو أن الخطأ بسيط إلى حد ما، لكنني أود التحقق من افتراضاتي.
لدينا إعداد موقع يُسمى slug_generation_method يجب تغييره من القيمة الافتراضية ascii إلى encoded لتفعيل هذا الخطأ. عند تغيير هذا الإعداد، نقوم بمسح جميع الروابط القصيرة (slugs) وإنشائها من جديد.
ما لا أفهمه هو سبب توليد رابط قصير بهذا الشكل عندما يكون إعداد الموقع مضبوطًا على “encoded”:
يتم إرجاع الرابط القصير الخام من الجدول في رأس الاستجابة Location برمز 301 عندما لا يتطابق رابط الموضوع، وبما أنني أرى أننا يجب أن نعيد عنوان URL صالح هناك.
إذن هل تقصد أن عنوان URL نفسه سيظهر النسخة المشفرة؟ أم أن إعادة التوجيه ستتعامل معها داخليًا فقط باستخدام النسخة المشفرة؟ في كلتا الحالتين، سيكون من الرائع أن يعمل هذا الأمر “بشكل تلقائي” دون الاعتماد على سلوكيات المتصفح الخاصة.
لا، كما يُشار إليه بالموضوع المفتوح في فئة bug هنا
@sam لقد راجعت هذا مرة أخرى اليوم وهناك طريقتان للتعامل مع الأمر:
تخزين سلاجل (slug) مشفر فعليًا في عمود السلاجل عندما تكون إعدادة توليد السلاجل مضبوطة على مشفر. قم بإنشاء هجرة (migration) لمسح جميع السلاجل الحالية عند استخدام سلاجل مشفرة بحيث يتم إعادة توليدها بشكل صحيح مع مرور الوقت.
الاحتفاظ بالسلاجل الحالي بتنسيق UTF-8 وتصحيحه على الفور عند إرساله في رأس (header) لإعادة التوجيه 301.
في رأيي، الخيار 1 هو “الأصح” وسيجعل من الصعب تمرير السلاجل الخام إلى العميل. ومع ذلك، لم يكن تصحيح مولد السلاجل كافيًا، حيث يحصل المتصفح على عنوان URL مشفر عند إعادة التوجيه 301، لكنه يفك تشفيره في الطلب التالي، مما يؤدي إلى فشل مقارنة السلاجل وإعادة التوجيه مرة أخرى. هذا يعني أنني سأحتاج أيضًا إلى تصحيح طريقة مقارنة السلاجل في وحدة تحكم المواضيع (topics controller)، وربما في أماكن أخرى.
