بيئة التجربة: جرّب تغييرات موقعك بأمان، واعرف ما يفعله زرّ النشر

في صفحة الدعم التي تشرح فيها Hostinger أداة بيئة التجربة عندها جملةٌ يمرّ عليها أكثر الناس دون أن يقفوا عندها. تقول إنّ النشر يستبدل ملفّات موقعك الحيّ وقاعدة بياناته بنسخة التجربة، وكلّ تغييرٍ حدث على الموقع الحيّ بعد إنشاء نسخة التجربة سيُكتب فوقه ويضيع دون رجعة.^[1] إن كان موقعك متجرًا، فكلّ طلبٍ وصله في أيّام التجربة يضيع مع ضغطة الزرّ. هذا المقال عن بيئة التجربة: لماذا تحتاجها، وكيف تعمل، ولماذا يكون أصعب ما فيها هو الطريق من التجربة إلى الموقع الحيّ.

أصبحت تملك في مقال SSH مفتاح الخادم، وهذا يعني أنّك تستطيع أن تكسر موقعك الحيّ بأمرٍ واحد، أو بتحديث إضافةٍ واحدة من لوحة ووردبريس في منتصف اليوم. بيئة التجربة هي المكان الذي تجرّب فيه ذلك التحديث أوّلًا.

ما هي بيئة التجربة

بيئة التجربة، واسمها الشائع staging، نسخةٌ من موقعك على عنوانٍ آخر لا يزوره أحد: ملفّاته نفسها، وقاعدة بياناته نفسها، وإضافاته وقالبه وإعداداته. تحدّث فيها إضافة، أو تجرّب قالبًا جديدًا، أو تغيّر إصدار PHP، فإن انكسر شيءٌ انكسر في النسخة، والموقع الذي يزوره الناس يعمل كما هو دون أن يعرف بشيء.

وووردبريس نفسه يعرف هذه الفكرة. منذ الإصدار 5.5 فيه دالّةٌ تعيد نوع البيئة التي يعمل فيها الموقع، ويحدّدها صاحب الموقع بثابتٍ في ملفّ الإعدادات. تقول وثائقها إنّ القيم الممكنة أربع: محلّيّة، وتطوير، وتجربة، وإنتاج، وإنّ الموقع يُعدّ موقع إنتاجٍ إن لم تحدّد شيئًا.^[2] والفائدة أنّ الإضافات تستطيع أن تقرأ هذه القيمة فتتصرّف بحسبها، فتعطّل مثلًا إرسال البريد إلى الزبائن حين تعرف أنّها في بيئة تجربة:

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

هذا السطر يوضع في ملفّ الإعدادات في نسخة التجربة وحدها، لا في الموقع الحيّ. وكثيرٌ من الاستضافات التي تنشئ لك بيئة تجربةٍ بنقرة تضبطه عنك، فافتح الملفّ وتأكّد قبل أن تعتمد على أنّ الإضافات تعرف أين هي.

وللقيمة أثرٌ في ووردبريس نفسه أيضًا. تقول الوثائق نفسها إنّ الموقع حين يكون نوعه «تطوير» يفعّل وضع تتبّع الأخطاء تلقائيًّا، إن لم يكن صاحب الموقع قد حدّد غير ذلك في ملفّ الإعدادات.^[2] ولهذا لا تضع هذه القيمة على موقعٍ حيٍّ بالخطأ، فتظهر رسائل الأخطاء لزوّارك وأنت لا تعرف لماذا.

لماذا لا تجرّب على الموقع الحيّ

لأنّ أكثر ما يكسر مواقع ووردبريس لا يبدو خطرًا حين تفعله. تحديثٌ لإضافةٍ تتعارض بعده مع قالبك، أو قالبٌ جديدٌ يحتاج إصدار PHP أحدث من إصدار خادمك، أو إضافة تخزينٍ مؤقّتٍ تحفظ صفحة الدفع وتعرضها لكلّ الزبائن بالمحتوى نفسه. كلّ واحدٍ من هذه يبدو زرًّا عاديًّا في لوحة الإدارة، ونتيجته قد تكون صفحةً بيضاء أمام كلّ زائرٍ يصل في تلك الدقائق.

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

ولا أقول إنّ كلّ تغييرٍ يحتاج بيئة تجربة. تصحيح خطأٍ إملائيٍّ في مقال، أو تغيير صورةٍ في صفحة، أو نشر مقالٍ جديد، كلّها تغييراتٌ في المحتوى تفعلها على الموقع الحيّ مباشرة. والقاعدة العمليّة بسيطة: إن كان التغيير يمسّ كيف يعمل الموقع، من تحديثٍ أو إضافةٍ أو قالبٍ أو شيفرةٍ أو إعدادات خادم، فمكانه التجربة أوّلًا مهما بدا صغيرًا. وإن كان يمسّ ما يقوله الموقع فقط، فمكانه الموقع الحيّ.

ثلاث بيئات، واتّجاهان

في العمل الاحترافيّ يمرّ التغيير غالبًا بثلاثة أماكن. الأوّل بيئةٌ محلّيّةٌ على جهازك، تبني فيها وتجرّب بسرعةٍ دون إنترنت. والثاني بيئة التجربة على خادمٍ يشبه خادمك الحقيقيّ، تختبر فيها التغيير في ظروفٍ قريبةٍ من الواقع. والثالث بيئة الإنتاج، وهو الاسم المهنيّ للموقع الحيّ الذي يزوره الناس.

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

شكل 1

ولست مضطرًّا للبيئات الثلاث كلّها. صاحب موقعٍ بسيطٍ يكفيه غالبًا بيئة تجربةٍ تنشئها استضافته إلى جانب الموقع الحيّ، ومن يكتب شيفرةً لقالبه أو إضافاته يحتاج البيئة المحلّيّة أيضًا. والمهمّ في الحالتين أن تعرف اتّجاه كلّ نوعٍ من التغييرات قبل أن تنقله.

وقد مررت بفكرةٍ قريبةٍ من هذه دون أن تسمّيها. في مقال نقل الموقع كانت الاستضافة الجديدة، في أيّام البناء والاختبار، بيئة تجربةٍ بالمعنى نفسه. كانت نسخةً كاملةً من موقعك لا يزورها أحد، تختبرها بملفّ المضيفات على حاسوبك وحده، والموقع القديم يخدم الناس كالمعتاد. والفرق أنّ النقل ينتهي بتحويل الزوّار إلى النسخة الجديدة، أمّا التجربة فتنتهي بنقل ما نجح فيها إلى الموقع القديم نفسه، والنسخة تُحذف. وفي الحالتين يبقى المبدأ واحدًا: لا يرى الزوّار شيئًا لم تجرّبه أنت أوّلًا.

أين تنشئ بيئة التجربة

أسهل طريقٍ أن تنشئها لك الاستضافة. رأيت في مقال الاستضافة المُدارة لووردبريس أنّ هذه من الميزات التي تدفع لأجلها، لكنّها لم تعد حكرًا عليها. تقول Hostinger إنّ أداة التجربة متاحةٌ في خطّة الأعمال فما فوق في استضافتها المشتركة: تنشئ النسخة على نطاقٍ فرعيّ، وتجرّب فيها، ثمّ تنشرها بزرّ.^[1] وفي Kinsta لكلّ موقعٍ بيئة تجربةٍ خاصّة، تنشئها من لوحتها بنسخ الموقع الحيّ.^[3]

والطريق الثاني أن تنشئها بيدك إن لم تكن استضافتك تعطيك الأداة. تنسخ الموقع إلى نطاقٍ فرعيّ بالطريقة التي رأيتها في مقال نقل الموقع، مع استبدال العنوان في قاعدة البيانات بأداةٍ تفهم البيانات المسلسَلة. الخطوات نفسها، والفرق أنّ الوجهة هذه المرّة نسخةٌ لا يزورها أحد، والموقع القديم يبقى هو الموقع الحيّ.

والطريق الثالث على جهازك دون خادم أصلًا. من الأدوات التي يقدّمها مشروع ووردبريس نفسه أداةٌ اسمها Playground تشغّل ووردبريس كاملًا في المتصفّح. تقول صفحتها إنّك تستطيع بها أن تنسخ موقعك وتجرّب في مساحةٍ خاصّة، وأن تختبر مع إصداراتٍ مختلفةٍ من ووردبريس وPHP.^[4] هذا مفيدٌ لتجربة إضافةٍ لا تعرفها قبل أن تنصّبها في أيّ مكان، أو لترى هل يعمل قالبك على إصدار PHP الأحدث.

ثلاث تجارب تستحقّ النسخة في 2026

أوّلها ترقية إصدار PHP. يقول مشروع PHP إنّ الدعم الأمنيّ للإصدار 8.2 ينتهي في 31 ديسمبر 2026، أي بعد ثلاثة أشهرٍ من كتابة هذا المقال.^[5] فإن كان موقعك يعمل على هذا الإصدار أو أقدم منه، فالترقية آتيةٌ هذا الشتاء، إمّا بقرارك أو بقرار استضافتك. وقد رأيت في مقال النقل أنّ إضافةً قديمةً واحدةً قد تتوقّف عن العمل على الإصدار الأحدث. فاجعل الترقية أوّل ما تجرّبه في النسخة: غيّر الإصدار فيها من لوحة الاستضافة، وتصفّح الموقع كلّه، ثمّ غيّره على الموقع الحيّ حين تطمئنّ.

وثانيها التحديثات التلقائيّة. منذ الإصدار 5.5 يستطيع مدير موقع ووردبريس أن يفعّل التحديث التلقائيّ لكلّ إضافةٍ ولكلّ قالبٍ على حدة. وتقول وثائق ووردبريس إنّه يشغّل هذه التحديثات مرّتين في اليوم افتراضيًّا، ويرسل رسالةً إلى صاحب الموقع بعد كلّ محاولة، ناجحةً كانت أو فاشلة.^[6] وهذا مريحٌ للإضافات الصغيرة التي لا يعتمد عليها موقعك، لكنّه يعني أنّ التحديث يصل إلى الموقع الحيّ دون أن يمرّ بالتجربة. فاختر بيدك: الإضافات التي يقوم عليها موقعك، كإضافة المتجر وإضافة الدفع والقالب، تُحدَّث في النسخة أوّلًا، وما عداها يمكن أن يبقى تلقائيًّا.

وثالثها قراءة الأخطاء. حين يظهر في موقعك سلوكٌ غريبٌ بعد تحديث، فأوّل ما تحتاجه رسالة الخطأ الحقيقيّة، وووردبريس يخفيها عن الزوّار افتراضيًّا. في نسخة التجربة تستطيع أن تطلب منه أن يكتبها في ملفٍّ دون أن يعرضها على الصفحة، بثلاثة أسطرٍ في ملفّ الإعدادات تنشرها وثائق ووردبريس بنفسها:^[7]

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

بعدها تُكتب كلّ الأخطاء والتحذيرات في ملفٍّ اسمه debug.log داخل مجلّد wp-content، فتفتحه وترى اسم الإضافة والسطر الذي انكسر. وتقول الوثائق نفسها إنّ هذه الأدوات لا يُنصح بها على المواقع الحيّة، وإنّها صُنعت للتجربة المحلّيّة ونسخ التجربة.^[7] والسبب عمليّ: ملفّ السجلّ قد يكبر بسرعة، وقد يكشف لمن يصل إليه مسارات ملفّاتك وتفاصيل إضافاتك. فهذه الأسطر مكانها النسخة وحدها، واحذفها منها قبل أن تنشر أيّ ملفّ إعداداتٍ إلى الموقع الحيّ.

أربعة أشياء تختلف في نسخة التجربة

نسخة التجربة الجيّدة تشبه الموقع الحيّ في كلّ شيءٍ إلّا أربعة، وكلّ واحدٍ منها إن نسيته صنع مشكلةً على الموقع الحيّ نفسه. الأوّل محرّكات البحث. النسخة مطابقةٌ لموقعك، فإن فهرسها محرّك بحثٍ صار عندك موقعان بالمحتوى نفسه. ويقول Google إنّ ملفّ منع الزحف لا يمنع ظهور الصفحة في نتائجه، وإنّ الطريق لذلك وسم منع الفهرسة أو حماية الصفحة بكلمة مرور.^[8]

وفي هذا تفصيلٌ يقع فيه كثيرون: إن منعت الزحف بملفّ المنع ووضعت وسم منع الفهرسة معًا، فالزاحف لا يصل إلى الصفحة ليقرأ الوسم. تقول وثائق Google صراحةً إنّ الصفحة المحجوبة بملفّ المنع لا يرى الزاحف وسمها، وقد تظهر في النتائج إن أشارت إليها صفحاتٌ أخرى.^[9] فالأضمن كلمة مرورٍ على النسخة كلّها. وKinsta مثلًا تفعّل في نسخ التجربة خيار ووردبريس الذي يطلب من محرّكات البحث ألّا تفهرس الموقع، وتضيف إلى عناوينها ترويسة منع فهرسةٍ لا يمكن إزالتها.^[3]

والثاني البريد. نسخة متجرك فيها عناوين زبائنك الحقيقيّين، فإن جرّبت فيها إعادة إرسال رسالة، أو شغّلت مهمّةً مجدولة، وصلت رسالةٌ حقيقيّةٌ إلى زبونٍ حقيقيّ. والثالث الدفع. إضافة الاشتراكات في WooCommerce تحلّ هذا بنفسها. تقول وثائقها إنّها تحفظ عنوان الموقع الذي فُعّلت عليه أوّل مرّة، فإن رأت عنوانًا مختلفًا عدّت الموقع نسخة تجربة، وأوقفت الدفعات التلقائيّة ورسائل الاشتراكات كي لا يُدفع مبلغٌ مرّتين.^[10] لكن ليست كلّ إضافة دفعٍ بهذا الحرص، فاجعل بوّابة الدفع في نسخة التجربة على وضع الاختبار الذي تعطيه معظم البوّابات.

والرابع المهامّ المجدولة. تقول Kinsta إنّ مهامّ الخادم المجدولة في الموقع الحيّ لا تعمل في نسخة التجربة، حتى لو نسخت الموقع الحيّ كلّه. وتنبّه إلى أنّك إن عدّلت جدول المهامّ في التجربة ثمّ نشرتها، كُتب جدولها فوق جدول الموقع الحيّ.^[3] فلا تفترض أنّ نسخة التجربة ترسل النسخ الاحتياطيّة أو تنظّف الملفّات كما يفعل الموقع الحيّ، ولا تنشر منها تعديلًا على المهامّ المجدولة دون أن تقصده.

زرّ النشر: أصعب ما في التجربة

عد إلى الجملة التي بدأ بها المقال. الموقع الحيّ لا يتوقّف وأنت تجرّب: تصله طلبات، ويكتب الزوّار تعليقات، ويسجّل مستخدمون جدد. فإن نشرت نسخة التجربة كاملةً بملفّاتها وقاعدة بياناتها، عادت قاعدة البيانات إلى لحظة إنشاء النسخة، وضاع كلّ ما بينهما. هذا هو الاتّجاه الخطأ في الشكل 1: بياناتٌ قديمةٌ تصعد فوق بياناتٍ أحدث منها.

والاستضافات لا تتصرّف كلّها بالطريقة نفسها، فاعرف ما يفعله زرّ النشر عند استضافتك قبل أن تضغطه. في Hostinger، كما رأيت، يستبدل النشر الملفّات وقاعدة البيانات معًا. وفي Kinsta نشرٌ انتقائيّ: تختار أن تنشر الملفّات وحدها، أو قاعدة البيانات كلّها، أو جداول بعينها منها. وتقول وثائقها بوضوح إنّ لوحتها لا تميّز بين الطلبات القديمة والجديدة في متاجر WooCommerce، وإنّ نشر الملفّات وقاعدة البيانات معًا يكتب فوق الموقع الحيّ كما هو في التجربة. ولهذا تقترح أن تنشر الملفّات وحدها، أو جداول قاعدة البيانات دون جداول المتجر.^[11]

والحلّ العمليّ الذي يغنيك عن أكثر هذه التعقيدات هو الشكل 1 نفسه: اجعل بيئة التجربة للملفّات، واترك البيانات حيث تولد. حدّث الإضافات وجرّب القالب في التجربة، فإن نجح كلّ شيء، طبّق التحديث نفسه على الموقع الحيّ، أو انشر الملفّات وحدها إن كانت استضافتك تسمح. ولا تنشر قاعدة البيانات من التجربة إلّا إن كان التغيير نفسه في قاعدة البيانات، وكان الموقع الحيّ هادئًا، وأوقفت الشراء والتعليقات في تلك الدقائق القليلة.

وقبل أيّ نشر، خذ نسخةً احتياطيّةً من الموقع الحيّ. Kinsta تأخذها تلقائيًّا قبل كلّ نشر، وتنبّه في الوقت نفسه إلى أنّ ما يُنشأ في المتاجر بين النشر والرجوع إلى النسخة قد يضيع أيضًا.^[11] فالنسخة الاحتياطيّة تنقذك من نشرٍ فاشل، ولا تنقذك من طلبٍ وصل بعد النشر ثمّ رجعت إلى ما قبله. وقد رأيت في مقال الأمان والنسخ الاحتياطيّ كيف تحسب ما تقبل أن تخسره.

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

نسخةٌ حديثة لكلّ تجربة

نسخة التجربة تشيخ بسرعة. بعد أسبوعين يكون الموقع الحيّ قد حُدّث، وأضيفت إليه مقالاتٌ وإضافات، فصار ما تجرّبه في النسخة القديمة تجربةً على موقعٍ آخر. ولهذا الأفضل أن تنشئ نسخةً جديدةً من الموقع الحيّ قبل كلّ تجربةٍ مهمّة، أو أن تحدّث النسخة القائمة منه. وهذا هو الاتّجاه الصحيح للبيانات في الشكل 1: من الحيّ إلى التجربة.

وحين تنتهي من التجربة وتطبّق ما نجح، فكّر في حذف النسخة. نسخةٌ قديمةٌ منسيّةٌ على نطاقٍ فرعيّ فيها إضافاتٌ لا تحدّثها وقاعدة بياناتٍ فيها بيانات زبائنك، وهذه ثغرةٌ لا يراقبها أحد. أنشئ النسخة حين تحتاجها، واحذفها حين تنتهي، وأنشئ غيرها في المرّة القادمة.

وتذكّر أنّ بيانات النسخة حقيقيّة: فيها أسماء زبائنك وعناوينهم وبريدهم كما هي في الموقع الحيّ. وقد رأيت في مقال كيف تختار استضافة موقعك أنّ السعوديّة والإمارات والاتّحاد الأوروبيّ تضع شروطًا لمعالجة البيانات الشخصيّة ونقلها. نسخة التجربة معالجةٌ لهذه البيانات أيضًا، فاحمِها بما تحمي به الموقع الحيّ. ولا تنقلها إلى جهازك أو إلى أداةٍ خارجيّةٍ دون حاجة، وإن احتجت نسخةً للتجربة على جهازك، فامسح منها بيانات الزبائن أو استبدلها ببياناتٍ وهميّةٍ قبل النقل.

أخطاء شائعة

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

والخطأ الرابع أن تنسى البريد والدفع في النسخة، فتصل رسالة تجربةٍ إلى زبونٍ حقيقيّ، أو تُسحب دفعةٌ من بطاقته مرّةً ثانية. والخطأ الخامس أن تجرّب على نسخةٍ قديمة، فيعمل التحديث فيها ويفشل على الموقع الحيّ الذي تغيّر عنها. والخطأ السادس النشر دون نسخةٍ احتياطيّةٍ من الموقع الحيّ، لأنّ التجربة نجحت، والتجربة الناجحة لا تضمن أنّ النشر نفسه سينجح.

والخطأ السابع أن تنشر ملفّ الإعدادات من التجربة إلى الموقع الحيّ كما هو، ومعه سطر نوع البيئة وأسطر تتبّع الأخطاء. فيعمل موقعك الحيّ وهو يظنّ نفسه نسخة تجربة، فتوقف بعض الإضافات فيه البريد أو الدفع، أو تُكتب أخطاؤه في ملفٍّ مكشوف. ملفّ الإعدادات يختلف بين البيئتين عمدًا، فلا تنقله بينهما أبدًا.

جرّبه بنفسك

افتح لوحة استضافتك وابحث عن كلمة «Staging» أو «بيئة التجربة». إن وجدتها، فاقرأ قبل أيّ شيءٍ صفحة المساعدة التي تشرح زرّ النشر، واعرف هل ينشر الملفّات وحدها أم قاعدة البيانات أيضًا. ثمّ أنشئ نسخة، وافتحها، وتأكّد من أمرين: أنّ خيار منع محرّكات البحث من الفهرسة مفعّلٌ في إعدادات القراءة فيها، وأنّها تطلب كلمة مرورٍ إن كانت استضافتك تسمح بذلك.

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

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

خلاصة عمليّة

جرّب في بيئة التجربة كلّ تغييرٍ يمسّ كيف يعمل موقعك، وغيّر المحتوى على الموقع الحيّ مباشرة. احمِ النسخة بكلمة مرورٍ ومنع فهرسة، وأوقف فيها البريد إلى الزبائن والدفع الحقيقيّ. وتذكّر اتّجاهي الشكل 1: الملفّات تصعد إلى الموقع الحيّ، والبيانات تنزل منه. ثمّ اقرأ ما يفعله زرّ النشر عند استضافتك قبل أن تضغطه، وخذ نسخةً احتياطيّةً قبل كلّ نشر، وابدأ كلّ تجربةٍ مهمّةٍ بنسخةٍ حديثة، واحذفها حين تنتهي.

بقي في هذه السلسلة سؤالٌ واحدٌ لم يمرّ به مقالٌ من قبل: هذه الخوادم كلّها، التي تستضيف موقعك ونسخة تجربته ونسخه الاحتياطيّة، تعمل على كهرباء في مراكز بياناتٍ حول العالم. كم تستهلك، ومن أين تأتي طاقتها، وماذا تعني الشركات حين تقول إنّ استضافتها خضراء؟ هذا موضوع المقال الأخير في السلسلة: الاستضافة الخضراء.

المصادر

1. ‏Hostinger، «How to create a WordPress staging environment at Hostinger» (قُرئت في 25 سبتمبر 2026): الأداة متاحةٌ في خطّة Business فما فوق؛ النشر يستبدل ملفّات الموقع الحيّ وقاعدة بياناته بنسخة التجربة، وكلّ تغييرٍ على الموقع الحيّ بعد إنشاء النسخة يُكتب فوقه ويضيع.
2. ‏WordPress Developer Resources، «wp_get_environment_type()» (قُرئت في 25 سبتمبر 2026): أُضيفت في الإصدار 5.5.0؛ تُضبط بالثابت WP_ENVIRONMENT_TYPE؛ القيم local وdevelopment وstaging وproduction، والافتراضيّ production.
3. ‏Kinsta، «Staging Environments» (حُدّثت في 15 يونيو 2026): بيئة تجربةٍ لكلّ موقع؛ خيار منع الفهرسة مفعّل وترويسة X-Robots-Tag: noindex لا تُزال؛ مهامّ الخادم المجدولة لا تعمل في التجربة، ونشر جدولٍ معدّلٍ يكتب فوق جدول الموقع الحيّ.
4. ‏WordPress.org، «WordPress Playground» (قُرئت في 25 سبتمبر 2026): تشغيل ووردبريس دون استضافة؛ نسخ الموقع والتجربة في مساحةٍ خاصّة؛ الاختبار مع إصداراتٍ مختلفةٍ من ووردبريس وPHP.
5. ‏مشروع PHP، «Supported Versions» (قُرئت في 24 سبتمبر 2026): الدعم الأمنيّ للإصدار 8.2 حتى 31 ديسمبر 2026، و8.3 حتى 31 ديسمبر 2027، و8.4 حتى 31 ديسمبر 2028، و8.5 حتى 31 ديسمبر 2029.
6. ‏WordPress.org Documentation، «Plugin and themes auto-updates» (قُرئت في 25 سبتمبر 2026): منذ ووردبريس 5.5 يفعّل المدير التحديث التلقائيّ لكلّ إضافةٍ وقالب؛ تجري التحديثات مرّتين في اليوم افتراضيًّا؛ رسائل بريدٍ بعد كلّ محاولة ناجحةً أو فاشلة.
7. ‏WordPress Developer Resources، «Debugging in WordPress» (قُرئت في 25 سبتمبر 2026): WP_DEBUG وWP_DEBUG_LOG وWP_DEBUG_DISPLAY تكتب الأخطاء في wp-content/debug.log وتخفيها عن الصفحة؛ لا يُنصح بها على المواقع الحيّة، فهي للتجربة المحلّيّة ونسخ التجربة.
8. ‏Google Search Central، «Introduction to robots.txt» (قُرئت في 25 سبتمبر 2026): ملفّ robots.txt ليس وسيلةً لإبقاء صفحةٍ خارج Google؛ استعمل noindex أو كلمة مرور.
9. ‏Google Search Central، «Block Search indexing with noindex» (قُرئت في 25 سبتمبر 2026): إن حُجبت الصفحة بملفّ robots.txt فلن يرى الزاحف قاعدة noindex، وقد تظهر في النتائج إن أشارت إليها صفحاتٌ أخرى.
10. ‏WooCommerce، «How Subscriptions Handles Staging Sites and Migrations» (قُرئت في 25 سبتمبر 2026): تحفظ الإضافة عنوان الموقع الأوّل، وحين يختلف العنوان تعمل في وضع التجربة وتوقف الدفعات التلقائيّة ورسائل الاشتراكات لمنع الدفع المكرّر.
11. ‏Kinsta، «Push Environments» (حُدّثت في 12 يونيو 2026): نشرٌ انتقائيّ للملفّات أو لكلّ الجداول أو لجداول محدّدة؛ لا تمييز بين الطلبات القديمة والجديدة في WooCommerce، فنشر الملفّات والقاعدة معًا يكتب فوق الموقع الحيّ؛ نسخةٌ احتياطيّةٌ تلقائيّة قبل النشر، وما يُنشأ في المتاجر بين النشر والرجوع قد يضيع.
12. ‏WordPress Developer Resources، «wp_robots_no_robots()» (قُرئت في 25 سبتمبر 2026): تضيف noindex إلى وسم robots، وتقرأ الخيار blog_public من قاعدة البيانات لتحديد follow أو nofollow.