مشكلة في إعادة توجيه الروابط الدائمة بسبب عدم إرسال الجزء بعد "#" إلى الخادم

الدعم
1

تعديل: قمت بتغيير عنوان الموضوع ليتوافق مع المشكلة التي اكتشفتها، وذلك بفضل الإجابات أدناه

أواجه سلوكًا غريبًا مع الروابط الدائمة (permalinks) في عملي على الترحيل.

مشكلتي ليست تلك المتعلقة بالروابط الداخلية التي لا تقوم بإعادة التوجيه. أنا فقط أجرب ذلك عن طريق لصق الروابط في شريط عنوان المتصفح.

هذان هما إعادة التوجيه اللذان أرمي إلى حدوثهما في اختباراتي:

هذه إعادة توجيه لـ منشور، ويجب أن توجه إلى المنشور الثاني على النحو التالي:

هذه إعادة توجيه لـ موضوع، ويجب أن توجه إلى:

أعلم أن عمليات التطبيع (normalizations) الخاصة بي تعمل بشكل صحيح. تعبيراتي النمطية (regexp) هي:

/(?:.*)(\/)(?<topicid>\d*.)-(.[^\/#\?]*)(?<parm>\?(\w*)[=](?<start>\d+))?(?:\/)?(\D+(\/)?)?(?<postid>\d+)?(?:\/)?/normalized.\k<topicid>.\k<postid>

وأقوم بفحصها في وحدة تحكم rails:

irb(main):069:0> Permalink.normalize_url('https://community.suitecrm.com/languages/17978-why-two-italian-language-packs#16249')
=> "normalized.17978.16249"

irb(main):068:0> Permalink.normalize_url('https://community.suitecrm.com/languages/17978-why-two-italian-language-packs')
=> "normalized.17978."

هذا هو ما كنت أعتزمه. لدي هذا في جدول Permalinks:

image
image611×356 42.9 KB

وهذا ما يبدو عليه من قاعدة البيانات:

image
image561×138 35.4 KB

لكن عندما أضع هذا في عنوان URL للمتصفح

يتم إعادة توجيهه إلى

بدلاً من ما يجب أن يكون عليه

لذا أرى المنشور الأول، ولا يتم التمرير إلى المنشور الثاني كما يجب.

لماذا يتم إضافة تجزئة #16249 مرة أخرى، إذا كان تطبيقي قد أزالها؟

طريقة أخرى لكشف هذا التناقض (رغم أنها اصطناعية بعض الشيء) هي تجربة إعادة التوجيه التالية من شريط عنوان المتصفح:

https://community.suitecrm.com/normalized.17978.
يتم إعادة التوجيه بشكل صحيح إلى:
Reports disappeared - 💬 General Discussion - SuiteCRM

و Why two Italian language packs? - #2 by roberto - Translation and Language Packs - SuiteCRM
يتم إعادة التوجيه بشكل صحيح إلى
Reports disappeared - #2 by erevodifosin - 💬 General Discussion - SuiteCRM

إذن لماذا لا يعمل الأمر عند المرور عبر العملية العادية؟

2

روابط الدائمة تعمل فقط للروابط الواردة، وهذا موضح في الوصف.

image
image1125×1081 167 KB

ستحتاج إلى تصحيح الروابط الداخلية.

3

لقد ذكرت في بداية منشوري أن هذا ليس هو الحال، فأنا لا أنقر على الروابط في منتداي الخاص.

ولكن ربما لم أفهم ما يُقصد هنا بـ “الروابط الداخلية”، هل يمكنك شرح ذلك بشكل أفضل؟ إذا قمت بلصق عنوان URL في شريط عناوين المتصفح، فكيف يُعتبر ذلك رابطًا داخليًا؟

4

لا يرسل المتصفح معرّف جزء عنوان URL (الرمز # وما يليه) إلى الخادم أبدًا — لا يمكنك استخدامه كجزء من إعادة التوجيه.

5

الآن بعد أن قلت ذلك، يبدو الأمر منطقياً… لكنه محبط جداً.

أعتقد أن هذا يستبعد تماماً إمكانية إعادة التوجيه على مستوى المنشورات من منتدياتي القديمة، لأنها تستخدم # لهذا الغرض :sob:

هل هذه قيود شائعة واجهها الناس في عمليات الترحيل؟ أعتقد أن برنامج Kunena شائع جداً، وأراهن أن الآخرين يستخدمون أيضاً علامات التجزئة للربط مع المنشورات…

6

لقد كنت أفكر في هذا الأمر طويلاً. إنه قيد مزعج للغاية. أعتقد أن الخطأ الأساسي ارتُكب منذ زمن بعيد، من قبل مصممي منتديات Kunena، عند استخدام مجرد أجزاء (fragments) لوضع روابط المنشورات… آه.

أرى ثلاثة أساليب يمكن لـ Discourse استخدامها لتجاوز هذه المشكلة (أدخل هنا بوضوح في منطقة التفكير بالتمني، استمتعوا بالرحلة):

  1. يقوم JavaScript بالتدخل عند تحميل الصفحة، ويتعرف على وجود جزء (hash fragment) في URI، ثم يستخدمه للاتصال بالخادم وإعادة التوجيه إلى المكان الصحيح. يعمل هذا الحل، لكنه يؤدي إلى إعادة توجيه مزدوجة، ويرى المستخدم الصفحة تعيد التحميل.

  2. يمكن لـ Discourse إضافة (من جانب الخادم) وسم id يحتوي على post_id المستورد القديم إلى HTML كل منشور. بهذه الطريقة، سينقل المتصفح معرف التجزئة القديم، ويستخدمه في الصفحة المعاد توجيهها للتمرير إلى الأسفل. التحدي الرئيسي: نظام التمرير المتقدم في Discourse، حيث يتم تحميل المنشورات فقط عند التمرير إليها، يجعل هذا المخطط غير كافٍ.

  3. مزيج من الحلين السابقين: يقوم Discourse ببناء (من جانب الخادم) جدول للتطابق بين post_ids المستوردة القديمة وpost_numbers الجديدة، ويرسله إلى العميل عند تحميل الصفحة. يتعرف JavaScript على الجانب العميل على وجود جزء (hash) في URI، يترجم ذلك الجزء باستخدام الجدول، ثم يستخدم دوال التمرير الخاصة به للنزول إلى المنشور الصحيح.

سيكون هذا التنفيذ مرهقًا وسيفرض عقوبة على الأداء. ومع ذلك، سيمكّن من حدوث هجرات مثالية…

7

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

8

منهجيتي الحالية لإعادة التوجيه الداخلية/الخارجية هي كالتالي:

موقعي القديم موجود في
https://suitecrm.com/suitecrm/forum/، بينما الموقع الجديد في
https://community.suitecrm.com/

عندما يبدأ خادم الهجرة بالعمل، سنقوم بإعادة توجيه بوابة (Gateway redirect) من القديم إلى الجديد.

أبقي روابطي الداخلية دون تغيير، بدءًا بـ https://suitecrm.com/suitecrm/forum/. وعندما يضغط عليها أحد، فإنها تعتبر خارجية عمليًا. لكن بعد ذلك، تحدث إعادة توجيه البوابة لدينا، فتعود إلى Discourse، ويجب أن تعمل الروابط الدائمة (permalinks) بشكل طبيعي.

صحيح؟ لم أجرب هذا بعد… أعتقد أن هذا سيكون مستحيلاً إذا أردنا استخدام نفس اسم النطاق ونفس المجلد، لكننا لا نريد ذلك.

9

ما عليك فعله هو استخدام إعادة توجيه الروابط الدائمة.

غالبًا ما أنشئ روابط دائمة مثل /oldpost/POST_ID ثم أكتب إعادة توجيه رابط دائم لإعادة كتابة /forum./category/someslug#1234 لاستخدام هذه الروابط.

10

هل تقصد بإعادة توجيه الروابط الدائمة إعداد الموقع “تطبيع الروابط الدائمة”؟

11

أوه نعم! آسف. كان دماغي متعبًا في ذلك الوقت.

12

حسنًا :slight_smile:

لكنني أستخدم تطبيع الروابط الدائمة (انظر منشوري الأول). الجزء الخاص بـ hash فقط هو الذي لا يُرسل إلى الخادم (دائمًا)، لذا ما لم يكن هناك شيء من جانب العميل باستخدام JavaScript يقوم بسحره، فلا توجد طريقة لكي يتم ترحيل منتدى يستخدم فقط روابط hash على مستوى المنشورات بشكل صحيح (من حيث إعادة التوجيه) إلى Discourse (أو إلى أي برنامج آخر).

13

آسف. لم أقرأ ذلك بدقة كافية. ظننت أنني استخدمت محتوى بعد علامة الهاش من قبل، لكن يبدو أن هذا خطأ. أتذكر حالة حديثة كانت فيها معرفات المنشورات بالهاش موجودة، لكن يبدو أن العميل أراد فقط إعادة توجيه على مستوى الموضوع. أعتقد أن إعادة التوجيه 301 التي تؤدي إلى الموضوع الصحيح قد تكون كافية.