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

هذا المقال عن الصيانة الدورية وعلاج الأعطال. أما سرعة الموقع فلها دليل مستقل لتسريع WordPress، وأما مبادئ عمل مساعد العمليات نفسه فتجدها في مقال عمليات الذكاء الاصطناعي.

ما الذي تشمله صيانة WordPress؟

الصيانة ليست ضغطة «تحديث الكل» مرة في الشهر. هي مجموعة مهام لكل منها إيقاع ومخاطرة مختلفة:

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

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

كيف تحدّث WordPress دون أن تكسر الموقع؟

القاعدة: التحديث على الموقع الحي هو آخر خطوة، لا أولها.

1. خذ نسخة احتياطية قبل التحديث مباشرة

النسخة الليلية قد يكون عمرها عشرين ساعة، وفي متجر نشط تعني هذه الساعات طلبات جديدة. خذ نسخة من الملفات وقاعدة البيانات قبل التحديث، وتأكد من أنها تُستعاد فعلًا. المبدأ العام في استراتيجية النسخ الاحتياطي 3-2-1.

2. اعمل على نسخة تجريبية

النسخة التجريبية (Staging) نسخة من الموقع وقاعدة بياناته على عنوان منفصل. حدّث فيها أولًا. وانتبه لأمرين: أن تمنع محركات البحث من فهرستها، وأن تتأكد من أنها لا ترسل بريدًا حقيقيًا إلى العملاء ولا تتصل ببوابة الدفع الحية.

3. حدّث بترتيب، لا دفعة واحدة

اعرف ما الذي ينتظر التحديث قبل أن تبدأ. من سطر الأوامر عبر WP-CLI:

bash
wp core check-update
wp plugin list --update=available --fields=name,version,update_version
wp theme list --update=available --fields=name,version,update_version

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

4. اختبر ما يهم فعلًا

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

5. انقل التغييرات إلى الموقع الحي

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

6. جهّز التراجع قبل أن تحتاجه

اكتب قبل البدء ما الذي ستفعله إن تعطل الموقع: إعادة الإضافة إلى إصدارها السابق، أو استعادة النسخة الاحتياطية التي أخذتها في الخطوة الأولى. يسمح WP-CLI بتثبيت إصدار محدد من إضافة:

bash
wp plugin install example-forms --version=2.3.1 --force

ما دور الذكاء الاصطناعي في التحديثات؟

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

ولا تجعل الذكاء الاصطناعي بديلًا عن الاختبار اليدوي للمسارات المهمة. هو يرى ما يُكتب في سجلات الخادم، ولا يرى زرًا في صفحة الدفع توقف عن العمل بسبب خطأ JavaScript في المتصفح، إلا إذا نسخت له رسالة الخطأ من أدوات المطور.

كيف تتعامل مع تنبيه ثغرة في إضافة أو قالب؟

الفحص اليومي يقارن إصدارات الإضافات والقوالب المثبتة بالثغرات المعروفة المنشورة لها. هذا مثال توضيحي لنتيجة فحص:

text
2026-10-25 04:00 UTC  vulnerability scan  site=example.com
  plugin  example-forms   2.3.1  HIGH    unauthenticated file upload   fixed in 2.3.2
  theme   example-theme   1.8.0  MEDIUM  stored XSS in shortcode       no fix available
  plugin  example-seo     5.1.4  OK

لكل نتيجة قرار مختلف.

الإصلاح متاح

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

لا يوجد إصلاح

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

هل استُغلت الثغرة قبل سدّها؟

التحديث يسد الباب، لكنه لا يُخرج من دخل. ابحث عن ملفات PHP في مجلد uploads، وعن حسابات مدير لم تنشئها، وعن تعديلات على ملفات النواة:

bash
find wp-content/uploads -name '*.php' -newermt '2026-10-01'
wp user list --role=administrator --fields=user_login,user_registered
wp core verify-checksums

الجانب الأمني الأوسع، مثل محاولات تسجيل الدخول المتكررة والبريد الصادر غير المعتاد، في مقال الذكاء الاصطناعي وأمان الخادم.

لماذا تظهر الشاشة البيضاء أو رسالة الخطأ الفادح؟

في الإصدارات القديمة من WordPress كان الخطأ الفادح في PHP يعني صفحة بيضاء فارغة. أما الإصدارات الحديثة فتعرض للزائر رسالة عامة:

text
There has been a critical error on this website.

وترسل بريدًا إلى عنوان المدير فيه رابط وضع الاستعادة (Recovery Mode)، الذي يسمح لك بالدخول إلى لوحة التحكم مع إيقاف الإضافة أو القالب المسبب مؤقتًا. الرسالة نفسها لا تقول شيئًا عن السبب، فالسبب في سجل أخطاء PHP.

مثال: عطل بعد تحديث تلقائي

لنفترض أن موقع example.sa توقف في الثالثة فجرًا. يبدأ المساعد بسجل الأخطاء:

text
[25-Oct-2026 03:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function example_forms_get_fields() in /home/example/public_html/wp-content/themes/example-theme/functions.php:214
Stack trace:
#0 /home/example/public_html/wp-includes/class-wp-hook.php(324): example_theme_render_form()
#1 {main}
  thrown in /home/example/public_html/wp-content/themes/example-theme/functions.php on line 214

ثم يراجع سجل العمليات فيجد أن إضافة example-forms حُدِّثت تلقائيًا في 03:10، أي قبل أول خطأ بدقيقتين. الاستنتاج مع دليله: القالب يستدعي دالة كانت في الإصدار السابق من الإضافة وأزيلت في الإصدار الجديد. المشكلة ليست في الإضافة وحدها ولا في القالب وحده، بل في اعتماد القالب على دالة داخلية في الإضافة.

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

ما الأسباب الشائعة الأخرى؟

ما يظهر في السجلالمعنى المرجح
Allowed memory size of ... bytes exhaustedاستنفدت العملية حد الذاكرة في PHP، غالبًا بسبب إضافة أو استيراد كبير
Maximum execution time of 30 seconds exceededعملية تجاوزت الحد الزمني، مثل نسخ احتياطي أو استيراد من داخل WordPress
Cannot redeclareإضافتان، أو قالب وإضافة، يعرّفان الدالة نفسها
syntax error, unexpectedتعديل يدوي خاطئ على ملف، أو تحديث لم يكتمل
Error establishing a database connection (في المتصفح)قاعدة البيانات لا تستجيب، أو بيانات الاتصال في wp-config.php خاطئة

شرح هذه الرسائل وغيرها بالتفصيل في مقال قراءة سجلات الأخطاء بالذكاء الاصطناعي.

كيف تكتشف تعارض الإضافات؟

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

  1. بدّل القالب إلى أحد قوالب WordPress الافتراضية. إن اختفت المشكلة فالسبب في القالب.
  2. عطّل نصف الإضافات. إن اختفت المشكلة فالسبب في هذا النصف، وإلا ففي النصف الآخر.
  3. كرر التنصيف داخل النصف المشتبه به حتى تبقى إضافة واحدة، أو إضافتان لا تعملان معًا.
bash
wp plugin list --status=active --field=name > active-plugins.txt
wp plugin deactivate example-forms example-slider example-popup
# test the site, then reactivate
wp plugin activate example-forms example-slider example-popup

مع عشرين إضافة تصل إلى السبب في نحو خمس جولات بدل عشرين. وإن لم تستطع التعطيل على موقع حي، فإضافة Health Check & Troubleshooting من مستودع WordPress تتيح وضع استكشاف أخطاء يعطّل الإضافات لجلستك أنت فقط، بينما يرى الزوار الموقع كما هو.

يفيد المساعد هنا في أمرين. الأول أنه يقرأ تتبع الأخطاء (Stack Trace) ويخبرك أي ملفات وأي إضافات ظهرت فيه، فيختصر جولات التنصيف حين يترك التعارض أثرًا في السجل. والثاني أنه يشرح بلغة واضحة رسالة خطأ JavaScript التي تنسخها من أدوات المطور في المتصفح.

WP-Cron أم وظائف Cron حقيقية؟

WP-Cron لا يعمل إلا مع زيارة. في موقع قليل الزيارات يتأخر النشر المجدول، وفي المتاجر تتأخر رسائل الطلبات والمهام المؤجلة، وقد تتوقف نسخ احتياطية تجريها إضافة دون أن يلاحظ أحد. الحل أن توقف WP-Cron وتشغّل المهام المستحقة من وظيفة Cron على الخادم:

php
// wp-config.php
define( 'DISABLE_WP_CRON', true );
text
*/5 * * * * cd /home/example/public_html && wp cron event run --due-now --quiet

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

bash
wp cron event list --fields=hook,next_run_relative

إن ظهرت مهام موعدها في الماضي بساعات، فوظيفة Cron لا تعمل أو تفشل.

كيف يساعدك bPanel؟

يدير bPanel مواقع WordPress كلها من مكان واحد: التحديثات، وفحص يومي للإضافات والقوالب بحثًا عن الثغرات المعروفة، ونسخ تجريبية تدفعها إلى الموقع الحي حين تكون جاهزة، ودخول آمن إلى wp-admin دون كلمة مرور. وتؤخذ نسخ احتياطية يومية للملفات وقواعد البيانات والبريد على الخادم وفي تخزين خارجي، مع استعادة بنقرة واحدة. ولكل وظيفة Cron سجل لكل تشغيل وتنبيه عند الفشل.

وحين يتعطل موقع، يقرأ المساعد السجلات والمقاييس ويحدد السبب بالدليل ويقترح إصلاحًا، ولا يُنفَّذ أي تغيير دون موافقتك، وكل إجراء يُسجَّل في سجل التدقيق. كل الباقات تشمل كل المزايا، ويمكنك المقارنة بينها في صفحة الأسعار.

الخلاصة

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