بعد الترقية إلى الإصدار 3.1.1 من الإصدار 2.8.x، أصبحت جميع القوالب القديمة التي تستخدم %{base_url}%{url} لتضمين رابط لموضوع ما، تظهر الآن على أنها غير صالحة، حيث تقول واجهة المستخدم الرسومية مفتاح الاستيفاء التالي غير صالح: base_url
لكنه في الواقع صالح، لأنه إذا قمت بإزالته وتركت %{url} فقط، فسيكون الرابط معطلاً (يشمل المسار فقط، بدون النطاق) وإذا قمت بتضمينه، فسيكون الرابط صالحًا وبشكل كامل.
نظرًا لأنك تعرف بالفعل عنوان URL الأساسي لموقعك، لست متأكدًا من أن المفتاح مطلوب. بدلاً من %{base_url}%{url}، استخدم عنوان URL الخاص بموقعك فقط. على سبيل المثال https://forum.example.com%{url}
ولكنه يعمل، أي أن %{base_url} يتم توسيعه بشكل جيد، لذا فهو ليس غير صالح (إنه فقط الواجهة الرسومية التي تشتكي). علاوة على ذلك، لا يمكن إنشاء رابط يعمل بالكامل بدونه (إلا إذا قاموا بترميز عنوان URL الأساسي الكامل يدويًا، وهو أمر غير مقبول)
الغرض من العناصر النائبة بشكل عام هو جعل البرامج قوية، وهذا يشمل تجنب ترميز الأشياء يدويًا. إذا قمت بتغيير اسم النطاق أو اسم المضيف أو المسار لتثبيت Discourse الخاص بي (أي عنصر من عناصر base_url) فسيتعين عليّ تحرير جميع القوالب التي قمت بترميزها يدويًا. هذه ممارسة ترميز سيئة.
نظرًا لأنني أعرف أن تطوير Discourse يتبع بخلاف ذلك ممارسات ترميز صحية وقوية جدًا، يمكنني فقط افتراض أنه كان سهوًا / خطأً (1) إزالة base_url عند التحقق من صحة القالب ولكن (2) لا يزال يفسره إذا كان موجودًا، و (3) لا يقدم بديلاً لبناء عنوان URL يعمل بالكامل دون اللجوء إلى ممارسات الترميز السيئة …
بالإضافة إلى ذلك، سيكون هذا تغييرًا كبيرًا غير متوافق مع الإصدارات السابقة لا أرى له أي فائدة حقيقية، ولكنه يسبب الكثير من العمل اليدوي للمستخدمين … سبب إضافي لافتراض أنه خطأ / سهو.
(لقد رأيت أيضًا أخطاء أخرى تم تقديمها في الإصدار 3.x تتعلق بقوالب النص، لذلك هناك سبب إضافي لافتراض أنه كان سهوًا)
عندما أختبر هذا، لا يمكنني الحصول على %{base_url} لحفظه، لذلك لا يتم استخدامه.
ربما يكون هذا سهوًا. أتفق على أنه يمكن أن يؤدي إلى كسر قوالب البريد الإلكتروني الحالية من المواقع القديمة. سأعيد هذا إلى فئة Bug وأمنح الفريق فرصة لتحديد ما يجب فعله بشأنه.
كما ذكرت في البداية، أنا أتحدث عن القوالب المخصصة الموجودة التي تم تمييزها بشكل خاطئ على أنها غير صالحة بعد الترقية إلى 3.x، أي القوالب التي تم تحريرها تحت 2.x ولا تزال موجودة بعد الترقية وتحتوي على %{base_url}. إزالة هذا العنصر النائب يجعل من المستحيل إنشاء عناوين URL كاملة دون اللجوء إلى ترميز عناوين URL الثابتة. عدم إزالته يجعل من الواضح أنه لا يزال يتوسع بشكل جيد تحت 3.1.1. أعدت قراءة المنشور الأول ولا أجده غير واضح.
ربما يمكنك اختباره بنفسك عن طريق تحرير قاعدة البيانات مباشرة (أو ربما أيضًا في وحدة تحكم Rails إذا لم يقم الكود بتشغيل نفس التحقق).
يبدو هذا خطأً بالفعل. ربما ما يفترض أن يحدث هو أن %{url} يجب أن تتضمن اسم المضيف. في قالب endo، يكون عنوان URL بدون اسم المضيف هذا عديم الفائدة إلى حد ما (ما لم تكن هناك طريقة html لتغيير القاعدة النسبية عالميًا؟)
الفريق في مؤتمر هذا الأسبوع، لذا سيستغرق الأمر بعض الوقت قبل أن يتمكنوا من إبداء رأيهم في هذا الأمر.
لا أعتقد أن ذلك سيكون ممارسة جيدة، لأنه لا توجد طريقة للإشارة إلى جذر الموقع. يلعب %{base_url} دورًا مهمًا لسبب ما، للسماح ببناء عناوين URL. بشكل عام، توفر أنظمة القوالب لعناوين URL 3 عناصر نائبة: base، path، full_url، مع تقديم الأخير للراحة فقط (إنه تسلسل الأولين).
@pfaffman لم يتم إصلاح هذا حتى في الإصدار 3.2.1. لم يتغير شيء منذ تقريري الأولي. هل يمكن تصعيد هذا ليتم إصلاحه، من فضلك؟ باختصار، يجب أن تسمح كل القوالب تقريبًا باستخدام %{base_url} نظرًا لأن %{url} يتضمن فقط المسار بعد عنوان URL الأساسي.
على الأقل لا تمنع المستخدم من استخدامه (على الرغم من أنه لا يظهر في قائمة المفاتيح المتاحة).
هل يمكن لأحد المساعدة في اسم كائن rails أو أمر وحدة تحكم rails لـ فرض%{base_url} في قالب أعرف أنه يقبله ويتوسع (إنها الواجهة الرسومية فقط هي التي تقول إنه غير صالح)؟
هل يمكنك تقديم المزيد من المعلومات، مثل لقطة شاشة ومفتاح القالب الذي تحاول تحديثه. ليس لدي مشكلة في استخدام base_url على نسختي، ولكن المشكلة قد تكون متعلقة بقالب معين.
هناك العديد من الأمثلة الأخرى أيضًا (معظم قوالب البريد الإلكتروني، على سبيل المثال).
يجب أن تسمح كل قالب بريد إلكتروني (إن لم يكن كل قالب نصي!) باستخدام %{base_url} نظرًا لأن هذا هو الموقع الجذر الذي يجب أن يكون المرء قادرًا على الإشارة إليه من أي مكان. أنا لا أفهم قرار إزالته بشكل انتقائي من بعض القوالب … إلا إذا كان ذلك خطأ غير مقصود بطريقة ما.