نظام حجز بمواعيد وقواعد خاصة
إضافات الحجز الجاهزة لا تدعم طريقة عملك: فترات مختلفة لكل خدمة، أو عربون، أو أكثر من فرع.
إضافة حجز مبنية على قواعدك أنت، مربوطة بالدفع وبالإيميل.
العميل يحجز وحده، وأنت ترى جدولك في مكان واحد.
نظام حجز بقواعدك، ربط مع برنامج الحسابات، لوحة متابعة لفريقك، أو استيراد أسعار من مورد. عندما لا تجد إضافة جاهزة تعمل المطلوب، أو تجدها ثقيلة أو غير آمنة، نبرمج لك إضافة مستقلة، آمنة، وقابلة للتطوير.
كل إضافة نبرمجها تبدأ من مشكلة حقيقية في طريقة العمل، لا من فكرة تقنية. هذه أمثلة لما يمكن بناؤه:
إضافات الحجز الجاهزة لا تدعم طريقة عملك: فترات مختلفة لكل خدمة، أو عربون، أو أكثر من فرع.
إضافة حجز مبنية على قواعدك أنت، مربوطة بالدفع وبالإيميل.
العميل يحجز وحده، وأنت ترى جدولك في مكان واحد.
كل طلب في المتجر يُنسخ يدويًا إلى برنامج الحسابات، مع أخطاء وتأخير.
إضافة ترسل الطلب والفاتورة تلقائيًا عند تغير حالته، مع سجل لكل عملية.
بيانات متطابقة بين المتجر والحسابات بدون نسخ ولصق.
المعلومات موزعة بين شيتات ورسائل، ولا توجد صورة واحدة للوضع.
لوحة تحكم داخل ووردبريس بصلاحيات مختلفة لكل دور.
كل شخص يرى ما يخصه فقط، وأنت ترى الصورة الكاملة.
المورد يرسل ملفًا أو يوفر API، والتحديث اليدوي يأخذ ساعات ويسبب أخطاء في الأسعار.
استيراد مجدول يقرأ المصدر ويحدث المنتجات المتغيرة فقط، مع تقرير بما تغير.
أسعار ومخزون محدثان بدون تدخل يومي منك.
الاستفسارات تضيع بين الواتساب والإيميل، ولا تعرف ما الذي تم الرد عليه.
نظام تذاكر بسيط داخل حساب العميل مع إشعارات للطرفين.
كل طلب دعم له حالة وسجل واضح.
تحتاج أسعارًا مختلفة حسب نوع العميل أو الكمية، والإضافات الجاهزة معقدة أو ناقصة.
قواعد تسعير تُطبق تلقائيًا في السلة حسب العميل والكمية.
كل عميل يرى سعره الصحيح بدون عروض يدوية.
لا نبرمج شيئًا يمكن حله بإضافة جاهزة جيدة. استخدم هذه القائمة لتعرف أين تقف.
هذا التقسيم هو ما يجعل الإضافة سهلة الفهم والاختبار والتطوير لاحقًا، حتى لو تولاها مطور آخر.
الإضافة لها صلاحية الوصول لبيانات موقعك وعملائك، لذلك نلتزم بهذه المعايير في كل مشروع:
كل نموذج وإجراء محمي برمز تحقق يمنع تنفيذ طلبات مزيفة.
لا يستطيع أي مستخدم تنفيذ إجراء ليس من دوره.
البيانات تُفحص قبل الحفظ وتُهرّب قبل العرض.
لا استعلامات قاعدة بيانات مبنية من مدخلات مباشرة.
مفاتيح الربط محفوظة في الإعدادات، لا داخل الملفات.
لا تعديل على ملفات ووردبريس أو WooCommerce نفسها.
ملفات الإضافة تُحمّل فقط في الصفحات التي تحتاجها.
عند إلغاء الإضافة لا تترك خلفها بيانات أو جداول بلا فائدة.
من سيستخدم الإضافة، وماذا يجب أن يحدث في كل حالة، وما الذي لا يجب أن يحدث.
البيانات التي تُحفظ، والصلاحيات، ونقاط الربط، وحالات الفشل.
التنفيذ على أجزاء واضحة يسهل تطويرها لاحقًا، بعيدًا عن موقعك الحقيقي.
اختبار الحالات العادية والخاطئة، ثم التشغيل والمتابعة.
مستقلة عن القالب، مثبتة ومفعّلة على موقعك.
تغيّر منها الخيارات بدون لمس الكود عند الحاجة.
ماذا تفعل الإضافة، وكيف تستخدمها، وأين إعداداتها.
الحالات العادية وحالات الخطأ التي تم اختبارها قبل التشغيل.
لو وجدنا أثناء المراجعة إضافة جاهزة موثوقة تعمل المطلوب، نخبرك بذلك قبل أي برمجة.
إذا كانت الجاهزة تعمل المطلوب جيدًا ومن مصدر موثوق ومتحدّثة، استخدمها. ننصح بالمخصصة عندما تعمل الجاهزة نصف المطلوب، أو تكون ثقيلة، أو تحتاج تعديلات ستضيع مع أول تحديث.
نعم. الإضافة مستقلة عن القالب، لذلك تستمر وظيفتها كما هي. قد تحتاج فقط ضبط شكل العرض إذا كان لها واجهة تظهر للزوار.
نعم في الظروف العادية، لأنها مبنية بالطرق الرسمية. وإذا غيّر ووردبريس أو WooCommerce شيئًا جوهريًا يكون التحديث المطلوب محددًا ومعروف المكان.
نبنيها لتُحمّل ملفاتها فقط في الصفحات التي تحتاجها، والمهام الثقيلة مثل الاستيراد تعمل في الخلفية بدل أن تؤخر الزائر.
نعم. نقسّم الإضافة إلى أجزاء واضحة من البداية، فإضافة خاصية جديدة لاحقًا لا تعني إعادة البناء.
حسب حجم الوظيفة وعدد الحالات وأي ربط مع أنظمة خارجية. نحدد النطاق والسعر والمدة بعد فهم المطلوب وقبل أي التزام.
لا تحتاج مواصفات تقنية. اكتب الخطوات التي تقوم بها الآن ومن يقوم بها، ونرد عليك بالحل المقترح ونطاقه وسعره ومدته.