المشكلة
University Barber صالون حلاقة احتاج إلى موقع واحد لثلاث مهام: تقديم خدماته وفريقه، وبيع منتجات العناية بالشعر والحلاقة عبر الإنترنت، واستقبال المواعيد. كما احتاج إلى طريقة آمنة لتعديل الموقع، لأن كل تعديل كان يذهب مباشرة إلى متجر حي.
ما الذي بنيته
بنيتُ موقع WordPress بمتجر وحجز إلكتروني، مع مسار نشر يحمي الخادم الحي.
- متجر إلكتروني على WooCommerce بخط منتجات الصالون الخاص: الشامبو والبلسم والكريمات وعلاجات تساقط الشعر ومنتجات التصفيف.
- الدفع عبر PayPal من خلال بوابة PayPal لـWooCommerce.
- أدوات التسوق: قائمة الرغبات، ومقارنة المنتجات، والعرض السريع، ومرشحات تتحدث دون إعادة تحميل الصفحة.
- حجز المواعيد إلكترونيًا عبر إضافة لحجوزات الصالونات.
- ترجمة القالب إلى الإيطالية عبر Loco Translate، لتتحدث كل تسمية في الموقع بلغة العميل.
- سكربت نشر يرسل التغييرات من حاسوبي إلى الخادم عبر rsync فوق SSH، ويعمل كتجربة دون تنفيذ ما لم أؤكد.
- حزمة انطلاق قابلة لإعادة الاستخدام: حوّلتُ المشروع إلى حزمة موثقة فيها دليل تثبيت ومعالج إعداد ومسار النشر و22 إضافة مثبتة مسبقًا، لتخدم القاعدة نفسها صالون حلاقة آخر.
التقنيات المستخدمة
WordPress، وقالب Barber من ArrowTheme مع ArrowPress Core، وElementor مع Thim Elementor Kit، وSlider Revolution، وWooCommerce مع ملحقات YITH، وContact Form 7 وMailchimp for WordPress وYoast SEO وGoogle Site Kit وReally Simple SSL وWP-Optimize، على استضافة cPanel.
لماذا بهذه الطريقة
يقرأ سكربت النشر قائمة استثناءات لا تمس أبدًا ما يعيش على الخادم وحده: إعدادات WordPress، و.htaccess، والصور المرفوعة، والتخزين المؤقت، والنسخ الاحتياطية، والسجلات. فيستطيع النشر تحديث القالب والإضافات، لكنه لا يستطيع الكتابة فوق الإعدادات الحية أو وسائط المتجر. وتتبع حزمة الانطلاق الفكرة نفسها: تأتي بمجلد رفع فارغ ودون قاعدة بيانات، فلا يتسرب شيء من محتوى المتجر الأصلي إلى موقع جديد، وتستبعد الإضافات المدفوعة التي يجب على كل مشترٍ ترخيصها.
