هل هذا هو الشيء الوحيد الذي يفعله هذا الإعداد؟
أشعر أن اسمه ووصفه في WP غامضان للغاية، لذلك كنت أتساءل عما قد يفعله أيضًا؟
بخصوص هذا،
ماذا لو كان المستخدم موجودًا بالفعل داخل ووردبريس و ديسكورس. كيف أقوم بدمج / ربط ملفاتهم الشخصية؟
من الناحية الفنية، ما يفعله هو إجراء استدعاء لمسار sync_sso الخاص بـ Discourse وتمرير بياناتهم (معرف مستخدم WordPress، اسم المستخدم، الاسم، البريد الإلكتروني…) إلى Discourse فور تسجيل دخولهم إلى WordPress. التفاصيل حول مسار sync_sso موجودة هنا: Sync DiscourseConnect user data with the sync_sso route.
التأثير الجانبي الوحيد لهذا الذي أعرفه لمستخدمي WordPress الذين لم يزوروا موقع Discourse مطلقًا هو أنهم سيبدأون في تلقي رسائل البريد الإلكتروني المجمعة من Discourse.
لهذا السبب تريد تشجيع مستخدمي Discourse على التسجيل في WordPress بنفس عنوان البريد الإلكتروني الذي يستخدمونه في Discourse. طالما تطابقت عناوين البريد الإلكتروني، سيتم تسجيل دخولهم إلى حساب Discourse الصحيح. هذا بافتراض أنك تعتني بمشكلة التحقق من البريد الإلكتروني التي ناقشناها في المشاركات السابقة.
من المحتمل أن ينتهي بك الأمر ببعض المستخدمين الذين يسجلون في WordPress بعناوين بريد إلكتروني مختلفة عن تلك التي استخدموها في Discourse. في هذه الحالة، سيتم إنشاء حساب Discourse جديد لهم، باستخدام عنوان البريد الإلكتروني الخاص بـ WordPress. ستحتاج إلى دمج الحساب القديم في Discourse يدويًا في حساب Discourse الجديد: Merging user accounts.
3 إعجابات
ماذا يحدث إذا كان علينا تحديث البريد الإلكتروني للمستخدم يدويًا في ووردبريس. هل يتم تحديث البريد الإلكتروني الخاص بـ Discourse الخاص بهم أيضًا إذا تم تمكين هذا الإعداد؟
إعجاب واحد (1)
تحديث مستخدم من صفحة ملفه الشخصي في ووردبريس لا يؤدي إلى استدعاء sync_sso. ربما يجب أن يفعل ذلك. في الوقت الحالي، ستحتاج إلى مطالبتهم بتسجيل الخروج من ووردبريس، ثم تسجيل الدخول مرة أخرى إلى ووردبريس. لا أعتقد أنه من الممكن لمسؤول تسجيل خروج مستخدم ووردبريس من صفحة ملفه الشخصي.
إذا كنت ترغب في مزامنة رسائل البريد الإلكتروني و/أو أسماء المستخدمين بين ووردبريس و ديسكورس، فقم بتمكين إعدادات ديسكورس هذه:
auth overrides emailauth overrides username
إعجاب واحد (1)
شكراً لك يا سيمون. أعتقد أن هذه هي العملية التي سأتبعها بعد النظر في كل شيء:
- تصدير المستخدمين من Discourse
- تفعيل Discourse Connect
- استيراد وإنشاء هؤلاء المستخدمين في Wordpress وتمييز رسائل بريدهم الإلكتروني كـ “تم التحقق منها” في WP
- عندما يقوم هؤلاء المستخدمون بتسجيل الدخول (عبر صفحة تسجيل دخول مخصصة) يتعين عليهم إعادة تعيين كلمة المرور الخاصة بهم
- بطريقة ما إجبار هذه الشريحة من المستخدمين فقط على تغيير كلمة المرور الخاصة بهم بعد إدخال بريدهم الإلكتروني (ويدرك النظام أنهم جزء من هذه الشريحة)
- أو فقط عرض رسالة على صفحة تسجيل الدخول: “إذا كنت تقوم بتسجيل الدخول بعد [تاريخ] فيجب عليك إعادة تعيين كلمة المرور الخاصة بك”
- يجب أن يعمل الوصول!
بالنسبة للاشتراكات الجديدة التي ترد، سأحتاج إلى إيجاد طريقة للتحقق من رسائل البريد الإلكتروني. من المحتمل أن أرسل لهم كلمات المرور الخاصة بهم عبر البريد الإلكتروني.
لاحظت أيضًا أنه حتى لو لم يتم تحديد إعداد “عنوان البريد الإلكتروني تم التحقق منه” في ملف تعريف Wordpress، فلا يزال المستخدم قادرًا على تسجيل الدخول الأحادي إلى Discourse. يتعين عليهم تأكيد بريدهم الإلكتروني بغض النظر في المرة الأولى التي يدخلون فيها Discourse. وهذا جيد.
هل لهذه الإعدادات أي آثار جانبية؟
إعجاب واحد (1)
نعم، هذه هي الطريقة المقصودة. هذا ليس حاجزًا كبيرًا لمعظم المستخدمين. المشكلة التي تحتاج إلى الانتباه إليها هي أنه إذا لم يتم تمييز عنوان البريد الإلكتروني على أنه تم التحقق منه في ووردبريس، فلن يقوم ديسكورس بمطابقة مستخدمي ووردبريس بمستخدمي ديسكورس بناءً على عنوان بريدهم الإلكتروني في المرة الأولى التي يسجلون فيها الدخول إلى ديسكورس عبر DiscourseConnect. طالما أنك اكتشفت كيفية تمييز عناوين البريد الإلكتروني للمستخدمين المستوردين لديك على أنها تم التحقق منها، فلن يسبب ذلك مشكلة. إذا لم تقم بتمييزها على أنها تم التحقق منها، فسيكون الأمر مزعجًا لفرز الأمور.
إذا تم تمكينها، فإنها تمنع المستخدمين من تغيير اسم المستخدم أو عنوان البريد الإلكتروني الخاص بهم على ديسكورس.
إعجاب واحد (1)
نعم، كنت أختبر الكثير وأدركت ذلك. سأقوم بكتابة نص برمجي مخصص يميز جميع المستخدمين الذين أستوردهم على أنهم مُحقّقون.
شكراً للتوضيح!
إعجاب واحد (1)
هل من المقبول الاحتفاظ بـ verbose /logs إلى الأبد؟
هل سيؤثر هذا سلبًا على الأداء؟
لقد رأيت حالات تم تركها قيد التشغيل إلى الأبد. لا أعتقد أن له أي تأثير كبير على الأداء. إنه فقط يربك سجلاتك إذا كنت تحاول تصحيح مشكلة لا تتعلق بـ DiscourseConnect.
إعجابَين (2)
لقد كان كل شيء يعمل بشكل رائع حتى الآن!
شيء واحد صغير ألاحظه هو أن أي مسار أقوم بإدخاله في هذا الحقل:
يصبح صفحة تسجيل الدخول الافتراضية لـ WordPress.
على سبيل المثال، إذا حاولت الآن الذهاب إلى /wp-admin وهو ما كنت أستخدمه سابقًا لتسجيل الدخول كمسؤول، فإنه يعيد توجيهي إلى /login/forum
من الناحية المثالية، يجب أن يعيد التوجيه إلى هذا فقط عندما ينقر شخص ما على زر تسجيل الدخول من منتدى discourse.
أتساءل عما إذا كان هذا سلوكًا طبيعيًا وما إذا كان من السيئ أن يعمل بهذه الطريقة.
هذا هو السلوك المتوقع. يتم استخدام خيار “مسار صفحة تسجيل الدخول الخاصة بك” لتجاوز مسار تسجيل الدخول الافتراضي لـ WordPress. يقوم بذلك عن طريق الربط بفلتر login_url الخاص بـ WordPress.
لا يزيل مسار تسجيل الدخول الافتراضي على /wp-login.php، لذا لا يزال بإمكانك الانتقال مباشرة إلى عنوان URL هذا عن طريق إدخاله في شريط عنوان المتصفح الخاص بك. بدلاً من الانتقال إلى /wp-admin، انتقل إلى /wp-login.php لاستخدام صفحة تسجيل الدخول الافتراضية.
يمكنني التفكير في طريقة يمكن بها تحديث المكون الإضافي لإعادة التوجيه فقط إلى المسار “مسار صفحة تسجيل الدخول الخاصة بك” لتسجيل الدخول إلى Discourse، ولكن هذا التغيير سيتطلب بعض العمل.
4 إعجابات
لا مشكلة. مجرد شيء بسيط. شكراً على الأفكار!
إعجاب واحد (1)
م
تلقيت للتو لقطة الشاشة هذه من المستخدم:
قال: “لا يوجد بريد إلكتروني. بمجرد النقر على رابط التسجيل، يتم تقديمك بالصفحة التالية…”
عندما أنقر على رابط تسجيل الدخول/التسجيل (في وضع التصفح المتخفي)، فإنه يعمل بالنسبة لي.
إليك عنوان URL لمنتدانا كمرجع: forum.projectvanlife.com
أفترض أن الإدخالات التي تبدأ بـ “سجل SSO المطول” تظهر تسجيلات دخول ناجحة.
بالنسبة لأخطاء “google_oauth2” و “OAuth::Unauthorized” و “facebook”، لست متأكدًا مما يحدث. هل تم تكوين موقع Discourse الخاص بك مسبقًا للسماح للمستخدمين بتسجيل الدخول عبر Google و Facebook؟ إذا كان الأمر كذلك، فلن يتمكنوا من تسجيل الدخول إلى الموقع بهذه الطرق الآن بعد تمكين DiscourseConnect. ربما حاول تعطيل تسجيلات الدخول إلى Google و Facebook من صفحة إعدادات Discourse الخاصة بك.
بالنسبة للمستخدمين الذين يبلغون عن أخطاء في تسجيل الدخول، حاول العثور على رسالة خطأ مطولة في سجل SSO مرتبطة بمحاولة تسجيل دخول المستخدم. ثم تحقق مما إذا كان الخطأ يتطابق مع أي من المشكلات الموضحة في هذا الموضوع: Debug and fixing common DiscourseConnect issues.
عنوان URL المعروض في شريط عنوان المتصفح هو https://projectvanlife.com/login/forum/javascript%3Avoid(0.
أفترض أن بعض جافا سكريبت يتم اقتطاعه وأنه مخصص بالفعل لفك تشفيره إلى javascript:void(0). لست متأكدًا من مصدر ذلك. ربما من أحد ملحقات متصفح المستخدم. حاول أن تطلب منهم تعطيل ملحقات المتصفح الخاصة بهم، أو محاولة تسجيل الدخول من نافذة متصفح متخفية.
تحرير: @Sami_Syed يتم إلحاق رمز javascript:void(0) بالمسار عند النقر فوق رابط “تسجيل” في صفحة تسجيل الدخول. href هذا الرابط هو: \"javascript%3Avoid(0)\"
أعتقد أن ما يتم استخدامه هو جعل نموذج التسجيل على نفس المسار مثل نموذج تسجيل الدخول. شيء ما يحدث بشكل خاطئ معه على الرغم من ذلك. هل تعرف ما إذا كان هذا يعمل بشكل صحيح قبل تمكين DiscourseConnect؟
إذا كان المكون الإضافي المستخدم لنماذج تسجيل الدخول/التسجيل لديه خيار لجعل نموذج التسجيل يظهر على صفحة منفصلة، فإن تمكين ذلك يجب أن يعمل كحل سريع للمشكلة.
سأكون غير متصل بالإنترنت لمعظم اليوم، ولكن يمكنني محاولة المساعدة في هذا لاحقًا إذا كنت عالقًا.
تحرير: كنت في حيرة من أمري بشأن هذا، لذلك ألقيت نظرة أخرى. علامة التبويب “تسجيل” في نموذج تسجيل الدخول تعمل دون مشاكل. رابط “تسجيل” لديه المشكلة التي وصفتها أعلاه:
لذا فإن الحل السريع للمشكلة هو مجرد إزالة رابط التسجيل.
إعجابَين (2)
هذا صحيح.
نعم، تم تمكين هذا. السؤال هو، كيف يتمكنون حتى من تشغيل تسجيل دخول عبر FB أو Google الآن؟ صفحة تسجيل الدخول الحالية لدينا لا تحتوي على هذه الميزة.
أم أن هذا الخطأ يظهر لأولئك الذين سجلوا في الأصل باستخدام G أو FB ويحاولون الآن تسجيل الدخول ولكن لن يعمل؟
وإذا كان الأمر كذلك، فكيف يمكنني حلها؟
كما أرى، كان ذلك بسبب أنني لم أضع رابطًا صحيحًا هناك. عفوًا. اكتشاف جيد وشكراً لك!
لا أعرف ما الذي يمكن أن يؤدي إلى تشغيله. ربما تم تخزين عنوان URL لموفر المصادقة مؤقتًا بواسطة متصفحات المستخدم. هذا مجرد تخمين.
إعجاب واحد (1)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.