لدي فكرة مجنونة، وهي أنني أستخدم في WooCommerce محفظة افتراضية (تعتمد على النقاط) والتي أود مزامنتها مع نقاط الألعاب في Discourse… ولكنني أشعر أن واجهة برمجة التطبيقات وحدها ثقيلة جدًا (سواء بالاستشارة كل x cron أو عندما يقوم المستخدم بإجراء في WC)… هل يمكنك إنشاء خطاف ويب لتحديث المحفظة الافتراضية في WooCommerce بالنقاط التي تم الحصول عليها في Discourse؟… أرفق مخططًا توضيحيًا للدليل
أعلم أن الأمر قد يكون أكثر تعقيدًا مما يبدو، خاصة وأن واجهة برمجة تطبيقات Discourse جديدة نسبيًا (ولا يوجد خطاف ويب أيضًا)، ولكني أقدم حالة استخدام فقط، تحقق من صحة الفكرة
أوه، لم أفكر في هذا النهج… أي يمكنني استخدام n8n (استضافة خاصة لتقليل التكاليف)؛ سأقوم بإنشاء مشغل cron كل 5 أو ربما 10 دقائق للاستعلام عن واجهة برمجة تطبيقات Discourse للنقاط الجديدة (كيف يمكنني الاستعلام عن جميع المستخدمين؟ أو هل ستفعل ذلك للأحداث؟)… على الرغم من أنه بالطبع ستكون هناك نافذة زمنية صغيرة ثابتة حيث لن ترى النقاط متزامنة عبر كلا النظامين…
كنت أفكر في الأمر، وأعتقد أنه إذا كان من الممكن إنشاء خطاف ويب (webhook) لمكون الإضافات الخاص بالألعاب (gamification plugin) يرسل المعلومات عبر الأحداث (دون الحاجة إلى الاستعلام عبر واجهة برمجة التطبيقات API)، فإن هذا سيتجنب الحاجة إلى الاستعلام، على سبيل المثال، إذا كان هناك 200 مستخدم نشط، 200 مرة عبر واجهة برمجة تطبيقات كل 5 دقائق (وأيضًا بشكل افتراضي يسمح Discourse بخطافات الويب… الأمر مهم لأن Discourse هو المصدر الرئيسي للنقاط (ويحدث بشكل مستمر أكثر) وهذا سيكون تحديثًا يسمح بالمزامنة في الخلفية. على الفور وفقًا للتغييرات في Discourse…
متأخر عن الركب هنا - هل هناك طريقة يمكن بها تخصيص معاملات نقاط معينة بحيث لا تُحتسب كـ “إنفاق” بالنسبة لترتيب لوحة الصدارة؟ أود أن تُحتسب النقاط السلبية الحقيقية الأخرى بالنسبة للوحة الصدارة (الأصوات/الأعلام ضد، أحداث واجهة برمجة التطبيقات كما هو مقترح أعلاه لـ “خسارة” حدث سلم، إلخ).
على سبيل المثال.
تجميع 10 آلاف نقطة من خلال الأنشطة، وتصدر القائمة. يا للروعة!
إنفاق 10 آلاف نقطة على سلع فاخرة، والوصول إلى رصيد “قابل للإنفاق” قدره 0 نقطة حيث سيجمع الاستعلام 10 آلاف - 10 آلاف.
ولكن يجب أن تظل في أعلى لوحة الصدارة.
خسارة 2 ألف نقطة في لعبة سلم، وعرضها على لوحة الصدارة عند 8 آلاف. خسارة الصدارة… رصيد قابل للإنفاق سالب 2 ألف.
هذا ما يغطيه التحذير في الموضوع الأصلي. نظرًا لأننا نقوم بتخزين النتيجة الإجمالية مؤقتًا في كل مكان في واجهة المستخدم، فبعد تعديلك، ستنعكس فقط بعد تحديث ذاكرة التخزين المؤقت. بالنسبة للأحداث الأخيرة، يتم تحديث ذاكرة التخزين المؤقت تلقائيًا، ولكن بالنسبة للأحداث التي وقعت منذ أكثر من 10 أيام، ستحتاج إلى تشغيل تحديث النتيجة لتلك الفترة.
أعتقد أنك على حق. يبدو أنه تتم إضافة المزيد من النطاقات عند طلبها. يمكنك القيام بذلك باستخدام إضافة مخصصة إذا كنت تستضيف بنفسك. يمكنك تقديم طلب سحب (PR) و/أو النشر كـ #طلب ميزة. إذا كنت عميلاً للمؤسسة، يمكنك أن تطلب قيادتك.
حسنًا. الآن أتساءل عما إذا كان من الممكن إضافة نطاق واجهة برمجة تطبيقات مخصص في إضافة (خاصةً وجود إضافة تضيف نطاق واجهة برمجة تطبيقات لإضافة أخرى). أشك في ذلك، لكنني لم أر ذلك يحدث.
ربما قم بإنشاء مستخدم لواجهة برمجة التطبيقات فقط حتى تتمكن على الأقل من تتبعها بهذه الطريقة.
بصفتي مبتدئًا في البرمجة، لقد حاولت جاهدًا فهم محتوى المنشور ولكنه لا يزال صعبًا للغاية بالنسبة لي… أردت أن أسأل عما إذا كانت هذه الميزة مشابهة لـ “الدفع للمشاهدة”؟ إنها ميزة شائعة جدًا في المنتديات التقليدية حيث يكسب المستخدمون نقاطًا من خلال الأحداث (مثل تسجيل الدخول اليومي، النشر، الرد، إلخ)، ثم تتطلب بعض المنشورات في المنتدى من المستخدمين دفع نقاط لعرض المحتوى الكامل. في المنتديات التقليدية (مثل Discuz)، تكون عمليات كسب النقاط وخصم النقاط مؤتمتة. مما أستطيع رؤيته الآن، يمكن للتحفيز بالألعاب (gamification) التعامل مع جزء “كسب النقاط”، ولكن هل تتطلب عملية “خصم النقاط” استدعاءات واجهة برمجة تطبيقات (API) يدوية من قبل المسؤولين؟ سيكون هذا صعبًا للغاية بالنسبة لمنتدى شخصي. مما أفهمه، فإن تشغيل واجهات برمجة التطبيقات بتهور دون معرفة برمجية كبيرة قد يكون خطيرًا وقد يتسبب حتى في انهيار المجتمع بأكمله…
هل من الممكن تطبيق ميزة “الدفع للمشاهدة” هذه كإضافة (plugin) قائمة بذاتها؟ أو إذا قمت بتوظيف شخص لتخصيصها، فكم ستبلغ التكلفة تقريبًا؟
