مرحباً — أنا أبحث عن مطور Discourse خبير لمساعدتي في إعداد منصتي المجتمعية للإطلاق. النسخة موجودة بالفعل وتعمل، مع وجود سمة مخصصة (core.scss, nav.scss, nav.js)، لذا فإن الأمر لا يتعلق ببناء من الصفر، بل بإتقان التفاصيل.
ملاحظة: ملفات السمة الحالية تقتصر على طبقة التصميم فقط (الألوان، الخطوط، حقن القائمة) ولا تتضمن تجاوزات لقوالب هيكلية. لم يتم تعديل أي قوالب أساسية في Discourse.
أنا مستعد لتلقي عروض أسعار ثابتة مع هيكل دفع مقسم حسب مراحل الإنجاز.
إليك ما أحتاجه:
السمة الحالية
توجد بالفعل سمة مخصصة كاملة تدعم الوضع الفاتح والداكن، وقائمة مخصصة تقوم بإخفاء رأس الصفحة الافتراضي في Discourse، مع ألوان العلامة التجارية. يجب أن تظهر القائمة بشكل متسق على جميع أنواع الصفحات، بما في ذلك ملف العضو، وأحتاج إلى شخص يقوم بمراجعة وإصلاح أي عناصر تعود إلى الإعدادات الافتراضية لـ Discourse. كما يجب استبدال الشعار (سيتم توفير الملف).
صفحة بوابة العضو
أريد صفحة ملف شخصي مخصصة تعرض نوع العضو (مالك، عضو، أو تاجر)، ومركبته، وشارة حالة التحقق، ومحدد اللغة. يجب أن تكون روابط الموارد المعروضة على الصفحة مشروطة؛ فمثلاً، يرى الملاك أدوات مختلفة عن الأعضاء المحتملين. سأوفر نموذجًا تفاعليًا كاملاً يوضح الحالات الفاتحة والداكنة وجميع عروض أنواع الأعضاء.
تحتاج الصفحة أيضًا إلى لوحة “الحسابات المتصلة” حيث يمكن للأعضاء المصادقة عبر Discord و Facebook OAuth. عند المصادقة الناجحة، يتم كتابة معرف المنصة واسم المستخدم الخاصين بهم مرة أخرى إلى Supabase (سيتم توفير بيانات الاعتماد والمخطط). لقد قمت بإعداد تطبيقات OAuth، وأحتاج فقط إلى مكون جانب Discourse ومنطق استدعاء الربط (callback) ليعمل بسلاسة.
اللغة والترجمة
المجتمع دولي لذا فإن هذا الأمر بالغ الأهمية. عندما يختار العضو لغته المفضلة (الإنجليزية، التايلاندية، التشيكية، الهولندية، الألمانية، الإنجليزية النيوزيلندية)، أريد أن يتحول واجهة Discourse بالكامل — القوائم، الإشعارات، رسائل النظام، كل شيء. عند الزيارة الأولى، قم باكتشاف بلدهم من عنوان IP واطلب منهم التأكيد. أحتاج أيضًا إلى تثبيت وتكوين إضافة Discourse Translator باستخدام مفتاح API من DeepL (سيتم توفيره)، مع تفعيل أزرار ترجمة المنشور لكل منشور، وتخزين الترجمات مقابل معرف المنشور لتقليل تكاليف API. يجب أن تظهر الصفحات الثابتة، بما في ذلك بوابة العضو (التي يجب أن تكون قابلة للوصول عبر أزرار Discourse الأصلية أيضًا)، باللغة المحددة.
مستويات الثقة، المجموعات، وتكامل Tally
سيكون هيكل التصنيفات جاهزًا قبل أن تبدأ. ما أحتاجه هو ربط تكوين مستويات الثقة والمجموعات بشكل صحيح، بحيث يتم تعيين أنواع الأعضاء (مالك، عضو، تاجر) عند التسجيل، وتُربط المجموعات بصلاحيات التصنيفات المناسبة، ويتم مزامنة أي تغييرات مع Supabase. أحتاج أيضًا إلى تعريض discourse_user_id و discourse_username كمعلمات URL لنماذج Tally المدمجة حتى يمكن التقاطها كحقول ملء تلقائي مخفية.
بوابة التحقق من DVLA
يجب أن يكون التصنيف المخصص للملاك فقط محميًا وراء تحقق من المركبة. عندما يحاول عضو غير محقق الوصول إليه، تظهر له رسالة تطلب منه إدخال رقم التسجيل. أنا أقوم ببناء نقطة نهاية التحقق بنفسي (Cloud Run، REST — موثقة بالكامل ومقدمة) لذا فإن نطاق عملك هنا يقتصر على مكون السمة في Discourse: شاشة الهبوط المحمية، ونموذج إدخال VRM، وحالات النجاح/الفشل. أحتاج إلى شخص مرتاح للتعامل مع مكونات السمة المبنية على Ember في Discourse لهذا الجزء تحديدًا.
موضوع XCombo
مكون آخر: موضوع واحد في Discourse يعمل كمصدر مرجعي ومساحة نقاش لمجموعة بيانات أحتفظ بها. أول منشور مثبت ويحتوي على أداة بحث مدمجة (تقوم بتصفية البيانات في الوقت الفعلي من جدول Supabase)، وزر “أرسل لي القائمة الكاملة عبر البريد الإلكتروني” (يتصل بنقطة نهاية مقدمة، ويقوم Resend بإرسال ملف PDF إلى عنوان العضو المسجل)، ورابط ينزل إلى خيط النقاش المفتوح أدناه. مرة أخرى، منطق البحث، نقطة النهاية، وتكامل Resend كلها مقدمة — أنت تقوم فقط بربط الحاوية في جانب Discourse. هذا يعطيك أيضًا فكرة عن تدفق العضو الكامل: البوابة → رابط المورد → الموضوع → البحث → البريد الإلكتروني.
سأوفر جميع الأصول، وبيانات الاعتماد، والوصول إلى Supabase، والوثائق عند منح العقد. مستعد لمناقشة التفاصيل إذا لزم الأمر. يرجى إخباري بخبرتك في تكاملات OAuth في Discourse تحديدًا، وما إذا كنت قد عملت سابقًا مع مكونات السمة المبنية على Ember.
شكرًا جزيلاً
تم التعديل للوضوح