نحن نضيف القدرة للمستخدمين على ضبط منطقتهم الزمنية في ووردبريس بحيث يعرض نشاطهم الخاص على موقعنا بالوقت المحلي. أثناء قيامنا بذلك، اعتقدنا أنه يمكننا جعل هذا الإعداد يتدفق أيضًا إلى المنتدى، حتى لا يضطروا إلى إجراء نفس الإعداد مرتين. حاليًا، يقوم المستخدمون على ديسكورس بتعيين موقعهم ومنطقتهم الزمنية الخاصة تحت التفضيلات/الملف الشخصي، لذا نود تجاوز ذلك إذا أمكن.
يبدو أن هناك إعداد DiscourseConnect ضمن “site_settings/category/login” يسمى “discourse connect overrides location”. هل هذا فقط لحقل “الموقع”، أم أنه يعتني بالمنطقة الزمنية أيضًا؟ عند تحديد هذا المربع، من أين يسحب DiscourseConnect هذه المعلومات في قاعدة بيانات ووردبريس؟
على سبيل المثال: إذا قمنا بتطبيق إعداد مماثل خاص بنا، فنحن نريد التأكد من تخزينه في المكان الصحيح حتى يتدفق بشكل صحيح عبر DiscourseConnect عند تشغيل خيار “الموقع”.
بعد المزيد من البحث في هذا الأمر، سأفترض أن تحديد خيار “تجاوز الموقع” في DiscourseConnect لا يأخذ إعداد المنطقة الزمنية من ووردبريس، وأنه إذا أردنا ذلك، فإن أفضل طريقة ستكون تعيينه عبر واجهة برمجة التطبيقات (API) في كل مرة يقوم فيها المستخدم بتعديل تلك المعلومات. أخبرني إذا كان هذا صحيحًا.
ومع ذلك، ما زلت غير متأكد من مصدر “الموقع” من جانب ووردبريس، أو حتى ما إذا كان يتم نقله. لا أرى رمز “الموقع” في “الحمولة الأخيرة” لمستخدمي، على سبيل المثال. لكنني أرى الصورة الرمزية، والسيرة الذاتية، واسم المستخدم، والمعرف الخارجي، وما إلى ذلك. والجدير بالذكر أن السيرة الذاتية يتم نقلها حتى لو لم يكن لدينا “تجاوز السيرة الذاتية” قيد التشغيل، لذا يفترض أن “الموقع” يجب أن يتم نقله أيضًا؟
إذا كان لديك ثانية يا @simon، أعتقد أنك ساحر الإضافات. أخبرني إذا كان لديك أي رؤى. شكرًا لك!
مرحباً @troygrady، آسف على الرد البطيء (أنا أجيب على الأسئلة المتعلقة بمكون WP Discourse الإضافي). سأتناول إعدادات المنطقة الزمنية والموقع بشكل منفصل (فهما غير مترابطين).
المنطقة الزمنية
هل يمكنك فقط توضيح ما إذا كنت تقصد أن نشاط المستخدم يجب أن يُعرض له بالوقت المحلي الخاص به؟ إذا كان الأمر كذلك، فعلى عكس ووردبريس، هذا هو الوضع الافتراضي حاليًا في Discourse (بدون أي استخدام لـ DiscourseConnect)، وسيتم تحديثه تلقائيًا إذا لم يقم المستخدم بتعيينه. على سبيل المثال، انتقلت مؤخرًا من المنطقة الزمنية Australia/Perth إلى Europe/Oslo. لم ألمس إعداد المنطقة الزمنية في ملفي الشخصي هنا على meta، وهو يقرأ الآن
يمكنك مزامنة موقع تم تعيينه في ملف تعريف مستخدم ووردبريس مع حقل الموقع في ملف تعريف المستخدم على Discourse. لا تتم المزامنة افتراضيًا لأنه لا يوجد حقل قياسي في ووردبريس يعادل حقل الموقع في Discourse. تحتاج إلى إضافة بعض التعليمات البرمجية هنا. في ملف functions.php الخاص بالسمة الخاصة بك أو في مكان آخر يمكنك إضافة تعليمات برمجية، تحتاج إلى إضافة شيء مثل ما يلي، مع استخدام الجزء الرئيسي لـ wpdc_sso_params filter.
لاحظ أنك ستحتاج إلى استبدال ‘user_location_meta’ بأي حقل بيانات تعريف المستخدم يتم استخدامه لتخزين موقع المستخدم في مثيل ووردبريس الخاص بك (أي أي حقل يستخدمه المكون الإضافي الذي تستخدمه لإضافة مواقع المستخدمين إلى ووردبريس).
لاحظ أيضًا أن حقل الموقع في Discourse هو مجرد حقل “سلسلة نصية”، مما يعني أنه سيعرض ببساطة أي شيء يتم وضعه فيه حرفيًا. ليس له أي تأثير على المنطقة الزمنية للمستخدم وليس تحديد موقع جغرافي (أي مرتبط بالخرائط بأي شكل من الأشكال).
آسف على الارتباك! نعم، المنطقة الزمنية المحلية، ونعم، السلوك القياسي لـ Discourse رائع. كما تشير، ليست Discourse هي المشكلة، بل WP التي لا تملك القدرة على السماح للمستخدمين برؤية الموقع في منطقتهم الزمنية المحلية. هذا ما نريد إضافته. إذا سمحنا للمستخدم بتعيين منطقته الزمنية، فقد فكرت في أنه يجب علينا أيضًا أن نجعل هذا الإعداد يتجاوز إعداد Discourse بحيث يكونان متزامنين. هذا ما أردت معرفته مما إذا كان DiscourseConnect يوفره. يبدو أنه لا يفعل.
ما لم أدركه هو أن إعداد Discourse تلقائي. إذا كان الأمر كذلك، فقد نتركه كما هو. أي، تنفيذ المنطقة الزمنية المحلية في WP، وعدم جعل هذه القيمة تتجاوز قيمة Discourse. نعم، قد يخرجان عن التزامن، ولكن قد لا يكون ذلك مشكلة كبيرة لمعظم المستخدمين.
ممتاز، هذه هي المعلومة المفقودة - لم أكن أعرف من أين يفترض أن يحصل DiscourseConnect على بيانات الموقع من جانب WP. لقد قمنا بتنفيذ حقل موقع خاص بنا يدويًا، في usermeta، لذلك يمكننا فقط سحب القيمة من هناك باستخدام خطاف wpdc_sso_params.
أنا غبي، لذلك ربما أغفلت ذلك. هل توجد وثائق لـ wpdc_sso_params في أي مكان؟ لقد وجدت هذا الموضوع، والذي يبدو أنه يغطيه في الوقت الحالي:
لا، لا يمكنك تعيين المناطق الزمنية عبر DiscourseConnect، وأوصي بعدم محاولة القيام بذلك أيضًا، حيث أن قابلية نقل المناطق الزمنية عبر الأنظمة الأساسية/المعايير هي حقل ألغام إلى حد ما (هناك قوائم متعددة “قياسية” للمناطق الزمنية مع اختلافات طفيفة).
ليس بمعنى منظم. أنا بصدد إعادة هيكلة جميع وثائق WP Discourse وسأقوم بنشر قائمة شاملة بالإجراءات والتصفية
لا مشكلة.\n\nفيما يتعلق بـ wpdc_sso_params، نود تضمين رابط لصفحة المنصة الرئيسية للمستخدم وعرضه على بطاقته. يبدو أنه يمكنني إعداد ذلك كحقل مخصص ثم تمريره عبر خطاف مشابه. لكنني أريد أن يكون ذلك لاستخدامنا الداخلي، أي أنني لا أريد فعليًا أن يظهر كشيء يمكن للمستخدم تعديله. نظرًا لأننا نتحكم في جميع عمليات التسجيل على ووردبريس، ويتم التعامل مع حساب المنتدى تلقائيًا، فهل من المحتمل أن يحل ذلك المشكلة؟ أي، نقوم بإنشاء الحقل المخصص، ونضبطه على أنه غير قابل للتعديل بعد الإنشاء، ثم نقوم فقط بتحديثه عبر sso بعد ذلك. لن يرى المستخدم أبدًا مربع تحرير في أي مكان؟
وجود حقل مخصص في ووردبريس يحتوي على “الصفحة الرئيسية لمنصة المستخدم”
تمرير الحقل المخصص إلى ديسكورس باستخدام فلتر wpdc_sso_paramsكما هو موضح هنا.
عرض الحقل المخصص في ديسكورس على بطاقة المستخدم وعدم السماح للمستخدم بتعديله في ملفه الشخصي في ديسكورس (مع ترك “قابل للتعديل بعد التسجيل” غير محدد).
إذا كان هذا صحيحًا، فيجب أن يعمل ذلك، بافتراض أنه لا يوجد لديك أي مربع تعديل للحقل المخصص في ووردبريس نفسه.
ملاحظة فقط أن الموظفين يمكنهم دائمًا تعديل حقول المستخدم (أي الحقول المخصصة)، حتى لو لم تحدد “قابل للتعديل بعد التسجيل”. لرؤية هذا أثناء العمل، ستحتاج إلى اختباره بحساب غير موظف.
نعم، هذا بالضبط ما نريد القيام به.
المشكلة هي أنه يبدو أن حقول المستخدم المخصصة تظهر دائمًا على أنها قابلة للتحرير في نموذج تسجيل مستخدمي Discourse، حتى لو لم تكن تنوي أبدًا أن يتمكن المستخدمون من الوصول إليها. لا نريد أبدًا أن يقوم المستخدمون بتحرير عنوان URL لصفحتهم الرئيسية على المنصة نظرًا لأنه يتم إنشاؤه تلقائيًا بواسطة النظام. ومع ذلك، نظرًا لأن مستخدمينا لا يرون أبدًا نموذج تسجيل Discourse، فقد يكون هذا غير ذي صلة.
بوضع هذا بطريقة أخرى، هل هناك طريقة لإنشاء حقول مخصصة للاستخدام الداخلي فقط، أي أنها لا تظهر أبدًا في أي نوع من النماذج القابلة للتحرير من قبل المستخدم في Discourse؟ أتخيل أن هناك العديد من الاستخدامات المحتملة لهذا من حيث دمج بيانات WP أو المنصات الخارجية الأخرى في عروض Discourse.
نعم، ولكنها لن تظهر تلقائيًا في بطاقة المستخدم، وهي المكان الذي تريد عرض البيانات فيه، أليس كذلك؟ ومع ذلك، إذا كان هذا ما تريده، يمكنك فقط إضافة أي حقل عشوائي في فلتر wpdc_sso_params، على سبيل المثال:
سيتم تخزين هذا في Discourse في جدول قاعدة البيانات user_custom_fields، ولكنه لن يكون مرئيًا في أي مكان. يمكنك الاستعلام عنه باستخدام إضافة Data Explorer.
حسنًا، نود عرض حقول عشوائية في بطاقة المستخدم، تم إنشاؤها بواسطة WP، تتعلق بحساب المستخدم على الموقع الرئيسي - مثل عنوان URL لصفحته الرئيسية، وربما حقول أخرى أيضًا. لا يُقصد أبدًا أن يتم توفيرها من قبل المستخدم، حتى أثناء إنشاء الحساب. إنها مُعدة للعرض فقط. في حالتنا، يبدو أن حقل “مستخدم” مخصص هو النهج الأفضل لأنه يتضمن بالفعل خيارات عرض للملف الشخصي والبطاقة. والمستخدم لا يرى أبدًا نموذج تسجيل.
الحالة الاستثنائية ستكون إذا لم تكن تستخدم SSO - سيرى المستخدم تلك الحقول في نموذج التسجيل، على الرغم من أنه لا يُقصد منه ملؤها. أفترض أن الحل البديل سيكون مجرد إخفائها عبر CSS؟
على أي حال، في حالتنا، يبدو أن لدينا حلولنا هنا. شكرًا لك!
