يتسبب آخر تثبيت إضافي في إضافة WP-Discourse في إرجاع جميع المشاركات المخصصة (التي تم إنشاؤها عبر إضافة EventON) إلى المستخدم system على الرغم من وجود المستخدم في كل من Discourse و WordPress.
إذا قمنا بالرجوع إلى الإصدار 2.3.7، فإنه يعمل كما هو متوقع، ولكن التحديث إلى الإصدار 2.3.8 يتسبب في حدوث هذا الخطأ.
نتلقى هذا الخطأ عبر رسائل البريد الإلكتروني:
سبب الفشل:
تم إرجاع رمز استجابة 400 من Discourse.
المعلمة مفقودة أو القيمة فارغة: post
هل تقصد؟ post
post[raw]
controller
title
أعتقد أن هذا قد يكون مفيدًا في تحديد السبب المحتمل.
[2022-02-21 08:07:11] publish.INFO: create_post.post_success {"wp_title":"[Please Ignore] Test Event","wp_author_id":"3958","wp_post_id":126070,"discourse_post_id":""}
[2022-02-21 08:07:11] publish.INFO: create_post.body_valid {"wp_title":"[Please Ignore] Test Event","wp_author_id":"3958","wp_post_id":126070,"discourse_post_id":""}
تم ربط المنشور بشكل صحيح بحساب المستخدم الخاص بي على كل من ووردبريس و ديسكورس باستخدام الإصدار 2.3.7.
v2.3.8:
[2022-02-21 08:10:15] publish.INFO: create_post.post_success {"wp_title":"[Please Ignore] Another test event","wp_author_id":"3958","wp_post_id":126071,"discourse_post_id":""}
[2022-02-21 08:10:15] publish.INFO: create_post.body_valid {"wp_title":"[Please Ignore] Another test event","wp_author_id":"3958","wp_post_id":126071,"discourse_post_id":""}
تم ربط المنشور بالمستخدم الخاص بي على ووردبريس والمستخدم النظام على ديسكورس في الإصدار 2.3.8.
هل يمكنك تأكيد بعض الأشياء لي\n\n1. هل يتم نشر أنواع المنشورات المخصصة الخاصة بك (أي الأحداث) بنجاح إلى Discourse\n2. لم ترَ الخطأ 400 من قبل\n3. ما نوع المستخدمين (الذين تتوقع استخدام أسماء مستخدميهم في Discourse) الذين ينشرون المنشورات (أي هل هم مسؤولون أم لا)\n4. ما نوع مفتاح API الذي تستخدمه لربط Wordpress بـ Discourse
مرحباً @orenwolf، يؤسفني سماع أنك لا تزال تواجه مشكلة. هل يمكنك تأكيد أن المستخدمين الذين تتوقع أن يتم النشر باسمهم لديهم “اسم مستخدم Discourse” في ملفهم الشخصي على Wordpress؟
بشكل عام يا رفاق، شكراً لصبركم على هذا. في اختباري الخاص على مواقع مختلفة (وفي اختبارات الوحدة الخاصة بالمكون الإضافي)، تعمل ميزة “اسم مستخدم Discourse” الآن كما هو متوقع في “2.3.9”. إذا كنت لا تزال تواجه مشكلة، فيرجى التأكد من أنك تستخدم أحدث إصدار من المكون الإضافي وأن المستخدم الذي تتوقع أن يكون مؤلف المنشور لديه “اسم مستخدم Discourse”.
قد تتساءل لماذا نشأت هذه المشكلة على الإطلاق. أعتقد أنه سيكون من المفيد أن أقدم بعض الخلفية (والتي ستجيب أيضًا على سؤالك @itsbhanusharma). في السابق، كانت طريقة عمل هذه الميزة هي أنها تستخدم مستخدمين مختلفين في رأس “Api-Username” (انظر هنا). كان سبب اعتبار هذا ضروريًا هو أن نقطة النهاية ذات الصلة في Discourse لا تدعم تعيين منشئ للمنشور يختلف عن المستخدم الذي يقوم بطلب API.
كانت نتيجة ذلك أن الطريقة الوحيدة لعمل هذه الميزة هي إذا كان لديك مفتاح API “لجميع المستخدمين” بنطاق “عالمي”. سأشير فقط إلى أنه لبعض الوقت، كانت التعليمات القياسية لإنشاء مفتاح API لمكون Discourse الإضافي WP هي كما يلي:
إذا لم تكن قد أنشأت مفتاح API بعد، فانقر فوق “مفتاح API جديد”، واضبط مستوى المستخدم على “مستخدم واحد”، واضبط “المستخدم” على حساب مسؤول، وحدد “مفتاح عالمي” وانقر فوق “حفظ”. انسخ والصق مفتاح API هنا.
اتباع هذه التعليمات يعني أن هذه الميزة (غير الموثقة) لن تعمل، وقد تسببت في مشاكل لمواقع مختلفة.
علاوة على ذلك، ولأسباب أمنية مختلفة، قمت تدريجياً بإجراء تغييرات على المكون الإضافي للسماح باستخدام مفاتيح API أكثر تحديدًا. سيتطلب هذا تغييرًا في Discourse، (وعندما يتم دمجه) سيسمح لمسؤولي المكون الإضافي بإصدار مفتاح API جديد ومحدود للغاية لأنفسهم. سأقوم بإعلان عن ذلك عندما يحين الوقت.
نعم @itsbhanusharma، الطريقة التي تعمل بها الميزة الآن هي عن طريق إجراء طلب ثانٍ لتغيير مالك المنشور بعد إنشائه (إذا كان “اسم مستخدم Discourse” موجودًا). هذه هي في الواقع الطريقة الصحيحة الوحيدة لتعيين مالك منشور بشكل اعتباطي عبر Discourse API (دون الحاجة إلى استخدام Api-Username ومفتاح عالمي لجميع المستخدمين بالطريقة الموضحة أعلاه). بالنظر إلى نوع العملية هذه، لا ينبغي أن تكون مصدر قلق بشأن الأداء.
إنه ليس مصدر قلق بشأن الأداء، بل مجرد إزعاج لشرح الأشخاص الأقل خبرة أن أيقونة القلم الموجودة أعلى مشاركتهم طبيعية وأن هذا هو الحال.
سيستغرق الأمر بعض الوقت ولكن في النهاية سوف نعتاد عليه.
منفر قليلاً أن يتم عرض المشاركات على أنها معدلة، ولكن لا بأس طالما أن كل شيء يعمل.
ومع ذلك، فإن مشكلة أن الإشعارات خاطئة. إنها تعرض المنشور الجديد الذي تم إنشاؤه بواسطة مستخدم النظام.
حتى الآن، هذا يبدو وكأنه حل مؤقت، وليس حلاً. إنه بالتأكيد خطوة كبيرة إلى الوراء لعدم القدرة ببساطة على النشر كمستخدم مناسب تلقائيًا. لست متأكدًا من سبب تعطل هذا في المقام الأول.
الخلاصة هي أنني كنت أغير ببطء الطريقة التي يتعامل بها المكون الإضافي مع جميع طلباته إلى discourse لأسباب مختلفة، لا سيما الاختبار والأمان. السياق الكامل والمنطق وراء التغييرات طويل جدًا للدخول فيه هنا. أقدر أنه في سياق هذه الميزة المحددة قد يبدو الأمر وكأنه “إذا لم يكن مكسورًا فلا تصلحه”، ومع ذلك، هناك سياق أوسع هنا.
لقد استمرت هذه التغييرات لبعض الوقت (أشهر)، ومع ذلك، فإن السبب في ظهورها الآن هو أنني ارتكبت خطأ في إصدار 2.3.8. لذلك قمت بتضمين التغيير الذي كان يجب أن يكون في هذا الإصدار في 2.3.9.
ومع ذلك، @jtbayly@itsbhanusharma، أسمع ملاحظاتكم حول النهج المختلف لهذه الميزة المحددة. أفهم أنه قد يبدو وكأنه حل بديل. إنه ليس كذلك. ومع ذلك، نظرًا لملاحظاتكم، سأضيف الطريقة الحالية مرة أخرى إلى المكون الإضافي خلف إعداد يمكنك استخدامه إذا كنت ترغب في ذلك (سيتم طرحه في 2.4.0). سأتابع بملاحظة عندما يتم دمج ذلك في الأيام القليلة القادمة.
آمل أن أتمكن من إزالة هذا النهج بالكامل عندما أعالج المشكلات التي أثرتها، على الأرجح مع بعض التغييرات الإضافية على discourse/discourse. كما ذكرت، سأقوم بإعلان أكبر حول التغييرات في كيفية تعامل المكون الإضافي مع مفاتيح API خلال الشهر المقبل (اعتمادًا على وقت دمج التغييرات في discourse/discourse)، والتي ستغطي جوانب من هذا.
عندما قلت هذا، كان القصد منه الإقرار بأنني لم أكن متأكدًا مما إذا كانت هناك أي طريقة أخرى للمضي قدمًا. لم يكن المقصود أن يكون تعليقًا مثل “لماذا ذهبت وكسرته!”.
ممتن جدًا لعملك في الحفاظ على عمل المكون الإضافي لـ WP مع نواة Discourse المحدثة. وسعيد جدًا بوجود تغييرات (على الأرجح) قادمة إلى النواة ستسمح بالتحسين في هذا المجال.
