@ستيفن، شكرًا جزيلاً على هذا الرد، إنه مفيد للغاية.
يبدو أن الحقول المخصصة تحل معظم مشكلتي؛ فأنا أستخدم إضافة التلخيص (teaser plug-in)، وقد توصلت إلى حل عملي لأنواع العضوية بناءً على ما تسمح به هذه الإضافة.
لقد نظرت إلى الجدول (نشكر جوجل للترجمة!) ويبدو أنه يمكننا وجود مستويات عضوية متعددة بتكاليف مختلفة عبر ProCourse، أليس كذلك؟ إذا كان الأمر كذلك، فيمكنني ببساطة إنشاء عضوية إضافية توفر نفس الوصول تمامًا ولكن بتكلفة أقل. نحن مجموعة صغيرة بما يكفي للتعامل مع هذا كحل، مع وجود شخص يتأكد يدويًا من وجود عضوية “رئيسية” لهؤلاء المستخدمين.
أعمل على إعداد هذا، ولديّ سؤال. إذا كان لدي عضوية مدتها 12 شهرًا لمجموعة “برونزي”، فهل سيتم إزالة العضوية من هذه المجموعة في نهاية الـ 12 شهرًا؟ هل هناك تنبيه للمستخدم يحدث هذا/قريبًا من الحدوث؟
قرأت هذا النص عدة مرات وحاولت مرة أخرى استخدام موقع العرض التجريبي، وأعتقد أنني فهمت الآن سبب حيرتي فيما يتعلق بتدفق التسجيل / العضوية.
إليك ما أعتقد أنني بحاجة إلى فعله:
ملاحظة: موقعي مدفوع بالكامل، ولا يوجد مستوى مجاني.
لدي صفحة مبيعات ثابتة (خارج Discourse) تحتوي على نموذج طلب. إذا تمت الموافقة على الطلب (عملية يدوية)، سأرسل دعوة للانضمام من داخل Discourse.
يسجل العضو الجديد ويحصل على حساب جديد في Discourse.
يسجل العضو الجديد الدخول إلى Discourse فيجد… منتدى فارغاً، باستثناء موضوع واحد حول “إنشاء عضوية”. [ربما يكون هذا هو المكان الذي تلعب فيه الصفحة الثابتة الخاصة بالدورة الاحترافية دورها، ويمكنني إنشاء صفحة ثابتة تحتوي على خيارات الدفع بدلاً من ذلك؟]
يحتوي ذلك الموضوع [أو الصفحة الثابتة] على خيارين: دفع شهري متكرر ودفع سنوي متكرر. كل رابط أو زر يؤدي إلى صفحة العضوية التي أنشأتها داخل إضافة Procourse.
يكمل العضو الجديد عملية الدفع ويتم إضافته إلى مجموعة الأعضاء، والتي لديها حق الوصول إلى المنتدى بالكامل.
أعتقد أنني على المسار الصحيح هنا. لكن النقطة رقم 3 و4 تثيران شكوكاً لدي. هل فاتني مسار أسهل أو أكثر وضوحاً؟
ملاحظة جانبية: كنت أظن أن صفحة الدفع ستظهر أولاً، قبل أن ينشئ العضو الجديد حسابه. كان ضرورة إنشاء حساب أولاً عقبة كبيرة في ذهني، لكنني أفهم السبب الآن. أعتقد.
أعتقد أنك ستواجه مشاكل في سهولة الاستخدام لمستخدميك من خلال إجبارهم على التسجيل، ثم الانتظار للموافقة، ثم الدخول إلى منتدى فارغ، ثم دفع ثمن المحتوى.
قد يكون من الأفضل لك اتباع نهج مشابه حيث يكون Discourse مقفلاً، ولكن استخدم WP Discourse لتسجيل الدخول الموحد (SSO) و Paid Memberships Pro لتقييد الوصول إلى المجتمع. ستتم كل هذه العمليات بسلاسة أكبر لمستخدميك.
فكرة التطبيق هي الحصول على بعض المعلومات الخلفية عن الشخص وما يأمل في تحقيقه من المجتمع. أنا عضو في مجموعة أخرى، حيث انضم الأعضاء وغادروا بعد فترة قصيرة لأنهم لم يكونوا مناسبين للمجموعة.
يمكنني تعديل الأمور لتوجيههم مباشرة إلى صفحة تسجيل الأعضاء، ثم، بعد انضمامهم، طرح نفس الأسئلة عليهم كجزء من عملية الترحيب بهم. هذا سيعمل، خاصة أنني تحدثت كثيرًا عما يمكن توقعه قبل أن يسجل الأشخاص.
سؤال واحد: إذا سلكنا هذا المسار، هل يمكنني توجيههم مباشرة إلى صفحة العضوية في Procourse (حيث يشتركون ويدفعون) ثم إنشاء حساب لهم في Discourse؟ أم أن العملية لا تزال تتطلب إنشاء حساب أولاً ثم اختيار خطة الدفع؟
أود دمج هذا مع إضافة السحرة المخصصة. باستخدام هذه الإضافة، يمكنك التقاط أي معلومات تريدها أو جميعها أثناء التسجيل، ثم عند إرسال النموذج، يتم توجيه المستخدم إلى صفحة دفع العضوية. بهذه الطريقة، يكون كل شيء في تدفق واحد.
شخصيًا، أفضل هذه الطريقة مقارنة بالطريق المتبع في Paid Memberships Pro. يمكن لـ PMPro أن يعمل بشكل ممتاز حتى تبدأ في محاولة مزامنة عضويات المجموعات ذهابًا وإيابًا. يمكنك القيام بذلك، ولكن بناءً على تجربتي، فإن إعداده ليس سهلاً دائمًا ولا يكون موثوقًا به في جميع الأوقات.
عندما كنت أدير PMP على موقعي مع مزامنة المجموعات، لم أواجه أي مشاكل، لكن من الصحيح أنك تحتاج إلى بعض المعرفة التقنية لجعله يعمل. بغض النظر عن التفضيلات الشخصية، كلاهما خياران بالتأكيد لهما مزايا وعيوب فريدة – @madbaker نأمل أن نكون قد ساعدناك في الاقتراب من اتخاذ قرارات ممكنة!
نجحتُ في تشغيل إضافة السحرة المخصصة (Custom Wizard) بنجاح عند التسجيل. فهي تستدعي صفحة ثابتة حيث يمكن للمستخدم الجديد اختيار خطة عضوية متكررة (شهريّة أو سنويّة).
لديّ مستويان في إضافة العضوية، ويذهب المستخدم إلى صفحة العضوية الصحيحة عبر الصفحة الثابتة. رائع.
المشكلة الوحيدة هي أن جزء تكامل Stripe في الصفحة يقف ويدور دون استجابة.
لقد راجعتُ بعناية وثائق تكامل Stripe على موقع مجتمع Procourse. يبدو أن إعداداتي صحيحة، لكن من الواضح أنها ليست كذلك.
قمتُ بمراجعة عملات الصرف في الإضافة وStripe (كلها بالدولار الأمريكي)، ومفاتيح API وسرير الويب (webhook secret). جميعها في وضع “الاختبار”.
أنشأتُ مستوى دفع لمرة واحدة في حال كان نموذج الاشتراك هو السبب (لم يتغير شيء).
راجعتُ سجلات Stripe ولم أجد أي سجل لمحاولة استدعاء (لا شيء في السجل).
هل توجد طريقة للتحقق من سجل داخل Discourse لمعرفة أي استدعاء يتم محاولة إجراؤه؟
أنا مستعد للنشر في السوق للحصول على مساعدة، ولكن إذا تمكّنتُ من معرفة ما تحاول الإضافة فعله على الأقل، فسيتحسن الأمر. لقد قمتُ بتبسيط تدفق التسجيل إلى الأساسيات دون وجود حل، رغم أن الوثائق تشير إلى أن هذا يجب أن يكون مباشرًا الآن. (كلمات أخيرة مشهورة!)
لقد قمت ببعض البحث الإضافي وجربت بعض الأمور الإضافية يائسًا:
أعيدت بناء التطبيق وشغلت أداة discourse-doctor للتأكد من عدم وجود أخطاء
حذفت وأعدت بناء مستويات العضوية الخاصة بي في إضافة procourse-membership باستخدام مفاتيح اختبار Stripe
يمكنني رؤية خطط المنتجات الجديدة (نسخة الاختبار) في Stripe عند تمكين المستويات. رائع!
لكن عند الانتقال إلى صفحة الدفع للمستويات، تظهر الصفحة لكن حقول بطاقة الائتمان لا تُحمّل. أبقى عالقًا مع مؤشر الدوران إلى الأبد.
فحصت سجلات أخطاء Discourse وسجلات أخطاء Stripe ولم أجد أي شيء. لا توجد إدخالات في أي من السجلين.
لذا، ظننت أن المشكلة قد تكون في “وضع الاختبار”. قمت بالتغييرات التالية:
استبدلت مفاتيح الاختبار وويب هوك بمفاتيح الإنتاج وويب هوك
أعدت إنشاء مستويات العضوية داخل الإضافة وتمكينها
ظهرت المنتجات/الخطط الجديدة في Stripe في منطقة الإنتاج. رائع!
لكن نفس المشكلة حدثت عند الانتقال إلى صفحة الدفع في Discourse. تظهر الصفحة لكن حقول بطاقة الائتمان لا تُحمّل. أبقى مع مؤشر الدوران اللانهائي.
لا توجد أي نشاطات في سجلات Stripe أو سجلات أخطاء Discourse.
=== يا للعجب! ===
أوه. لقد اكتشفت المشكلة.
هناك سكريبت مطلوب لجعل الدفع يعمل - js.stripe.com/v3. كان يتم حظره كخطأ أمني. أضفت السكريبت إلى القائمة البيضاء، وعمل بسرعة وبشكل رائع.
تفاصيل مهمة جدًا، ذلك. كنت أفحص سجلات التطبيق لكن التحقق السريع من وحدة التحكم عبر F12 كان سيوفر عليّ 4 أيام.
