لماذا بيئة تجريبية بدل الاختبار على الموقع المباشر
إضافة نماذج لم تعد تعمل، وقالب فقد تنسيقه، وشاشة «حدث خطأ فادح في هذا الموقع»: أعطال تأتي بعد تحديث بدا بسيطًا. مع ثلاثة مواقع تكفي الحيطة. أما مع ثلاثين موقعًا فإما أن تحدّث في الظلام وإما أن تتوقف عن التحديث، وعندها تصبح الثغرة غير المسدودة هي الكلفة.
البيئة التجريبية نسخة حية من الموقع على عنوان مستقل وبقاعدة بيانات خاصة بها. يمكنك أن تكسر فيها ما تشاء، وتقرأ الأخطاء، وتصلحها، ثم تعيد على الإنتاج الخطوة التي ثبتت صحتها. وهي لا تغني عن النسخة الاحتياطية: بل تجعل اللجوء إليها نادرًا.
ما تقدمه لك البيئة التجريبية
- تحديثات بلا مفاجآت — يُرى كل تغيير في النواة أو القالب أو الإضافات على الشاشة قبل أن يصل إلى الزوار.
- تشخيص مقروء — تذهب الأخطاء إلى سجل لا إلى أمام العميل، ويُعرف السبب قبل أن يتصل.
- مراجعة مشتركة — يعتمد العميل أو مدير مشروعه النتيجة على عنوان منفصل دون المساس بالموقع العام.
- سجل للتغييرات — تدوّن إصدار كل إضافة قبل التحديث وبعده، وتعيد على الإنتاج الشيء نفسه تمامًا.
- تجربة للجديد — قالب جديد أو منشئ صفحات جديد أو وحدة دفع جديدة: يُحكم على كل شيء على نسخة.
- تراجع جاهز — تُنجَز النسخة الاحتياطية وتُفحص قبل الاختبار لا بعد الحادث.
المتطلبات بالأرقام قبل النسخ
احسب ثلاثة أضعاف حجم الموقع المباشر من مساحة القرص: الموقع ونسخته وتصدير قاعدة البيانات. اعرف حجم wp-content بالأمر du -sh wp-content وحجم قاعدة البيانات في phpMyAdmin أو بالأمر wp db size. خصّص نطاقًا فرعيًا لكل عميل، مثل staging.your-domain.com، واستخدم إصدار PHP نفسه المستخدم في الإنتاج: بيئة تجريبية بإصدار أحدث تعتمد إعدادًا ليس إعداد العميل. يظهر هذا الإصدار في الأدوات › سلامة الموقع › المعلومات، والإصدارات المدعومة حاليًا محدّثة في php.net/supported-versions.php.
تحتاج أيضًا إلى طرفية فيها wp-cli (اتصال SSH على حساب يسمح به، أو خادم VPS). يصف هذا الدليل النسخ اليدوي، الملفات ثم قاعدة البيانات، وهو يُظهر بالضبط ما يُنسخ. وإن كان WP Toolkit متاحًا في حسابك فإن استنساخه ينتج هذه النسخة بدلًا عنك (راجع دليل «تثبيت ووردبريس من cPanel»)؛ ويبقى باقي الدليل (noindex والمصادقة وإيقاف البريد والاختبارات) سارياً كما هو. لتثبيت موقع جديد من cPanel راجع الدليل المخصص لذلك.
إنشاء البيئة التجريبية خطوة بخطوة
خذ نسخة احتياطية من الإنتاج قبل أي كتابة
من مجلد الموقع المباشر:
mkdir -p ~/preprod-backupswp db export ~/preprod-backups/before-staging.sql --single-transactiontar -czf ~/preprod-backups/files-before-staging.tar.gz -C ~/public_html .
تأكد من وجود الملفين ومن أنهما غير فارغين بالأمرls -lh ~/preprod-backups. النسخ الاحتياطية للباقة لا تغني عن هذه الخطوة: فتكرارها يختلف بحسب الباقة، وقد يعود تاريخها إلى عدة أيام.أنشئ النطاق الفرعي ومجلده
أنشئ
staging.your-domain.comفي cPanel (يشرح دليل «إنشاء نطاق فرعي في cPanel» الشاشة) مع مجلد جذر خاص به، ويُفضَّل خارجpublic_html، مثل~/staging.your-domain.com. المجلد الموضوع داخلpublic_htmlيمكن بلوغه أيضًا من عنوان في الموقع المباشر. انتظر حتى تُصدَر شهادة TLS للنطاق الفرعي قبل الاختبار.انسخ الملفات
rsync -a --exclude='wp-content/cache/' ~/public_html/ ~/staging.your-domain.com/
كيّف مسار المصدر مع مجلد جذر موقع العميل. بلا طرفية، يتيح مدير ملفات cPanel ضغط المجلد ونقله ثم استخراجه في مجلد النطاق الفرعي.أنشئ قاعدة بيانات ومستخدمًا مخصصين
في قسم قواعد بيانات MySQL في cPanel، أنشئ قاعدة جديدة ومستخدمًا، وامنحه كل الصلاحيات على هذه القاعدة وحدها. ثم افتح
wp-config.phpالخاص بالنسخة وغيّرDB_NAMEوDB_USERوDB_PASSWORD. هذا أغلى خطأ في هذا الدليل: نسخwp-config.phpدون تغيير هذه الأسطر الثلاثة يجعل البيئة التجريبية تكتب في قاعدة بيانات الإنتاج.استورد قاعدة البيانات
من مجلد النسخة:
cd ~/staging.your-domain.comwp db import ~/preprod-backups/before-staging.sqlwp option get siteurl
يجب أن يعرض الأمر الأخير عنوان الإنتاج بعد: هذا طبيعي، فالعناوين لم تُستبدل بعد. وإن فشل فإنwp-config.phpما زال يشير إلى قاعدة بيانات خاطئة.استبدل العناوين، مع تجربة جافة أولًا
wp search-replace 'https://your-domain.com' 'https://staging.your-domain.com' --all-tables --skip-columns=guid --dry-run
اقرأ التقرير: يسرد الجداول وعدد الاستبدالات. ثم أعد الأمر نفسه دون--dry-run. يخزّن ووردبريس إعدادات كثيرة في بيانات متسلسلة (serialized) تحمل فيها كل سلسلة طولها: أمرsedعلى ملف التصدير يغيّر طول العنوان دون تصحيح هذا العدد فتصبح الإعدادات غير مقروءة. أماwp search-replaceفيفهم هذه البيانات ويعيد كتابتها بشكل صحيح.اضبط إعدادات البيئة التجريبية في wp-config.php
أضف فوق السطر «That's all, stop editing»:
define('WP_ENVIRONMENT_TYPE', 'staging');define('DISABLE_WP_CRON', true);define('DISALLOW_FILE_EDIT', true);define('WP_DEBUG', true);define('WP_DEBUG_LOG', true);define('WP_DEBUG_DISPLAY', false);
تذهب الأخطاء إلىwp-content/debug.logدون أن تظهر للزوار. الثابتWP_ENVIRONMENT_TYPEموجود منذ ووردبريس 5.5 ويقبلlocalوdevelopmentوstagingوproduction: يسمح للقوالب والإضافات بالتكيف، لكنه لا يخفي الموقع عن محركات البحث، ومن هنا الخطوة التالية.أغلق الوصول واطلب noindex
في الإعدادات › القراءة، فعّل «منع محركات البحث من فهرسة هذا الموقع»، أو من سطر الأوامر:
wp option update blog_public 0. ثم أضف مصادقة HTTP إلى مجلد النسخة: ملف.htpasswdيُنشأ بالأمرhtpasswd -c ~/.htpasswd-staging client، ثم في ملف.htaccessالخاص بالمجلد التوجيهاتAuthType BasicوAuthName "Preproduction"وAuthUserFileالذي يشير إلى هذا الملف وRequire valid-user. وإن تعذّر ذلك فقيّد الوصول بقائمة عناوين IP.افحص النسخة كما يفعل الروبوت
curl -sI https://staging.your-domain.com/
يجب أن يكون الرد401. ثم بالبيانات:curl -s -u client https://staging.your-domain.com/ | grep -i robots
يجب أن تظهر وسمmeta name='robots'يحتوي علىnoindex. وإن استبدلته إضافة تخزين مؤقت أو إضافة سيو فهي التي ينبغي ضبطها. وأخيرًا تحقق من أن القالب لا يحتوي على عنوان إنتاج مكتوب يدويًا:grep -r "https://your-domain.com" wp-content/themes.اربط البيئة التجريبية بروتين الوكالة
اجعل هذا الإعداد نموذجًا: نطاق فرعي لكل عميل، في حساب cPanel الخاص بالعميل، مع قائمة التحقق نفسها. ترتيب العمليات لنقل موقع إلى استضافة أخرى يتناوله دليل «نقل موقع ووردبريس لعميل دون توقف»؛ أما البيئة التجريبية الموصوفة هنا فهي أداة دائمة لا خطوة من خطوات التحويل.
العزل الحقيقي: noindex وحده لا يكفي
يطلب noindex من محركات البحث ألا تحتفظ بصفحة، لكنه لا يمنع أحدًا من قراءتها. البيئة التجريبية المفتوحة للجميع ينتهي بها الأمر في رابط مُلصق في تذكرة أو خريطة موقع أو لقطة شاشة، وعندها تنشر محتوى مكررًا عن الإنتاج. والحمايتان متكاملتان: noindex يطلب من المحركات عدم الفهرسة، ومصادقة HTTP أو قائمة عناوين IP تمنع الوصول.
فخ واحد: إن حجبت النطاق الفرعي عبر robots.txt فلن يقرأ الروبوت الصفحة ولن يرى وسم noindex أبدًا. ومع وجود المصادقة لا فائدة من هذا الملف.
تعطيل البريد والمدفوعات والمهام المجدولة
تحتوي النسخة على عملاء الموقع الحقيقيين: مشتركون ومشترون وعناوين طلبات. يجب إيقاف كل ما يُرسل تلقائيًا قبل أي اختبار، وإلا خرج تذكير سلة متروكة أو تذكير موعد أو تجديد اشتراك مرتين من النسخة. تُطلَق المهام المجدولة في ووردبريس بالزيارات: في البيئة التجريبية عطّلها بـ DISABLE_WP_CRON وشغّلها يدويًا بالأمر wp cron event run --due-now حين تريد اختبارها.
قائمة التحقق قبل لمس أي إضافة
- البريد — إضافة الإرسال في وضع الاختبار أو محوّلة إلى صندوق للمراجعة، وإشعارات المتجر متوقفة.
- المدفوعات — البوابة في وضع الاختبار، ومفاتيح الإنتاج مسحوبة من النسخة، وعناوين الاستدعاء (webhooks) غير مسجلة للبيئة التجريبية.
- المهام المجدولة —
DISABLE_WP_CRONمضبوط، والأحداث المعلقة مسرودة بالأمرwp cron event list. - تعديل الملفات —
DISALLOW_FILE_EDITمفعّل حتى لا يُعدَّل الكود من لوحة الإدارة. - سجل الأخطاء —
WP_DEBUG_LOGمفعّل وWP_DEBUG_DISPLAYعلىfalse. - التكاملات الخارجية — أنظمة العملاء والأدلة وأدوات الإحصاء ومفاتيح API الخاصة بالإنتاج مستبدلة أو مسحوبة.
- محركات البحث — noindex مضبوط والمصادقة قائمة، مع فحص ذلك بـ
curlكما سبق.
اختبر التحديثات واحدًا تلو الآخر
اسرد ما ينتظر التحديث بالأمر wp plugin list --update=available. ثم حدّث إضافة واحدة في كل مرة: wp plugin update plugin-name، وتصفّح الصفحات المهمة (الرئيسية ونموذج الاتصال والسلة وتسجيل الدخول) واقرأ نهاية السجل بالأمر tail -n 30 wp-content/debug.log. لا تنتقل إلى التالية إلا حين يهدأ السجل. افعل الشيء نفسه مع القالب بالأمر wp theme update theme-name ثم مع النواة بالأمر wp core update.
دوّن في سجل التغييرات لكل سطر الإصدار قبل التحديث والإصدار بعده. هذه هي القائمة التي ستعيدها على الإنتاج إصدارًا بإصدار بدل نسخ أي شيء.
حين يكسر التحديث الموقع: قراءة debug.log
العَرَض الكلاسيكي هو شاشة «حدث خطأ فادح في هذا الموقع». يدخل ووردبريس عندها في وضع الاسترداد ويرسل رابطًا إلى عنوان الإدارة، وهذا يفترض أن إرسال البريد يعمل: وهو معطّل في البيئة التجريبية، فلا تنتظره. السبب موجود في السجل: tail -n 40 wp-content/debug.log. ابحث عن آخر سطر يبدأ بـ PHP Fatal error، مثل Call to undefined function أو Cannot declare class، ودوّن مسار الملف: المجلد الواقع تحت wp-content/plugins/ يسمّي الإضافة المعطوبة. عطّلها دون المرور بلوحة الإدارة بالأمر wp plugin deactivate plugin-name، فيعود الموقع وتعرف المتسبب.
استكشاف الأخطاء: الأعراض الأخرى التي تصادفها فعلًا
- الموقع يحوّل إلى الإنتاج — ما زال
wp option get siteurlوwp option get homeيعرضان العنوان القديم، أو أن منشئ الصفحات يحتفظ بعناوين مكتوبة يدويًا؛ أعد الاستبدال، مع--preciseعند الحاجة. - «Error establishing a database connection» — قيم
DB_NAMEأوDB_USERأوDB_PASSWORDأوDB_HOSTفي النسخة خاطئة، أو أن المستخدم لا يملك صلاحيات على القاعدة الجديدة. - صور أو أنماط تُحمَّل من الإنتاج — العناوين المهرّبة، مثل
https:\/\/في بيانات JSON الخاصة بمنشئي الصفحات، أفلتت من الاستبدال؛ أعده بهذه الصيغة. - حلقة تسجيل دخول أو خروج فوري — ملفات تعريف الارتباط تخص النطاق القديم؛ امسحها وتحقق من
siteurlوhome. - البيئة التجريبية تظهر في محرك بحث — وُضع noindex متأخرًا أو أن إضافة تستبدله؛ انتقل إلى مصادقة HTTP واطلب إزالة العنوان.
الملفات أم قاعدة البيانات: ما الذي يُنقل وكيف
مرّر الجدول أفقيًا
| العنصر | أين يعيش | كيف يُنقل إلى الإنتاج |
|---|---|---|
| القالب والقالب الفرعي | ملفات | انشر المجلد المعتمد، أو أعد `wp theme update` بالإصدار الذي اختبرته |
| الإضافات | ملفات | أعد `wp plugin update plugin-name --version=X` بالإصدار الذي اختبرته |
| الإضافات الإلزامية (mu-plugins) | ملفات | انسخ الملف المعتمد مع حفظ القديم بجانبه |
| الوسائط المرفوعة (uploads) | ملفات | لا تدفعها أبدًا من البيئة التجريبية إلى الإنتاج: فالإنتاج يواصل استقبال وسائط جديدة |
| إعدادات الإضافات | قاعدة البيانات (الخيارات) | أعد الإعداد يدويًا على الإنتاج، أو `wp option update` مع تسمية الخيار |
| الطلبات والنماذج والحسابات والتعليقات | قاعدة البيانات | لا تطمسها أبدًا: هذه البيانات تعيش في جهة الإنتاج |
| جداول ينشئها تحديث | قاعدة البيانات | دع الإضافة تنشئها بإعادة التحديث على الإنتاج |
النقل إلى الإنتاج، وإمكان العودة
في موقع فيه معاملات لا تستورد أبدًا قاعدة بيانات البيئة التجريبية في الإنتاج: أثناء اختباراتك وصلت طلبات وتسجيلات وإدخالات نماذج على الإنترنت، والاستيراد يمحوها. أعد بدلًا من ذلك تنفيذ التغييرات المعتمدة. التسلسل: نسخة احتياطية حديثة (wp db export وأرشيف الملفات كما في الخطوة 1)، ثم wp maintenance-mode activate، ثم التحديثات بالترتيب وبالإصدارات المدوّنة في السجل، ثم فحص الصفحات الأساسية، ثم wp maintenance-mode deactivate.
للتراجع، استعد الملفات أولًا: wp plugin install plugin-name --version=old --force أو أرشيف الخطوة 1. لا تستعد قاعدة البيانات إلا كحل أخير، وفقط إن كان التحديث قد غيّر جداول: سيضيع كل ما أُدخل منذ النسخة الاحتياطية، لذا يجب ألا يتجاوز عمر التصدير بضع دقائق. احتفظ بالنسخة الاحتياطية حتى يعتمد العميل الموقع المباشر.
عادة التحصين
بعد اعتماد التحديث، احذف نسخة قاعدة بيانات الإنتاج المتروكة في ~/preprod-backups وفي البيئة التجريبية: فالتصدير الكامل يحتوي على عناوين العملاء وطلباتهم وبصمات كلمات مرورهم. ولا تترك WP_DEBUG مفعّلًا على الموقع المباشر، فقد يحتوي السجل على مسارات واستعلامات.
روتين يصمد على مستوى محفظة مواقع
تُقاس البيئة التجريبية بانضباطها: الإعداد نفسه دائمًا، وقائمة التحقق نفسها، والسجل نفسه. وبالنسبة إلى وكالة يتسع الروتين في نموذج إجراء: نطاق فرعي لكل عميل، وقاعدة بيانات مخصصة، وnoindex مع المصادقة، وبريد متوقف، وتحديثات واحدًا واحدًا، ونشر بإعادة التنفيذ. ويعمل ذلك بصورة أفضل حين يعيش كل موقع عميل في حسابه الخاص بنسخه الاحتياطية وصلاحيات وصوله المنفصلة.
