The Cave Project
موقع تعريفي ولوحة تحكم ومسار طلبات لمنظمة خلوات للرجال.
THE CAVE
Four Pillars. One Platform.
- الصفحات العامة
- 8+
- ترحيلات قاعدة البيانات
- 17
- مراحل مُنجزة
- 6/6
- العميل
- The Cave Project
- القطاع
- منظمة ذات مرجعية دينية
- المؤسسون
- El Hosseine, Ayoub & Oussama
- الحالة
- مكتمل
- المدة
- مارس – أبريل 2026 · 8 أسابيع
- النطاق
- موقع تعريفي، لوحة تحكم، مسار طلبات
01 نظرة عامة
من هو العميل؟
The Cave Project منظمة رجالية ذات مرجعية دينية، قائمة على أربع ركائز: القوة الروحية، والقوة الذهنية، والتجدد الجسدي، والوضوح العاطفي. وينظمون خلوات وفعاليات ولقاءات، وهي تجارب مصمَّمة للابتعاد عن ضجيج الحياة اليومية والعودة بالصفاء والغاية. والاسم مقصود: الكهف بوصفه مكان خلوة لا مكان عزلة.
02 بيان المشكلة
ما المشكلة التي واجهوها؟
لم يكن لدى The Cave Project بيت رقمي حقيقي. فعلامتهم قائمة على التأمل والطبيعة وإتقان العمل، ولم يكن الموقع الجاهز المبني على قالب ليحمل ذلك. وعلى الصعيد العملي، لم يكن للجانب التشغيلي أي هيكل أصلًا.
غياب حضور رقمي يليق بالعلامة
لم يكن الموقع الجاهز المبني على قالب قادرًا على حمل ثقل ما يعدون به الناس في الخلوات. كان على التجربة الرقمية أن تضاهي مستوى الخلوات نفسها: مقصودة ومدروسة، وتستحق الانتباه الذي تتطلبه.
لا هيكل لاستقبال الطلبات
كان من يهتم بخلوة يتواصل عبر البريد الإلكتروني أو الرسائل المباشرة. ولم يكن لدى المؤسسين أي وسيلة لمعرفة من قدّم طلبًا، ومن تحدثوا معه، ومن قُبل. وهذا الأسلوب يتوقف عن العمل بسرعة كبيرة مع تزايد الاهتمام.
الاعتماد على مطوّر لتحديث أي محتوى
الإعلان عن خلوة، أو إضافة مصدر، أو استبدال رأي مشارك: كل ذلك كان يعني تعديلات في الشيفرة وإعادة نشر. وبالنسبة إلى فريق من ثلاثة أشخاص، هذا عنق زجاجة حقيقي وليس مجرد إزعاج.
لا حماية من البريد المزعج
يجذب أي نموذج عام على الإنترنت البوتات. وأرادوا صناديق وارد نظيفة دون وضع كابتشا (CAPTCHA) أمام مقدمي الطلبات الحقيقيين؛ فهذا طلب للمشاركة في خلوة، وليس اشتراكًا في نشرة بريدية.
03 الحل
كيف حللناها؟
بنينا المنصة في ثلاث طبقات: الموقع العام ولوحة التحكم والواجهة الخلفية. صُمّمت كل طبقة باستقلال، لكنها متصلة عبر نسخة واحدة من PocketBase تعمل على خادمهم الخاص.
الموقع العام تطبيق Next.js يركّز بشدة على السرد القصصي الذي يتحرك مع التمرير. تثبّت الصفحة الرئيسية تسلسل القسم الافتتاحي، وتكشف الركائز الأربع بمسح دائري، ثم تستعرض كل ركيزة — إحداها تحركها رسوم متحركة إطارًا بإطار مرتبطة بموضع التمرير — ثم تنتقل إلى الخط الزمني للمنظمة وآراء المشاركين وملفات المؤسسين. ويستخدم التنقل بين الصفحات واجهة View Transitions API في المتصفح، فتتحول بطاقة في صفحة القائمة بسلاسة إلى ترويسة صفحة تفاصيلها بدلًا من أن تُستبدل ببساطة.
لوحة التحكم عند /admin تعمل بمصادقة عبر ملفات تعريف الارتباط وتمنح المؤسسين تحكمًا كاملًا: لوحة معلومات تعرض الطلبات والرسائل الجديدة، إضافة إلى تحرير الفعاليات والمصادر والإعلانات وآراء المشاركين. وتنتقل الطلبات عبر مسار من ثلاث حالات: جديد ← تم التواصل ← مقبول. وتوضع علامة «تمت المعالجة» على رسائل التواصل.
- Site Next.js 15 الموقع العام GSAPLenisView Transitions
- /admin Admin Panel مصادقة بملفات تعريف الارتباط الطلباتإدارة المحتوى
- PB PocketBase Go + SQLite 17 ترحيلًاخطافات مخصصة
- القوة الروحيةالركيزة الأولى
- القوة الذهنيةالركيزة الثانية
- التجدد الجسديالركيزة الثالثة
- الوضوح العاطفيالركيزة الرابعة
- Next.js 15
- TypeScript
- GSAP ScrollTrigger
- Lenis
- View Transitions API
- PocketBase
- Go
- SQLite
- Docker
- Traefik
- Dokploy
الصفحات المنشورة: بُنيت وأُطلقت
04 الجدول الزمني للمشروع
أبرز المعالم والمدة
المرحلة 1 2–8 مارس 2026
التأسيس
إعداد المستودع كمساحة عمل Go مع Next.js، وبيئات Docker للتطوير والإنتاج، وربط PocketBase، وتهيئة حساب المشرف العام من متغيرات البيئة، لتكون أي عملية نشر جديدة جاهزة للإدارة فورًا.
المرحلة 2 9–20 مارس 2026
المحتوى والفعاليات
شريط الإعلانات مع الجدولة وزر دعوة لاتخاذ إجراء (CTA) اختياري، ومجموعة الفعاليات بحقول الاسم اللطيف (slug) والحالة والصور، والبيانات الأولية، وصفحات البرامج العامة.
المرحلة 3 23–31 مارس 2026
استقبال المهتمين
الطلبات المرتبطة بالفعاليات، ورسائل التواصل، والنموذجان العامان وفيهما حقل مصيدة (Honeypot)، وشاشات الإدارة لمراجعتها.
المرحلة 4 1–8 أبريل 2026
مكتبة المصادر: النسخة الأولية
المخطط الأولي لملفات PDF والفيديوهات وروابط وسائل التواصل الاجتماعي، مع الرفع وحالات النشر والترتيب.
المرحلة 5 9–20 أبريل 2026
إعادة تصميم مكتبة المصادر
ستة تصاميم HTML أولية مستقلة قبل كتابة أي شيفرة React. وأُعيد تشكيل المخطط عبر ترحيلات تضيف ولا تحذف: تصنيف جديد، ووسوم للمواضيع، ونسب المحتوى إلى مصدره، والمدد، وصور الأغلفة، ونصوص مقالات مطوّلة.
المرحلة 6 21–30 أبريل 2026
الصقل والإطلاق
مصادر مميزة في القسم العلوي من المكتبة، وأحجام الملفات عند تنزيل ملفات PDF، وتصنيف لأنواع الفعاليات يعتمد عليه عامل تصفية صفحات البرامج، وتهيئة Dokploy لبيئة الإنتاج.
05 التحديات وحلولها
ما العقبات التي واجهتنا وكيف تجاوزناها؟
فيديو يتحكم به التمرير
المشكلةتطلّب التصميم مقطعًا يُشغَّل للأمام وللخلف أثناء التمرير. غير أن التنقل داخل عنصر الفيديو عند كل حدث تمرير يُجهد المتصفح، فيتقطع العرض بشدة على لوحات اللمس وعجلات الفأرة، ويبدو التفاعل معطلًا بدل أن يبدو مقصودًا.
الحلتخلّينا عن التنقل داخل الفيديو تمامًا. حوّلنا المقطع مسبقًا إلى 99 إطارًا بصيغة WebP، وصرنا نبدّل مصدر صورة واحدة عند كل خطوة تمرير. والنتيجة فورية وسلسة تمامًا على كل جهاز.
حماية غير مرئية من البريد المزعج
المشكلةتجذب النماذج العامة عمليات إرسال آلية من البوتات. وكان من شأن الكابتشا (CAPTCHA) أن تضر بتجربة مقدمي الطلبات الحقيقيين، فهذا طلب للمشاركة في خلوة وليس اشتراكًا في نشرة بريدية، والاحتكاك في تلك اللحظة يرسل إشارة خاطئة عن المنظمة.
الحلحقل «website» مخفي في النموذجين العامين: لا يراه الناس، وتملأ البوتات كل الحقول، ويرفض الخادم أي عملية إرسال يكون فيها هذا الحقل غير فارغ. يُنفَّذ الفحص من جهة الخادم، لذا لا يتجاوزه استدعاء واجهة برمجة التطبيقات مباشرة.
التلاعب بالحالة عبر واجهة برمجة التطبيقات
المشكلةبما أن أي شخص يستطيع إنشاء سجل طلب باستدعاء واجهة برمجة التطبيقات، فبإمكان شخص لديه الدافع أن يرسل طلبًا مُعلَّمًا مسبقًا بأنه مقبول، بمجرد صياغة حمولة الاستدعاء المناسبة.
الحليفرض الخادم على كل طلب جديد الحالة «new» مهما كان محتوى الاستدعاء. ولا يوجد أي سبيل عبر واجهة برمجة التطبيقات العامة لترقية حالة طلبك بنفسك.
الحالات الحدية في نماذج HTML بلوحة التحكم
المشكلةمربعات الاختيار غير المحددة لا ترسل شيئًا، وحقول الملفات الفارغة ترسل ملفات حجمها صفر بايت، وحقول الأرقام الفارغة ترسل سلاسل نصية فارغة، والقوائم متعددة الاختيار بعد مسحها لا ترسل أي عناصر. وكل حالة منها تفسرها قاعدة البيانات بخلاف ما قصده المحرر.
الحلتحوّل طبقة توحيد في Server Actions كل حالة حدية إلى ما تتوقعه قاعدة البيانات قبل كتابة السجل. ولا تستطيع لوحة التحكم أن تضع البيانات في حالة غير سليمة.
توجيه عناوين URL الداخلية والعامة في Docker
المشكلةداخل شبكة compose، تصل حاوية Next.js إلى PocketBase باسم الخدمة. أما متصفح الزائر فلا يستطيع استخدام هذا العنوان. والخلط بين الاثنين يعطّل إما التصيير على الخادم وإما كل رابط لصورة أو ملف في بيئة الإنتاج.
الحلفُصل عنوانان فصلًا صريحًا في قاعدة الشيفرة كلها منذ اليوم الأول: PB_URL_INTERNAL للتصيير على الخادم داخل Docker، وNEXT_PUBLIC_PB_URL لكل ما يحمّله المتصفح مباشرة.
06 قبل وبعد
مقارنة بين الوضع قبل المشروع وبعده
| قبل | بعد |
|---|---|
| لا شيء يعكس هوية العلامة | موقع كامل: 8 صفحات عامة أو أكثر، وسرد قصصي يتحرك مع التمرير، ورسوم متحركة تحمل جمالية الخلوة |
| طلبات عبر البريد الإلكتروني والرسائل المباشرة، بلا تتبع ولا مسار، ويسهل ضياعها | تقديم الطلب لكل فعالية، مع مسار مراجعة (جديد ← تم التواصل ← مقبول) في لوحة التحكم |
| الحاجة إلى مطوّر لكل تغيير في المحتوى: الخلوات والمصادر وآراء المشاركين، وكلها كانت تتطلب إعادة نشر | ينشر المؤسسون كل شيء بأنفسهم: الفعاليات والمصادر وآراء المشاركين وشريط الإعلانات، دون الحاجة إلى مطوّر في أي خطوة |
| لا شيء يحمي النماذج العامة من البريد المزعج | حقل مصيدة في النموذجين العامين: لا تصل عمليات الإرسال الآلية من البوتات إلى صندوق الوارد، ولا كابتشا لمقدمي الطلبات الحقيقيين |
| لا مكتبة مصادر | مكتبة قابلة للتصفية مع صفحات تفصيلية، وتنزيلات PDF مع أحجام الملفات، وقسم للمصادر المميزة، ونصوص مقالات مطوّلة |
| كانت الإعلانات ستتطلب عملية نشر | شريط إعلانات مجدول مع تفعيل بنقرة واحدة ورابط دعوة لاتخاذ إجراء (CTA) اختياري، والمؤسسون يتحكمون في التوقيت |
| لا بنية تحتية للخوادم | نشر في حاويات Docker على خادمهم الخاص عبر Dokploy، مع توجيه Traefik وفحوصات الصحة ووحدات تخزين دائمة |
| ضياع المخطط والبيانات إذا أُعيد بناء الخادم | مخطط قاعدة البيانات بالكامل والبيانات الأولية يُعاد بناؤهما من 17 ترحيلًا مكتوبًا في الشيفرة، والمنصة كلها قابلة لإعادة البناء من الصفر |
07 فوائد العميل ونتائجه
ما القيمة التي حصل عليها العميل؟
- الصفحات العامة
- 8+
- الموقع · البرامج · المكتبة · التواصل
- المراحل
- 6 / 6
- مكتملة بالكامل · في موعدها
- ترحيلات قاعدة البيانات
- 17
- المخطط محفوظ في الشيفرة
- الواجهة الخلفية
- ملف تنفيذي واحد
- PocketBase · بلا قاعدة بيانات مُدارة
يدير المؤسسون كل شيء دون حاجة إلى مطوّر
نشر خلوة، وانتقاء محتوى المكتبة، وتبديل آراء المشاركين المعروضة، ووضع شريط إعلانات: كل ذلك يجري من لوحة التحكم. وبذلك لا يترتب على أي قرار يتخذونه بشأن المحتوى تكلفة مستمرة ولا تأخير.
تحولت الطلبات من رسائل مبعثرة إلى قائمة انتظار مُدارة
لكل مقدّم طلب حالة، ولا شيء يضيع، ويرى المؤسسون حجم الإقبال على كل فعالية بنظرة واحدة. ويتلقى مقدمو الطلبات تأكيدًا مناسبًا بدلًا من الصمت بعد الإرسال.
تكلفة تشغيل منخفضة ودون احتكار المورد
ملف تنفيذي واحد، وقاعدة بيانات مضمّنة، وخادم واحد متواضع. لا تراخيص لنظام إدارة المحتوى (CMS)، ولا فواتير لقاعدة بيانات مُدارة. ولأن كل شيء في حاويات ومخطط قاعدة البيانات في الشيفرة، يكفي لنقل المنصة كلها تشغيل حاويتين في مكان آخر.
الموقع نفسه يخدم العلامة
مستوى الصقل يطابق ما يعدون به الناس في الخلوات. وينتقل ذلك مباشرة إلى مسارات التقديم والتواصل، فالانطباع الأول يتسق مع التجربة التي يقدمونها.
08 الدروس المستفادة
ماذا تعلّمنا من هذا المشروع؟
اختيار واجهة خلفية تناسب حجم العميل
وفّر لنا PocketBase مع الخطافات المخصصة المصادقة والتخزين ومعالجة الملفات وواجهة برمجية للإدارة جاهزة فورًا، كل ذلك في ملف تنفيذي واحد. وهذا جزء يسير من الأجزاء المتحركة في مجموعة تقنيات تقليدية، وأكثر واقعية بكثير لمنظمة من ثلاثة أشخاص كي تمتلكها وتصونها فعلًا على المدى البعيد.
كل ما يتعلق بالأمان مكانه الخادم
حقل المصيدة، والحالات المفروضة، وقواعد السجل المفرد (singleton)، وتنقية المدخلات: كلها في الواجهة الخلفية. تجعل الواجهة الأمامية التجربة ممتعة، وتجعلها الواجهة الخلفية صحيحة. وحدود هذا الفصل لا تتداخل أبدًا.
أحيانًا يكون الحل في تغيير التقنية لا في تحسينها
كان بإمكاننا قضاء أيام في ضبط التنقل داخل الفيديو. لكن الانتقال إلى تسلسل صور حلّ المشكلة في نصف يوم. وحين تكون تقنية ما تصارع المتصفح في جوهرها، فالتصرف الصحيح هو إيجاد تقنية لا تصارعه.
أثبتت الترحيلات المكتوبة كشيفرة قيمتها في منتصف المشروع
حين اضطُر مخطط المصادر إلى التغيّر جذريًا في المرحلة 5، تحوّل ما كان سيكون عادةً جراحة يدوية محفوفة بالمخاطر في قاعدة البيانات إلى مجموعة خطوات قابلة للمراجعة، تضيف ولا تحذف، ويمكن التراجع عنها، طبّقتها كل بيئة تلقائيًا.
تصاميم أولية رخيصة قبل شيفرة مكلفة
ستة ملفات HTML مؤقتة جعلت إعادة تصميم المصادر تحدث مرة واحدة، وفق اتجاه سبق أن رآه العميل ووافق عليه. كلّفت التصاميم الأولية نصف يوم؛ ولو تخطّيناها لكلّفتنا أيامًا من إعادة كتابة شيفرة React.
مباشر في الموقع · GSAP + View Transitions API + Lenis
التفاعلات
تعرض كل بطاقة عرضًا مباشرًا لأحد أنماط التفاعل الرئيسية التي بُنيت للمشروع.
- تسلسل التمرير 99 إطارًا بصيغة WebP · تبديل صورة واحدة مع كل خطوة تمرير
- كشف الركائز الدائري مسح باستخدام conic-gradient · تدخل الركائز الأربع بالتتابع
- مشاهد تمرير مثبّتة مسار تمرير مثبّت بارتفاع 300vh · سرد قصصي للصفحة الرئيسية مقسّم إلى فصول
- تحوّل عبر View Transition تتحول بطاقة القائمة إلى ترويسة الصفحة · واجهة برمجية مدمجة في المتصفح
- مسار الطلبات جديد ← تم التواصل ← مقبول · مسار المراجعة في لوحة التحكم
- تمرير سلس يغلّف Lenis الموقع كله · زخم طبيعي على أي جهاز