محاولة تجاوز التأخير لمدة 10 دقائق

[Lee_Ars]

أخطط لاستخدام المكون الإضافي wp-discourse على موقع تنبؤات الطقس على ساحل الخليج والذي يخدم عادةً حوالي 10-20 ألف مشاهدة للصفحة/اليوم، ولكنه في بعض الأحيان خلال أحداث الطقس القاسية قد يصل إلى 1.5-2 مليون مشاهدة للصفحة/اليوم لحوالي 500-700 ألف زائر. تم اختبار الموقع واستراتيجية الاستضافة الخاصة به في العديد من أحداث الطقس القاسية وتعمل الأمور بشكل رائع تحت الضغط، ويرجع ذلك أساسًا إلى التصميم الدقيق والكثير من المساعدة من Cloudflare.

اعتاد مستخدمو الموقع على تجربة تعليق منخفضة الاحتكاك عبر تعليقات ووردبريس الأصلية، لذلك سيكون هناك بعض التكيف (مثل تعويدهم على النقر على رابط “متابعة المناقشة في…”) الذي يكون الموظفون الذين يتعاملون مع المستخدمين مستعدين لإدارته.

ومع ذلك، فإن ما لن يتسامحوا معه هو التأخير المتغير لمدة 10 دقائق بين نشر التعليقات وظهورها على صفحة منشور ووردبريس اليومي. سيرغبون في ظهور التعليقات الجديدة (حتى الحد المحدد) فورًا على الصفحة الرئيسية عند نشرها، على غرار كيفية ظهور تعليقات WP الأصلية فورًا بعد نشرها.

بعد العبث بالخيارات المضمنة لمحاولة جعل المنشورات تظهر فورًا دون تداخل ذاكرة التخزين المؤقت لـ nginx’s fastcgi، أو ووردبريس، أو ذاكرة التخزين المؤقت للمتصفح مع ظهور التعليقات الجديدة عند التحديث بعد نشرها، أضفت المكونين الإضافيين التاليين للتخفيف من ذلك والتسبب في ظهور التعليقات المنشورة حديثًا على جانب ووردبريس عند التحديث:

wp-discourse-transient-killer.php
wp-discourse-cache-header-fix.php

لقد حل هذا مشكلتي: تظهر المنشورات الجديدة في سلاسل Discourse التي تم إنشاؤها بواسطة ووردبريس الآن أسفل منشورات ووردبريس فورًا عند التحديث.

لكنني على وشك الوصول إلى نهاية كفاءتي هنا - ما الذي أفسده / أضر به / قوضته بفعل هذا؟

لا يهمني بشكل خاص إنشاء حمل إضافي على مستضيف الويب الخاص بي من خلال تعرض نقطة نهاية التعليقات للقصف من قبل الزوار الذين يتحققون من صفحة توقعات الطقس اليومية (مع تعليقات Discourse المضمنة) - هذه مشكلة يمكنني حلها بإنفاق المال عليها. متطلبي الأساسي هو تجنب 20 ألف مستخدم أو أكثر يرسلون لي رسائل بريد إلكتروني يسألون لماذا لا تظهر تعليقاتهم فورًا على الصفحة الرئيسية عند نشرها.

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

شكرا

[RGJ (Richard - Communiteq)]

حسنًا، أنا مرتبك لماذا يعمل هذا، لأن

@angus

ستتلقى الدالة معرفات منشورات ووردبريس التي تم تحديثها بواسطة الخطاف كوسيط، أي
do_action( 'wpdc_after_webhook_post_update', $post_ids );

ومكونك الإضافي

add_action( 'wpdc_after_webhook_post_update', function( $topic_ids ) {
    foreach ( (array)$topic_ids as $topic_id ) {
        delete_transient( 'wpdc_comment_html_' . $topic_id );
    }
}, 11 );

ألا تخلط بين معرفات (ووردبريس) $post_id التي تم تمريرها إلى الدالة مع معرف (Discourse) topic_id الذي يعمل كمفتاح مؤقت؟

أتوقع أن يبدو مكونك الإضافي كالتالي:

add_action( 'wpdc_after_webhook_post_update', function( $post_ids) {
    foreach ( (array)$post_ids as $post_id ) {
        $topic_id = get_post_meta( $post_id, 'discourse_topic_id', true );
        delete_transient( 'wpdc_comment_html_' . $topic_id );
    }
}, 11 );

من ناحية أخرى، أنت تقول أن هذا يعمل؟

[angus (Angus McLeod)]

مرحباً @Lee_Ars، هل يمكنك أولاً تأكيد أن لديك إعداد خطاف الويب الخاص بالتعليقات؟

Configure WP Discourse Webhooks

You can use webhooks to sync data between Discourse and WordPress, and enrich your integration. Reply to this topic if you have questions about how to setup the webhooks, or how they work. Setup WP Discourse First setup an endpoint in WP Discourse: Navigate to WP Discourse > Webhooks in Wordpress admin. Select the endpoint(s) you want to enable (see below). Set a “Webhook Secret Key”, if it’s not already set. Click “Save Options”. Discourse Then create a new Webhook in Discourse (Go to /admi…

يعمل هذا على النحو التالي:

1. يوجد منشور جديد في Discourse.
2. يتم إرسال حمولة خطاف ويب إلى Wordpress.
3. يقوم WP discourse بتحديث عدد التعليقات على المنشور ويقوم أيضًا بتعيين حقل مخصص للمنشور wpdc_sync_post_comments.
4. إذا تم تعيين wpdc_sync_post_comments، فسيتم مزامنة تعليقات Discourse عند تحميل منشور Wordpress، بغض النظر عن فترة المزامنة (أي تأخير الـ 10 دقائق).

قبل أن نتعمق في التخزين المؤقت، أريد فقط التأكد من أن هذا الإعداد موجود أولاً. إذا كان الأمر كذلك، فربما قم أيضًا بتشغيل “سجلات خطاف الويب المفصلة” وتحقق من أنك تتلقى طلبات خطاف الويب عند إنشاء منشور جديد في Discourse.

[Lee_Ars]

@angus

مرحباً @Lee_Ars، هل يمكنك أولاً التأكد من إعداد خطاف الويب الخاص بالتعليقات؟

مرحباً Angus! هذا مؤكد، تم تمكين خيار خطاف الويب “مزامنة بيانات التعليقات” على جانب WP، وقمت بإنشاء خطاف الويب على جانب Discourse وتكون الـ pings ناجحة. يُظهر تسجيل المكون الإضافي WP رسائل comment.INFO: sync_comments.success في الطوابع الزمنية الصحيحة:

[2025-07-07 14:16:38] connection.INFO: check_connection_status.successful_connection
[2025-07-07 14:16:38] connection.INFO: check_connection_status.valid_scopes
[2025-07-07 20:11:31] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 20:25:03] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 20:32:14] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 20:44:15] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 21:00:39] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 21:01:42] comment.INFO: sync_comments.success {"post_id":786}
[2025-07-07 21:15:40] comment.INFO: sync_comments.success {"post_id":786}

فقط أنه حتى مع رسائل النجاح هذه، يستمر الزوار الحاليون (أو على الأقل أنا، أختبر بشكل متكرر على Firefox/Safari/Chrome على جهاز Mac، و Firefox/Chrome/Edge على جهاز كمبيوتر يعمل بنظام Win10، و Safari على iOS) في الحصول على نقطة نهاية /wp-json/wp-discourse/v1/discourse-comments مخبأة مؤقتًا، مع تعيين رؤوس cache-control إلى قيمة غير صفرية. إذا قمت بتنفيذ ctrl-shift-f5 على Chrome (أو ما يعادله في المتصفحات الأخرى) لتجاوز ذاكرة التخزين المؤقت المحلية عند التحديث، فإن كل شيء يعمل بشكل رائع وتظهر المشاركات الجديدة.

مع وجود مكونات mu الإضافية في مكانها، تعرض نقطة النهاية هذه cache-control مضبوطة على no-store no-cache وما إلى ذلك، ولا يظهر سلوك المشكلة - ببساطة زيارة مشاركة WP أو تحديثها باستخدام زر التحديث العادي يعرض التعليقات المضمنة الجديدة.

لقد قمت بتشغيل تسجيل خطاف الويب المطول ونشرت مشاركة اختبار، وتبدو الأمور على ما يرام عند إنشاء مشاركة جديدة:

webhook_topic.INFO: update_topic_content.update_post_metadata_success {"post_ids":"786"}

كل شيء يبدو أنه يعمل، لكنني ما زلت لا أفهم حقًا سبب ظهور سلوك المشكلة الأصلي، أو ما إذا كان قد نشأ من مشكلة تم تجاهلها من جانبي. (ممكن جداً!)

@RGJ

هممم أنا مرتبك لماذا يعمل هذا…

D’oh، آسف، أنا متأكد من أنك على حق بشأن إفسادي الأمر - كان أمس يومًا طويلاً، وكما قلت، أنا نوعًا ما عند حدود قدراتي هنا. لقد كان بالتأكيد يفعل شيئًا ما، على الرغم من أنني الآن أتساءل عما إذا كان السلوك “المُصلح” الذي أراه هو مجرد كونه معطلاً بطريقة جديدة. (لقد قمت بتحديث المكون الإضافي “transient killer” لاستخدام الوسيطة الصحيحة الآن، شكرًا لك!)

[angus (Angus McLeod)]

شكرًا، لذا هناك شيء واحد آخر لتوضيحه. هل هذا الإعداد الخاص بـ WP Discourse (في “التعليقات”) قيد التشغيل؟

[Lee_Ars]

لقد جربت كليهما مع تمكين إعداد Cache Comment HTML أو تعطيله ويبدو أنه لا يؤثر على السلوك الإشكالي. حاليًا لدي معطل، ولكن يمكنني تعيينه إلى أي شيء قد يكون مفيدًا لاستكشاف الأخطاء وإصلاحها.

[RGJ (Richard - Communiteq)]

إذا تم تعطيل الإعداد، فلن تلاحظ خلط topic_id / post_id، نظرًا لأن هذا المكون الإضافي لا يفعل شيئًا في هذه الحالة. لا يوجد تخزين مؤقت → لا يهم إذا قمت بحذف ذاكرة التخزين المؤقت الخاطئة.

إذا تم تمكين الإعداد، فيجب أن تلاحظ أن المكون الإضافي لا يعمل بشكل صحيح.

أي، إذا كنت ترغب في استكشاف الأخطاء وإصلاحها، فيجب عليك تمكين الإعداد.

[angus (Angus McLeod)]

حسنًا، كإجراء أول لحالتك أقترح ما يلي:

1. احتفظ بتعطيل تعليق ذاكرة التخزين المؤقت HTML؛ و
2. قم بإزالة المكون الإضافي https://www.bigdinosaur.org/r/wp-discourse-transient-killer.txt لأنه لا يفعل شيئًا حاليًا كما يلاحظ ريتشارد.

إذا لم يحل ذلك المشكلة، فالمشكلة تتعلق بشكل آخر من أشكال التخزين المؤقت. الأسئلة التالية التي يجب الإجابة عليها هي:

1. ما هي حلول التخزين المؤقت التي تستخدمها (أنت و/أو مزود الاستضافة الخاص بك) لـ Wordpress؟
2. إذا كان https://www.bigdinosaur.org/r/wp-discourse-cache-header-fix.txt يحل المشكلة، فكيف يقوم سلوكه المحدد بإبطال أي ذاكرة تخزين مؤقت يتم تطبيقها في 1؟

بالنظر إلى wp-discourse-cache-header-fix أرى أن أحد الإصلاحات هو لـ load-comments.js. هل لديك هذا الإعداد ممكّنًا؟

[Lee_Ars]

[اقتباس=“angus, post:8, topic:373254”]
ما هي حلول التخزين المؤقت التي تستخدمها أنت (و/أو مزود الاستضافة الخاص بك) لـ Wordpress؟
[/اقتباس]

هذا هو ووردبريس مستضاف ذاتيًا على nginx+php-fpm 8.3 مع تخزين fast-cgi المؤقت ولا توجد طبقات أخرى (لا يوجد CDN، لا يوجد CF، لا يوجد Varnish على الجهاز أو ذاكرة تخزين مؤقت محلية أخرى بخلاف ذاكرة التخزين المؤقت fast-cgi الخاصة بـ nginx). إفراغ ذاكرة التخزين المؤقت fast cgi الخاصة بـ nginx (بشكل عدواني، عن طريق تشغيل rm -rf /etc/nginx/cache/*) لا يؤثر على سلوك المشكلة — يتم تقديم نتائج قديمة حتى بعد مسح دليل ذاكرة التخزين المؤقت وإعادة تشغيل كل من nginx و php-fpm.

بالفعل لدي تحميل تعليقات Ajax ممكّن حاليًا، نعم، ولكن مرة أخرى، تعطيله (وإفراغ ذاكرة التخزين المؤقت لـ nginx وإعادة تشغيل nginx و php-fpm فقط في حالة) لم يكن له أي تأثير على سلوك المشكلة. كانت المتصفحات لا تزال تحصل على تعليقات قديمة.

[angus (Angus McLeod)]

حسناً. فقط حتى أكون واضحاً بنسبة 100%.

عندما يكون لديك

• خطاف تعليقات يعمل بشكل موثق
• إيقاف ذاكرة التخزين المؤقت لـ HTML للتعليقات
• إيقاف تحميل AJAX
• لا يوجد CDN
• لا يوجد CloudFront
• لا يوجد إضافة تخزين مؤقت لـ WordPress
• لا توجد تحذيرات أو أخطاء ذات صلة في سجلات PHP

هل أنت متأكد من أنه لا يعمل؟

إذا لم يكن يعمل مع هذا الإعداد، فأنا في حيرة بعض الشيء دون إلقاء نظرة أقرب وسأفترض افتراضياً

• تحميل AJAX قيد التشغيل
• إصلاحات wp-discourse-cache-header-fix.php الخاصة بك

وهو ما أظن أنه كان يعمل لديك. إذا كان هذا المسار يعمل، فيجب عليك اعتماده.

[Lee_Ars]

@angus

حسنًا، فقط حتى أكون واضحًا بنسبة 100%، عندما يكون لديك:

• خطاف تعليق يعمل بشكل موثوق
• ذاكرة التخزين المؤقت لـ HTML للتعليقات معطلة
• تحميل AJAX معطل
• لا يوجد شبكة توصيل محتوى (CDN)
• لا يوجد Cloudfront
• لا يوجد إضافة تخزين مؤقت لـ WordPress
• لا توجد تحذيرات أو أخطاء ذات صلة في سجلات PHP

إليك معرض Imgur سريع لقطات شاشة لإعدادات الإضافة الحالية الخاصة بي، كمرجع.

تأكيد عدم وجود شبكة توصيل محتوى (CDN)، أو Cloudfront، أو Cloudflare، أو أي منهما، وعدم وجود إضافات تخزين مؤقت بخلاف Nginx helper (للمساعدة في إبطال ذاكرة التخزين المؤقت لـ Nginx fast-cgi حسب الحاجة).

تأكيد أيضًا عدم وجود شيء ذي صلة في سجلات أخطاء php-fpm أو nginx.

هل أنت متأكد من أنه لا يعمل؟

يا إلهي، يا رجل، أتمنى لو كان كذلك. لقد كنت أضرب رأسي في هذا لمدة 30 ساعة تقريبًا في هذه المرحلة، مع بعض الوقت للراحة والنوم. قد أكون أصبحت أرى الأمور بشكل غريب بعض الشيء، هيه.

[angus (Angus McLeod)]

نعم، أتفهمك. خذ استراحة ليوم أو نحو ذلك. سأحاول إعادة إنشاء المشكلة غدًا بنسخ إعداداتك.

[Lee_Ars]

إذا لم أجد حلاً بطريقة عشوائية، وإذا أردت، فسيسعدني منح بعض الوصول المحلي المؤقت (لمدونة ووردبريس، ومنتدى النقاش، و/أو المضيفين الأساسيين) لأغراض استكشاف الأخطاء وإصلاحها. بالتأكيد لا أحاول الحصول على عمل مجاني أو أي شيء من هذا القبيل. سأكون سعيدًا بدفع مقابل خدماتك إذا كان هناك وقت فعلي يجب تخصيصه هنا.

[angus (Angus McLeod)]

حسنًا، إليك مقطع فيديو لي وأنا أحاول (وأفشل) في إعادة إنتاج مشكلتك:

Setting Up WordPress With Discourse Discussion Forum Software

الشيء التالي الذي أريدك أن تجربه هو هذا الفلتر.

@angus

wpdc_comment_sync_period

ضبط فترة المزامنة للتعليقات بالثواني. الافتراضي 600، أي 10 دقائق.

مثال

ضبط فترة المزامنة إلى 5 دقائق.

function custom_comment_sync_period( $minutes, $post_id ) {
  return 300;
}
add_filter( 'wpdc_comment_sync_period', 'custom_comment_sync_period', 10, 2);

[Lee_Ars]

شكرًا @angus — فشل إعادة الإنتاج يجعلني أشعر بتحسن كبير، لأن ذلك يعني أنني أفعل شيئًا خاطئًا بدلاً من وجود خطأ بالفعل
سأضيف هذا الفلتر اليوم عندما يكون لدي وقت مخصص لاستكشاف الأخطاء وإصلاحها وسأبلغ عن النتائج

[Lee_Ars]

بالرد بعد شهر وشيء لتوضيح الأمر - ما زلت أواجه بعض الغرابة في النشر على بيئة الإنتاج الكاملة (موقع الإنتاج, مثال لمنشور موقع الإنتاج مع تضمين discourse, منتدى discourse الفعلي)، ولكن كل شيء قابل للإدارة. سأعزو أي مشاكل متبقية في زمن الاستجابة/التأخير إلى الطبقات المعقدة التي تتكون منها Wordpress + Discourse + Cloudflare، واستراتيجية التخزين المؤقت الشديدة الخاصة بي للحفاظ على تشغيل كل هذه الأشياء أثناء عواصف حركة المرور التي تنتج عن العواصف الفعلية.

شكراً لك على تخصيص الوقت للرد، @angus <3

[Lee_Ars]

أعتذر عن إعادة إحياء هذا الموضوع مرة أخرى، ولكن أردت المتابعة والإبلاغ عن أنني وجدت سبب المشكلة! وكانت غلطتي أنا، كالعادة.

باختصار شديد، أحتفظ بتفاصيل كتلة موقع PHP الشائعة في مقتطف تحت /etc/nginx/snippets/ حتى أتمكن من تضمينها في ملفات vhost متعددة دون الحاجة إلى تكرارها في كل مرة. لقد مر وقت طوييييل (سنوات، ربما) منذ أن تحققت من هذا المقتطف، وبالتأكيد، كان هناك add_header Cache-Control "public, max-age=7200"; عشوائي فيه، والذي كان يتم تطبيقه على كل شيء يخرج من كتلة الموقع تلك.

لذلك قمت بإزالته، ومسحت جميع طبقات ذاكرة التخزين المؤقت، ويا للعجب، اختفى السلوك الإشكالي.

شكراً مرة أخرى على تخصيص الوقت للعمل معي، @angus، على الرغم من أن هذا انتهى مرة أخرى ليكون مشكلة Discourse أخرى من صنع يدي