النشر على خادمك الخاص يعني منح وكيل صلاحية وصول شبيهة بـ SSH إلى جهاز تدفع تكلفته، وقد تكون هناك أشياء أخرى تعمل عليه بالفعل. هذا مستوى ثقة مختلف عن النشر على نطاق فرعي مجاني، ويعكس الإعداد ذلك — بضعة حقول، تُملأ مرة واحدة، وبعدها يصبح كل بناء لاحق مجرد زر. إليك ما يسأله الناس فعليًا قبل وبعد ربط أحدها.
ما الذي أحتاجه لإنشاء وجهة؟
خمسة أشياء، في الإعدادات ← النشر:
- اسم ستتعرف عليه لاحقًا — "prod-vps"، "client-hostgator"، أو أي شيء يصمد أمامك في قائمة منسدلة الساعة 11 مساءً
- المضيف والمنفذ
- بيانات اعتماد SFTP
- مسار جذر الويب (webroot)
لا رموز API، ولا أداة سطر أوامر يجب تثبيتها على الخادم، ولا مهمة cron تحتاج متابعة. إذا كان مضيفك يوفر وصول SFTP — وهو ما يشمل تقريبًا كل استضافة مشتركة، وكل VPS، وكل صندوق ووردبريس مُدار — فستنتهي خلال دقيقتين تقريبًا.
كلمة مرور أم مفتاح؟
مفتاح، إذا كان مضيفك يدعمه. كلمات المرور تعمل بشكل جيد ونحن نخزّنها مقيّدة بنطاق حسابك، لكن المفتاح يعني سرًّا واحدًا أقل موجودًا في أي مكان — الفرق بين "إلغاء مفتاح" و"إعادة تعيين كلمة مرور في كل مكان استُخدمت فيه تلك الكلمة" إذا حدث خطأ لاحقًا. كثير من إعدادات SFTP الرخيصة في الاستضافة المشتركة توفر فقط المصادقة بكلمة المرور، وهذا مقبول أيضًا. فقط لا تعيد استخدام تلك الكلمة في أي مكان آخر.
كيف أجد مسار جذر الويب الصحيح؟
هذا هو الحقل الذي يخطئ فيه الناس أول مرة، لأن الإجابة الخاطئة لا تزال تبدو معقولة. إنه ليس مجلدك الرئيسي (home)، وليس /var/www — إنه المجلد الدقيق الذي هيّأ خادم الويب لديك لخدمة المحتوى منه.
| الخادم | جذر الويب النموذجي |
|---|---|
| Apache / cPanel | public_html |
| Nginx | /var/www/mysite/html — أو مسار ما سمّاه مطور سابق قبل ثلاث سنوات لأسباب لا يتذكرها أحد |
إذا لم تكن متأكدًا، ضع ملفًا يمكن التخلص منه اسمه test.txt في المجلد الذي تظن أنه الصحيح باستخدام أي عميل SFTP، ثم تحقق مما إذا كان يظهر عند yoursite.com/test.txt. أخطئ في هذا وسيظل النشر يُبلغ عن النجاح — يكتب الوكيل الملفات بأمانة في المجلد الخطأ، وتبقى أنت محدقًا في موقع مباشر لم يتغيّر، متسائلًا عن السبب.
هل يمكن لوجهة واحدة أن تغطي أكثر من نطاق؟
نعم، وهذا هو الجزء الذي يوفر وقتًا حقيقيًا بمجرد تجاوزك موقعك الأول. الوجهة هي خادم واحد ومجموعة واحدة من بيانات الاعتماد — وهي غير مرتبطة بنطاق واحد. في إدارة النطاقات تربط كل نطاق بوجهة مع تجاوز خاص به لجذر الويب. هل تشغّل ثلاثة مواقع على VPS واحد باستخدام كتل خوادم Nginx؟
site-a→/var/www/site-asite-b→/var/www/site-bsite-c→/var/www/site-c
وجهة واحدة، ثلاث ارتباطات. أنت لا تُعيد إدخال كلمة مرور SSH ثلاث مرات، ولا تُبقي على ثلاث وجهات شبه متطابقة تتباعد عن بعضها في اليوم الذي تُغيّر فيه مفتاحًا وتنسى واحدة منها. اضغط نشر على أي من النطاقات الثلاثة وهو يعرف بالفعل أي خادم وأي مجلد — لا تختار شيئًا وقت النشر.
ماذا يفعل الوكيل فعليًا عند الاتصال؟
أولًا، يتفحص المكان — للقراءة فقط، لا شيء يُكتب بعد. هذا الفحص يتحقق من:
- مجلد فارغ
- نسخة سابقة من هذا البناء بعينه
- تثبيت ووردبريس قديم
- صفحة "قريبًا" وضعها مضيفك هناك افتراضيًا
هذا ما يحدد الاستراتيجية. جذر ويب فارغ يحصل على رفع مباشر. أما جذر ويب يحتوي على شيء بالفعل فيُعامَل بحذر أكبر، لأن الكثير من الإعدادات الفعلية بها أشياء موجودة بجانب الموقع لا ينبغي أن تختفي:
- A
.well-knownمجلد للتحقق من SSL - مجلد
uploadsلم يضعه أحد في git - A
wp-config.phpلا يريد أحد لمسه
المهمة هنا أقرب إلى "معرفة ما تغيّر والتوفيق بينه" من "المسح والاستبدال".
بعد ذلك، وقبل الكتابة فوق أي بايت واحد، يُلتقط جذر الويب الحالي كنسخة على مضيفك الخاص. ليس سجلًا في قاعدة بيانات، ولا فرقًا نحسبه ونأمل أن يكون صحيحًا — بل لقطة فعلية لما كان موجودًا هناك. هذا مهم أكثر ما يكون في أول نشر إلى أي وجهة، لأن ذلك النشر يهبط دائمًا فوق شيء ما، حتى لو كان الشيء هو لا شيء. مجلد فارغ، لقطة فارغة. موقع ثابت عمره خمس سنوات لا يتذكر أحد بناءه — يُحفظ تمامًا، مجانًا، قبل أن يُلمس. وذلك النشر الأول هو أيضًا الذي تكون فيه أقل ثقة، لذا فهو الذي يهم فيه هذا الأمر أكثر.
هل يرفع الشيفرة المصدرية أم الموقع المبني؟
الموقع المبني، دائمًا. بالنسبة لموقع ثابت، هذه هي الصفحات المولّدة. بالنسبة لبناء إطار عمل — Next.js، أو Vite، أو أيًّا كان ما يتطلبه نوع الموقع — فهو الناتج المُجمَّع، مجلد dist أو build ، وليس شجرة المصدر أبدًا. أعتقد أن هذا هو القرار الصحيح رغم أنه يعني أنك لا تستطيع الدخول عبر SSH وتشغيل npm run dev على ما هو موجود على الخادم. رفع المصدر يعني أن جذر الويب في الإنتاج يحتاج بيئة تشغيل Node وأدوات بناء فقط لخدمة HTML — تحويل صندوق استضافة مشترك لم يُصمَّم أبدًا لتشغيل خط أنابيب بناء إلى واحد يفعل ذلك، وتحويل كل عملية نشر إلى "الأمل أن يكون لدى الخادم ذاكرة كافية لإنهاء npm install". إرسال الناتج المُجمَّع فقط يبقي جذر الويب تمامًا كما يتوقعه خادم ملفات ثابت. مملّ. المملّ هو ما تريده الساعة 2 صباحًا عندما يكون هناك خطأ ما وأنت تحدّق في ذلك المجلد محاولًا معرفة ما يُقدَّم فعليًا.
كيف أعرف أن النشر نجح فعليًا؟
بعد الرفع، يصل الوكيل إلى الرابط المباشر ويتحقق مما إذا كان يستجيب — لا خطأ 500، ولا صفحة فارغة. أيًّا كان ما يجده، بالإضافة إلى أي شيء لاحظه أثناء الفحص ويريد رأيك فيه ("جذر الويب هذا يحتوي على مجلد wp-content تركته دون لمس، أكّد أن هذا متوقع")، ينتهي في سلسلة محادثة البناء. هذا هو النمط في هذه المنصة بأكملها: لا نجاح صامت، ولا فشل صامت يتحول إلى تذكرة دعم. الوكيل يخبرك بما رآه وما قرره، في نفس السلسلة التي طلبت فيها البناء.
ماذا يوجد فعليًا في سجل الإصدارات؟
كل عملية نشر تضيف إصدارًا — ليس الأولى فقط. لذا فالسجل ليس بناءاتك مرسومة على خط زمني تجريدي؛ إنه التسلسل الفعلي لما كان يُقدَّم من ذلك الجذر، بالترتيب، بدءًا مما كان موجودًا قبل ظهورك. الإصدار الأول هو دائمًا تلك الحالة السابقة للمنصة، تُلتقط تلقائيًا. لا داعي أن تفكر فيها.
ماذا يستعيد التراجع فعليًا؟
الإصدار المباشر السابق، تمامًا — ليس إعادة تشغيل لبناء قديم، ولا تقريبًا. الملفات الفعلية التي كانت تخدم الزوار قبل ذلك. هذا ضمان أقوى بكثير من معظم ميزات "التراجع" التي استخدمتها في أماكن أخرى، والتي عادة ما تعني "أعد النشر من commit قديم" وتفترض بصمت أن عملية البناء لديك حتمية وأن بيئتك لم تتغير منذ ذلك الحين. هنا التراجع هو استعادة لنسخة معروفة الصلاحية، ولهذا فهو آمن اللجوء إليه تحت الضغط — لست بحاجة لأن تفكر فيما إذا كانت الاستعادة قد تتصرف بشكل مختلف عن الشيء الذي تستعيده.
واللحظة التي تحتاجه فيها فعليًا ليست لحظة هادئة أبدًا؛ إنها "البناء الجديد كسر الدفع والزوار موجودون الآن مباشرة".
نقرة واحدة، الإصدار السابق مُستعاد، انتهى الأمر. المنطق وراء اعتبار هذا ميزة أساسية لا فكرة لاحقة موجود في التكرار دون خوف — يستحق القراءة مرة واحدة، قبل أن تحتاجه. كل من السجل وعنصر تحكم الاستعادة موجودان في بطاقة البناء وفي عرض سجل الوجهة الخاصة به.
هل يحفظ هذا قاعدة بياناتي أيضًا؟
لا، وأفضّل أن أقول ذلك بوضوح بدلًا من ترك أي أحد يفترض غير ذلك. سجل الإصدارات على المضيف يغطي ما وضعه خط أنابيب النشر هذا في جذر الويب. إذا كان لموقعك قاعدة بيانات، أو ملفات مرفوعة من المستخدمين، أو أي شيء آخر يتغير خارج عمليات النشر، فذلك أمر منفصل تمامًا — التراجع لا يلمسه ولا ينبغي الخلط بينه وبين استراتيجية نسخ احتياطي تفعل ذلك.
