مؤخرًا، كنت أنا وفريقي نعمل على ميزة تسمح بتعديل اسم مستخدم Discourse الخاص بالمستخدم من WordPress مع تثبيت إضافة WP Discourse وتعيين موقع WordPress الخاص بنا كموفر SSO لـ Discourse. حاليًا، حققنا بعض النجاح باستخدام واجهة برمجة تطبيقات Discourse، حيث لدينا حقل بيانات تعريف مخصص في WordPress يقوم، عند تحديثه، باستدعاء مثيل Discourse الخاص بموقعنا بطلب PUT لتحديث اسم المستخدم الخاص بالمستخدم (على غرار الحل المقترح هنا: How does one change a username via the API?)
ومع ذلك، هناك خيار موجود ضمن WP Discourse كما هو موضح هنا:
ولكن هذا الحقل يُستخدم فقط لنشر المشاركات (من WP إلى Discourse) ولا يقوم فعليًا بتحديث اسم مستخدم المستخدم في Discourse. تتم المزامنة عندما يغير المستخدم اسم المستخدم الخاص به في Discourse، ولكنه لا تتم المزامنة من WordPress إلى Discourse عند تغييره.
سؤالي هو، هل سيتم تنفيذ هذا النوع من المزامنة ثنائية الاتجاه في وقت ما؟ لماذا يوجد خيار للسماح للمستخدمين بتغيير حقل اسم المستخدم هذا إذا لم تتم مزامنته من WordPress إلى Discourse؟ سيكون فريقنا مهتمًا أيضًا بالمساهمة في هذه الميزة إذا لم تكن شيئًا قيد العمل بالفعل. يحتاج موقعنا إلى هذه الوظيفة، ونتخيل أنها ستكون مفيدة لجميع مواقع WP Discourse أيضًا. يرجى إعلامي بهذا!
@angus@simon نظرًا لأنكما تشاركان بشكل كبير في WP Discourse وساعدتمانا في مشكلات SSO الخاصة بنا، أعتقد أنه يجب توجيه هذا السؤال إليكما!
لقد نقلت هذا الموضوع إلى فئة #support:wordpress، لأن فئة Contribute > Feature مخصصة لميزات Discourse.
قد يكون حقل “اسم مستخدم Discourse القابل للتعديل” في إضافة WordPress سيئ التسمية. بالتأكيد يحتاج نص الإعداد إلى التحديث ليكون واضحًا بشأن الغرض منه. عند تفعيل إعداد “اسم مستخدم Discourse القابل للتعديل”، يمكن للمستخدمين في موقع WordPress تعيين اسم مستخدم Discourse الخاص بهم في صفحة ملفهم الشخصي في WordPress. إذا لم يتم تفعيل هذا الإعداد، فيمكن فقط لمسؤول موقع WordPress تعيين اسم مستخدم Discourse للمستخدم. يُستخدم اسم مستخدم Discourse بواسطة الإضافة فقط لنشر المنشورات من WordPress إلى Discourse.
عند استخدام DiscourseConnect بين WordPress وDiscourse، يتم تعيين اسم مستخدم Discourse الخاص بالمستخدم في البداية بناءً على اسم مستخدم WordPress الخاص به. إذا كان الإعداد auth_overrides_username مفعّلاً في موقع Discourse، فيمكن تعيين اسم المستخدم في Discourse فقط من WordPress. إذا لم يكن إعداد auth overrides username مفعّلاً في Discourse، فقد يقوم المستخدمون بتعديل اسم المستخدم الخاص بهم في Discourse، مما قد يؤدي إلى عدم تزامن أسماء المستخدمين بين النظامين.
بالنسبة لحقل اسم مستخدم Discourse، من المثالي أن يتم تعيين هذا الحقل دائمًا في الخلفية بناءً على اسم مستخدم Discourse. لقد مضى وقت طويل منذ أن نظرت إلى الكود ذي الصلة آخر مرة، لكنني أعتقد أن حقل اسم مستخدم Discourse يتم ملؤه تلقائيًا إذا تم استخدام موقع WordPress كموفر SSO لـ Discourse وخيار “إنشاء أو مزامنة مستخدمين Discourse عند تسجيل الدخول” مفعّلاً في تبويب خيارات مزود DiscourseConnect في WordPress. يتم أيضًا تعيين حقل اسم مستخدم Discourse تلقائيًا إذا تم استخدام Discourse كموفر SSO لـ WordPress (باستخدام إعداد DiscourseConnect Client).
من المثالي أن يتم تعيين حقل اسم مستخدم Discourse تلقائيًا دائمًا عندما يكون WordPress هو موفر SSO لـ Discourse، سواء كان خيار “إنشاء أو مزامنة مستخدمين Discourse عند تسجيل الدخول” مفعّلاً في Discourse أم لا. لا أعتقد أنه يمكن فعل أي شيء في الحالة التي لا يتم فيها استخدام DiscourseConnect بين الموقعين، لكن @angوس قد يكون لديه أفكار حول ذلك.
بشكل افتراضي، لا يسمح WordPress للمستخدمين بتغيير أسماء المستخدمين الخاصة بهم، لذلك لم يكن لدينا الكثير من الأسئلة حول هذا الموضوع. إذا كنت تريد ضمان بقاء أسماء المستخدمين متزامنة بين WordPress وDiscourse، فتأكد من تفعيل الإعداد auth_overrides_username في Discourse. قد ترغب أيضًا في تفعيل خيار “إنشاء أو مزامنة مستخدمين Discourse عند تسجيل الدخول” في WordPress. مع تفعيل هذا الخيار، سيتم تحديث المستخدمين في Discourse في كل مرة يسجلون فيها الدخول إلى موقع WordPress الخاص بك. إذا لم يتم تفعيل هذا الخيار، فسيتم تحديث المستخدمين في Discourse فقط عند تسجيل خروجهم من Discourse، ثم تسجيل الدخول مرة أخرى باستخدام DiscourseConnect.
قد يكون موقعنا حالة خاصة بعض الشيء، لأننا لا نريد مزامنة اسم مستخدم ووردبريس مع ديسكورس تحديداً لأن ووردبريس لا يسمح للمستخدمين بتغيير أسماء المستخدمين افتراضياً. ولا نريد تثبيت إضافة تضيف وظيفة تعديل اسم مستخدم ووردبريس هذه بسبب عدم الاستقرار الذي قد تحدثه.
ولكن بما أن أسماء المستخدمين قابلة للتعديل في ديسكورس، أعتقد أنه سيكون من المنطقي توسيع هذه الوظيفة إلى ووردبريس عبر إضافة WP Discourse. يبدو هذا الحقل هو المكان المثالي لذلك، ولكني أتفهم أنه قد يتعارض مع اسم مستخدم ووردبريس نظراً لأنه لن يتغير أبداً افتراضياً. لذا أفترض أن هذا ليس شيئاً تريد منا المساهمة به في الإضافة؟
بالإضافة إلى ذلك، فإن السماح للمستخدمين بتعديل اسم المستخدم الخاص بهم في المنتدى هو مطلب رئيسي بالنسبة لنا. لدينا بالفعل Discourse مُعد للسماح بذلك، ولكن معظم مستخدمينا لا يغيرون اسم مستخدم Discourse الخاص بهم لأنه مخفي ضمن إعدادات Discourse. نريد أن يكون في مكان واضح في صفحة ملفهم الشخصي على موقع Wordpress الخاص بنا، جنبًا إلى جنب مع معلوماتهم الأخرى مثل الاسم والصورة الرمزية وما إلى ذلك.
ولكنها ستكون متطابقة عند التسجيلات الجديدة، حيث أنك تستخدم DiscourseConnect. أفترض أنك موافق على ذلك، وأنك قلق بشأن المزامنة بحد ذاتها (أي بعد إنشاء الحساب)؟
كيف تتصور الحالة التي ينشئ فيها المستخدم حساب ووردبريس ولم يسجل الدخول إلى Discourse بعد؟ لن يكون هناك حساب Discourse موجود. في هذه الحالة، لن يكون حقل اسم مستخدم Discourse قابلاً للتحرير؟
لاحظ أن خطاف الويب “تحديث بيانات المستخدم” (انظر “خطافات الويب” في إعدادات WP Discourse) سيقوم بتحديث اسم مستخدم Discourse في ووردبريس عند تغييره في Discourse. هذا هو أحد أجزاء المزامنة ثنائية الاتجاه التي تتصورها.
إذًا، هل ما تريده تحديدًا هو أن يقوم المكون الإضافي WP Discourse بتحديث اسم مستخدم Discourse للمستخدم عند تغييره، نعم؟
الآن، يستخدم هذا الحقل من قبل أشخاص مختلفين لأغراض مختلفة. يرغب بعض الأشخاص في أن يكونوا قادرين على تحرير هذا الحقل دون تحديث اسم مستخدم مستخدم Discourse المرتبط بالحساب الذي يستخدمونه مع DiscourseConnect.
ومع ذلك، هناك حل بسيط نسبيًا. يمكننا فقط إضافة action في مكان ما حول هنا حتى تتمكن من استخدام طلب PUT إلى Discourse لتحديث اسم المستخدم على Discourse، أي كما تفعل الآن. سأضيف فقط أن الطريقة السهلة للقيام بذلك هي استخدام طريقة discourse_request المجردة في أدوات المكون الإضافي WP، أي
use WPDiscourse\\Utilities\\Utilities as DiscourseUtilities;
$path = ''
$args = array(
);
$response = DiscourseUtilities::discourse_request( $path, $args );
باستخدام كل من خطاف الويب ودالة رد النداء للإجراء، سيكون لديك مزامنة ثنائية الاتجاه بالطريقة التي تتصورها، بافتراض أنك قد أخذت في الاعتبار السؤالين اللذين طرحتهما أعلاه.
يسعدني مراجعة ودمج طلب سحب (PR) مع إجراء إضافي في هذا الاتجاه.
نحن في الواقع نتجاوز هذا السلوك باستخدام خطاف التصفية wpdc_sso_params لأن نظام تسجيل الدخول الأحادي الخاص بنا يدمج Firebase واسم مستخدم WP الافتراضي للجميع هو معرف Firebase الخاص بهم، لذلك نقوم بتغيير افتراضي Discourse إلى memberXXX (مع XXX كرقم). نريد في الواقع تغيير هذا الافتراضي إلى Firstname_Lastname الخاص بالمستخدم في وقت ما أيضًا. ولكن نعم، قلقنا الأساسي هو قدرة المستخدمين على تغيير اسم المستخدم الخاص بهم بسهولة عبر صفحة ملفهم الشخصي داخل موقع Wordpress الخاص بنا.
في هذه الحالة، أعتقد أنه يمكننا إما تخزين حقل اسم المستخدم وجعله يتزامن عند إنشاء الحساب (عبر خطاف التصفية wpdc_sso_params عند أول تسجيل دخول أحادي)، أو يمكننا فرض إنشاء حساب Discourse لكل عضو عند التسجيل في موقع Wordpress الخاص بنا عبر واجهة برمجة تطبيقات Discourse. الخيار الثاني سيكون على الأرجح أكثر فائدة لأننا سنعرف أن الجميع لديهم حساب Discourse وبالتالي سيكون هناك حالات خاصة أقل لبعض المستخدمين الذين لديهم حسابات والبعض الآخر لا. لكننا نسعى حقًا لتجربة سلسة، لذا نريد أن يكون هذا الاسم هو ما يفكر فيه المستخدم كاسم مستخدم لمنصتنا بأكملها. نريد أن يكون قابلاً للتحرير دائمًا، وفي المستقبل ربما نستخدمه لأكثر من مجرد Discourse (أي في لوحات الصدارة، وما إلى ذلك).
نعم، هذا بالضبط ما نحتاجه!
مفهوم! شكراً على هذا التوجيه، سأعمل أنا وفريقي على اختبار هذا مع تطبيقنا أولاً وسنقدم طلب سحب (PR) قريبًا!
