ربط WP Discourse مع نسخة معينة من Discourse محلية

لقد حاولت للتو تثبيت هذه الإضافة على WordPress 6.7.2 مع php-fpm-8.3.17-1.fc41.x86_64، لكنها لا تعمل. أحصل على الخطأ التالي في السجل عند النقر فوق “حفظ الخيارات”.

[2025-02-21 17:15:13] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"An invalid response was returned from Discourse","http_code":"","http_body":""} 

توجد أخطاء مقابلة في /var/log/php-fpm/www-error.log:

[21-Feb-2025 17:14:42 UTC] PHP Warning:  Undefined array key "url" in /wordpress/wp-content/plugins/wp-discourse/lib/discourse.php on line 301

أرى أن نفس الخطأ يتم الإبلاغ عنه في “اختبار الدخان” على Report - WP-Discourse 2.5.9 - PluginTests.com.

تعديل: لا تقلق بشأن خطأ عنوان URL غير المحدد. يبدو أن هذا كان مجرد خطأ أولي من قبل اكتمال نموذج الويب. ومع ذلك، ما زلت أحصل على خطأ wpdc_response_error بشكل متكرر، في كل مرة أنقر فيها فوق زر “حفظ الخيارات”.

تعديل2: أرى خطأ 403 ممنوع على جانب Discourse، لكن ليس من الواضح لي سبب منع الاتصال من موقع WordPress الخاص بي. يمكنني استخدام نفس مفتاح API بنجاح مع curl.

Completed 403 Forbidden in 33ms (Views: 0.3ms | ActiveRecord: 15.1ms (2 queries, 0 cached) | GC: 2.2ms)

أقوم بتشغيل Discourse 3.5.0.beta1-dev في وضع التطوير.

تعديل3: وجدت أن هناك أذونات WordPress خاصة لمفتاح API في هذا الإصدار من Discourse. استخدام “Granular” بدلاً من “Global” وتحديد مربعات الاختيار تحت WordPress أزال أخطاء 403 Forbidden. ومع ذلك، ما زلت أحصل على ردود فارغة/غير صالحة يتم إرسالها إلى WordPress.

Delivering messages [] to client d9fbb33f11ed404bbc361c459802c87d for user 1 (chunked)

أعتقد أنني بحاجة إلى استخدام إصدار أقدم من Discourse مع إضافة WordPress. ما هو أحدث إصدار يعمل معه؟

مرحباً @Gregory_Bartholomew، دعنا نرى ما إذا كان بإمكاننا الوصول إلى جوهر مشكلتك.

إنه يعمل مع أحدث إصدار من Discourse.

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

قبل محاولة استخدام مفتاح بأذونات دقيقة، هل يمكنك المحاولة باستخدام مفتاح عام كما هو موضح في الفيديو في المنشور الأول؟

شكرًا. أحاول إعادة تثبيت Discourse الآن. لقد قمت بسحب الإصدار 3.3.0 للاختبار.

أحاول تثبيت Discourse محليًا بدلاً من استخدام حاوية Docker بسبب خطأ في ZFS يمنع حاوية Docker من البناء بنجاح على أنظمة ملفات ZFS (مشكلة pnpm 7024). إذا قمت بتثبيت Discourse محليًا، يمكنني تجاوز خطأ ZFS عن طريق إضافة package-import-method=hardlink إلى .npmrc قبل تشغيل pnpm install.

أعني أنني كنت أستخدم RAILS_ENV=development. سأحاول مرة أخرى باستخدام RAILS_ENV=production الآن.

أيضًا، أحاول إعادة صياغة الدليل الذي ربطته أعلاه ليعمل على Fedora Linux.

تعديل: لا أحقق الكثير من النجاح مع الإصدار 3.3.0.

$ pnpm install
 WARN  حقل "workspaces" في package.json غير مدعوم بواسطة pnpm. قم بإنشاء ملف "pnpm-workspace.yaml" بدلاً من ذلك.
 ERR_PNPM_INVALID_SELECTOR  لا يمكن تحليل المحدد "**/unset-value"

أعتقد أنني سأحاول مرة أخرى مع 3.4.0 وأرى كيف يسير الأمر. :confused:

حسنًا، لقد أعدت تثبيت Discourse بالإصدار 3.4.0:

ومع ذلك، لم أتمكن من تشغيله في وضع الإنتاج. لست متأكدًا من السبب. لقد عرض فقط “عفوًا…” ولم يكن هناك الكثير مما يمكنني رؤيته في السجلات. أعتقد أن المشكلة ربما كانت تتعلق ببعض إعدادات الوكيل، لكنني لست متأكدًا.

على أي حال، قمت بإعادة تعيين RAILS_ENV إلى “development” وبدأ التشغيل. ومع ذلك، ما زلت أواجه نفس الخطأ عند محاولة الاتصال من WordPress:

[2025-02-21 22:11:06] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"An invalid response was returned from Discourse","http_code":"","http_body":""} 

يمكنني رؤية الاستعلامات تصل إلى Discourse، لذا لا أفهم لماذا لا يعمل.

GET "/site.json" for 000.123.456.789 at 2025-02-21 16:11:05 -0600
10:11 pm
Processing by SiteController#site as JSON
10:11 pm
ApiKey Load (9.0ms) SELECT "api_keys".* FROM "api_keys" WHERE (revoked_at IS NULL) AND "api_keys"."key_hash" = '3f27a89fedae42123b9ad596fae6c06d36748f53bd241213941083af49cf5e46' ORDER BY "api_keys"
10:11 pm
ApiKeyScope Load (10.6ms) SELECT "api_key_scopes".* FROM "api_key_scopes" WHERE "api_key_scopes"."api_key_id" = 1
10:11 pm
User Load (8.1ms) SELECT "users"."id", "users"."username", "users"."created_at", "users"."updated_at", "users"."name", "users"."last_posted_at", "users"."active", "users"."username_lower", "users".
10:11 pm
UserOption Load (6.1ms) SELECT "user_options"."user_id", "user_options"."mailing_list_mode", "user_options"."email_digests", "user_options"."external_links_in_new_tab", "user_options"."enable_quoti
10:11 pm
Group Load (8.6ms) SELECT "groups"."id", "groups"."name", "groups"."flair_icon", "groups"."flair_upload_id", "groups"."flair_bg_color", "groups"."flair_color" FROM "groups" ORDER BY groups.name ASC
10:11 pm
(7.0ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."read_restricted" = FALSE
10:11 pm
(10.7ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."read_restricted" = TRUE
10:11 pm
Topic Count (4.1ms) SELECT COUNT(*) FROM (SELECT 1 AS one FROM "topics" WHERE "topics"."deleted_at" IS NULL LIMIT 16) subquery_for_count
10:11 pm
(6.1ms) SELECT "users"."id" FROM "users" INNER JOIN "user_auth_tokens" ON "user_auth_tokens"."user_id" = "users"."id" WHERE "users"."admin" = TRUE AND (users.id > 0) ORDER BY user_auth_tokens.crea
10:11 pm
(8.5ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."topic_featured_link_allowed" = TRUE
10:11 pm
ColorScheme Load (6.8ms) SELECT "color_schemes".* FROM "color_schemes" WHERE (color_schemes.id NOT IN (SELECT color_scheme_id FROM theme_color_schemes)) AND "color_schemes"."id" = 1 LIMIT 1
10:11 pm
ColorSchemeColor Load (7.8ms) SELECT "color_scheme_colors".* FROM "color_scheme_colors" WHERE "color_scheme_colors"."color_scheme_id" = 1 ORDER BY id ASC
10:11 pm
(6.0ms) SELECT "group_users"."group_id" FROM "group_users" WHERE "group_users"."user_id" = -1
10:11 pm
(8.0ms) SELECT "category_users"."category_id", "category_users"."notification_level" FROM "category_users" WHERE "category_users"."user_id" = -1
10:11 pm
UserField Load (9.5ms) SELECT "user_fields"."id", "user_fields"."name", "user_fields"."created_at", "user_fields"."updated_at", "user_fields"."editable", "user_fields"."description", "user_fields".
10:11 pm
Completed 200 OK in 256ms (Views: 0.3ms | ActiveRecord: 116.4ms (15 queries, 0 cached) | GC: 94.6ms)

أعتقد أنني سآخذ استراحة من هذا الأمر لفترة، ولكن إذا كان لديك أي فكرة عما قد يكون خاطئًا، فسأكون ممتنًا لبعض التلميحات. :slightly_smiling_face:

لقد نقلت هذه المحادثة إلى موضوع مستقل نظرًا لأن المشكلات التي تتعامل معها قد تربك الآخرين الذين يقومون بتشغيل إعدادات قياسية.

حسنًا ، للملخص ،

  1. أنت تقوم بتشغيل Discourse على جهازك المحلي.
  2. أنت تقوم بتشغيل إصدارات محددة. أنت حاليًا تقوم بتشغيل 3.4.0.
  3. أنت تحاول ربط نسختك المحلية بنسخة WordPress عن بُعد.

هل أي من ذلك غير صحيح؟ أيضًا ، هل يمكنك توضيح ما يلي:

  1. كيف تتصل بنسخة WordPress عن بُعد من جهازك المحلي؟ هل تستخدم ngrok؟
  2. لماذا تقوم بتشغيل إصدارات محددة من Discourse بدلاً من أحدث إصدار؟
  3. ما هو هدفك العام هنا؟
إعجابَين (2)

نعم.

نعم.

نسخة WordPress التجريبية الخاصة بي تعمل أيضًا محليًا.

لا، كل شيء محلي. لدي نسختان من httpd تعملان وتستمعان على عناوين IP مختلفة (واحدة لـ WordPress والأخرى لـ Discourse). نسخة WordPress تعمل مباشرة على نظامي الأساسي ونسخة Discourse تعمل في حاوية systemd-nspawn. كلا النظامين الأساسيين والحاوية يعملان بنظام Fedora Linux 41.

لقد جربت نسخة Docker في البداية، لكنها لم تُبنَ على جهاز الاختبار الخاص بي. أدى البحث عن رسالة الخطأ إلى تقرير خطأ مفتوح يشير إلى أن المشكلة كانت مع نظام ملفات ZFS. لا أعرف كيفية تعديل صورة Docker لتطبيق الحل البديل، لذلك وجدت تعليمات لنسخ المستودع المصدر وبناء Discourse بذلك.

في البداية قمت ببناء أحدث إصدار (3.5.0.beta1-dev)، لكن السلوك بدا مختلفًا عما كان يعرضه الفيديو الخاص بك. كنت أرى خطأ 403 Forbidden في سجلات Discourse عندما حاولت WordPress الاتصال بمفتاح API (عندما تم تعيين الأذونات على “عام”). تغيير الأذونات إلى “مفصل” وتحديد جميع مربعات WordPress سمح للاستعلامات بالمتابعة، لكن WordPress كان يتلقى استجابات فارغة/غير صالحة. لاحظت بعد ذلك على https://blog.discourse.org/ أن أحدث إصدار يتم الترويج له هو 3.4، لذلك استنتجت أن بعض المشاكل التي كنت أواجهها ربما كانت بسبب محاولتي تشغيل إصدار ما قبل الإصدار. جربت git checkout v3.3.0 معتقدًا أنه سيكون قديمًا بما يكفي ليكون متوافقًا تمامًا مع إضافة WordPress التي أحاول اختبارها، لكنه لم يُبنَ على نظامي، لذلك قمت بفحص الإصدار 3.4.0 ويبدو أنه يعمل (وإن كان في وضع “التطوير”).

في الواقع، أريد فقط تجربة والتعرف على إضافة WordPress Discourse. أنا لا أهتم بـ Discourse على الإطلاق. أنا فقط بحاجة إلى شيء للاختبار. بمجرد أن أشعر بالراحة مع كيفية عمل كل شيء، قد أحاول تثبيت الإضافة على موقع إنتاجي (fedoramagazine.org) وإعادة توجيه التعليقات إلى نسخة Discourse الإنتاجية على discussion.fedoraproject.org.

إعجاب واحد (1)

هذا هو أتعس شيء قرأته على هذا المنتدى على الإطلاق! :lolsob:

إعجاب واحد (1)

ستكون المشكلة متعلقة بإعداداتك المحلية وشبكتك. لن تكون بسبب إصدار Discourse، أو الاختلاف بين المفاتيح العامة والمفصلة. سيكون من الصعب عليّ تصحيح مشكلات الاتصال المتبادل لتطبيقك المحلي، خاصةً بسبب تنوع الطرق والبيئات التي يمكنك من خلالها تشغيل كل من Wordpress و Discourse محليًا. إليك بعض النصائح لمساعدتك.

  1. قم دائمًا بتشغيل أحدث إصدار من Discourse و Wordpress ومكون WordPress الإضافي Discourse.
  2. استخدم المنفذ 3000 بدلاً من المنفذ 4200 في عنوان URL المحلي لـ Discourse في WP Discourse.
  3. تأكد من أن المفتاح الذي تنشئه يمكن استخدامه بواسطة اسم المستخدم الإداري الذي قمت بتعيينه كاسم مستخدم النشر.

هذا ما تبدو عليه إعداداتي المحلية مع اتصال Wordpress و Discourse المحليين ببعضهما البعض. أستخدم MAMP Pro لتشغيل Wordpress محليًا.


3 إعجابات

لقد نجح الأمر!!!

شكرًا لك على النصيحة بشأن الاتصال مباشرة بالمنفذ 3000. يبدو أن هذا هو ما أحدث الفرق.

شيء واحد جدير بالملاحظة (على الأقل في تكويني المحلي) هو أنني احتجت أيضًا إلى تعيين ALLOW_EMBER_CLI_PROXY_BYPASS=1 قبل بدء ember-cli.

3 إعجابات