تشخيص مشاكل WordPress 2026: Decision Tree قبل أي إصلاح

تشخيص مشاكل WordPress يجب أن يسبق أي محاولة إصلاح. نفس العرض — مثل بطء الموقع أوخطأ 500 أوتعطل صفحة واحدة — قد ينتج عن أسباب مختلفة تمامًا، وأخطر ما يمكن فعله هو تطبيق “حل مشهور” قبل معرفة طبقة المشكلة.

الخلاصة: ابدأ بتحديد نطاق العطل ووقت ظهوره، سجّل آخر تغيير، خذ Backup أوSnapshot، ثم افحص Recovery Mode وLogs وSite Health. اعزل المكون المشتبه به بأقل تغيير ممكن، ويفضل على Staging. لا تعطل كل Plugins أوتغيّر القالب أوترفع Memory إلا عندما لديك دليل يبرر الخطوة.

هذه الصفحة هي Troubleshooting Decision Tree، وليست قائمة بكل خطأ معروف. لو تريد فهرسًا للأعطال الشائعة نفسها، راجع مشاكل WordPress الشائعة وأسبابها.

Decision Tree سريع

المرحلة 1: ما نطاق المشكلة؟

قبل أن تسأل “ما الحل؟”، حدد أين يظهر العطل:

• كل الموقع.
• Frontend فقط.
• wp-admin فقط.
• صفحة واحدة.
• نوع محتوى واحد.
• WooCommerce فقط.
• مستخدمون مسجلون فقط.
• Mobile فقط.

كلما ضاق النطاق، قل عدد المكونات المحتملة.

المرحلة 2: متى بدأت المشكلة؟

سجّل Timestamp تقريبي ثم قارن مع:

• Plugin update.
• Theme update.
• WordPress Core update.
• PHP version change.
• Deploy أوCode snippet.
• Import/Database operation.
• Hosting change.
• DNS/CDN change.

“آخر تغيير” ليس حكمًا نهائيًا، لكنه أقوى Lead في كثير من الحالات.

المرحلة 3: خذ Backup قبل الاستمرار

إذا الموقع ما زال قابلًا للوصول، خذ:

• Database backup.
• Files backup.
• Hosting snapshot إن كانت متاحة.

إذا الموقع متوقف، استخدم أدوات Hosting بدل تشغيل Plugin جديدة داخل موقع معطل.

المرحلة 4: هل WordPress أرسلت Recovery Mode؟

WordPress تحتوي Recovery Mode لحالات Fatal PHP error أثناء تحميل الصفحات. افحص بريد Administrator.

إذا وصلت رسالة:

1. ادخل عبر رابط Recovery Mode.
2. اقرأ اسم Plugin/Theme المسببة.
3. أوقف المكون أوارجع التعديل.
4. اختبر قبل الخروج من Recovery Mode.

للتشخيص الكامل لهذه الحالة راجع White Screen وCritical Error في WordPress.

المرحلة 5: اقرأ Log قبل التخمين

ابحث عن:

• PHP Fatal error.
• Uncaught Exception.
• Allowed memory size exhausted.
• Database connection errors.
• Permission errors.
• REST/HTTP failures.

المعلومة الأهم عادة:

file path + line + error type

إذا Stack trace تشير إلى Plugin محددة، ابدأ بها، لا بكل Plugins.

المرحلة 6: WP_DEBUG بصورة آمنة

إذا تحتاج Logging مؤقتة:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

لا تعرض PHP errors على Production للزوار. وأوقف Debug بعد انتهاء التشخيص.

المرحلة 7: Site Health

من Tools → Site Health افحص:

• Critical issues.
• REST API.
• Loopback.
• Scheduled events.
• HTTPS.
• PHP/server environment.

Site Health ليست Score يجب مطاردتها، لكنها توفر Evidence جيدة عن البيئة.

المرحلة 8: هل المشكلة Plugin conflict؟

لا تبدأ بتعطيل كل شيء إذا Log تحدد Plugin بعينها.

الترتيب الأفضل:

1. المكون الذي تغير مؤخرًا.
2. المكون المذكور في Stack trace.
3. Plugins التي تعمل على نفس الوظيفة.
4. عزل أوسع فقط إذا لم يظهر السبب.

متى أعطل كل Plugins؟

كـFallback عندما:

• لا توجد Logs مفيدة.
• Dashboard غير متاحة.
• لا تعرف أي مكون تسبب بالمشكلة.

ويفضل على Staging أوداخل Maintenance window لموقع تجاري.

المرحلة 9: Theme conflict

إذا العطل مرتبط بالواجهة أوStack trace داخل Theme:

• ارجع آخر Child Theme change.
• اختبر Default theme على Staging.
• لا تعدل Parent theme.

تغيير Theme على Production متجر أوSite مع Builder قد يكسر Layout؛ لا تستخدمه كأول اختبار.

المرحلة 10: PHP Compatibility

بعد PHP upgrade قد تظهر أخطاء Type/Deprecated/Removed functions.

راجع:

• نسخة Plugin/Theme.
• متطلبات PHP.
• Changelog.
• Stack trace.

الرجوع المؤقت لـPHP سابقة قد يكون Recovery، لكنه ليس حلًا دائمًا لكود غير متوافق.

المرحلة 11: Memory

لا ترفع Memory لمجرد أن الموقع بطيء. ارفعها فقط إذا Logs تقول:

Allowed memory size exhausted

ثم ابحث عن العملية التي تستهلك الذاكرة: Import، Image processing، Query ضخمة، Plugin، Builder أوBackground job.

المرحلة 12: 500 Error

HTTP 500 عرض عام وليس Root Cause. افحص:

• Server error log.
• PHP log.
• .htaccess / Nginx rules.
• Permissions.
• Plugin/Theme fatal.
• Resource limits.

لا تستبدل .htaccess أوCore files قبل معرفة السبب.

المرحلة 13: 404 بعد تغيير Permalinks

إذا Pages موجودة لكن تعطي 404:

• راجع Permalink settings.
• Rewrite rules.
• Server config.
• هل Slug تغيرت؟
• هل هناك Redirect conflict؟

لا تعمل Redirect كل 404 إلى Homepage.

المرحلة 14: Login problems

حدد هل المشكلة:

• Password.
• Cookies.
• Redirect loop.
• Security plugin.
• Site URL mismatch.
• 2FA.

لا تغيّر siteurl وhome في Database عشوائيًا.

المرحلة 15: REST API

تعطل REST قد يؤثر على:

• Block Editor.
• Plugins.
• Integrations.
• WooCommerce/API workflows.

افحص Site Health وHTTP status وAuthentication وSecurity/WAF rules.

المرحلة 16: WP-Cron / Scheduled Events

لو Emails/Backups/Jobs لا تعمل:

• راجع Site Health.
• Scheduled actions.
• Loopback.
• DISABLE_WP_CRON.
• Server cron إذا مستخدمة.

لا تفترض أن Cron تعمل لأن Frontend تعمل.

المرحلة 17: الموقع بطيء

البطء ليس Error واحدة. افصل:

• TTFB.
• Database.
• PHP workers.
• Frontend assets.
• Third-party scripts.
• Images.
• Cron/queues.

لا تضف Cache Plugin قبل معرفة ما إذا المشكلة Backend أوFrontend.

المرحلة 18: WooCommerce

إذا الموقع العام يعمل والمتجر لا:

• WooCommerce logs.
• Status/System report.
• Scheduled actions.
• Payment webhooks.
• Cart/Checkout blocks.
• Shipping/tax rules.
• HPOS compatibility.

راجع أيضًا مشاكل WooCommerce الشائعة إذا العطل محصور في المتجر.

المرحلة 19: Staging

استخدم Staging عندما الاختبار يحتاج:

• تعطيل Plugins كثيرة.
• تغيير Theme.
• تغيير PHP.
• Database cleanup.
• Core update.
• WooCommerce upgrade.

ولا تعتمد على noindex وحدها لحماية Staging؛ استخدم Access control.

المرحلة 20: Troubleshooting Mode

يوجد Troubleshooting Mode كأداة تسمح للمسؤول بتجربة تعطيل Plugins/Theme لجلسة الاختبار دون التأثير على الزوار في بعض السيناريوهات.

لكن لا تستخدم Plugin تشخيص لموقع مخترق أومتوقف تمامًا إذا لا تستطيع التحقق من بيئة التشغيل.

المرحلة 21: Rollback أمFix؟

المرحلة 22: لا تنفذ SQL كأول حل

SQL مفيدة عندما المشكلة محددة والSchema معروفة، لكنها عالية الأثر.

قبل أي UPDATE/DELETE:

• Backup.
• SELECT preview.
• WHERE محددة.
• Count المتوقع.
• Rollback plan.

المرحلة 23: لا تعدل Core

أي Patch داخل wp-admin أوwp-includes سيُفقد مع Update ويصعب تدقيقه. استخدم Hooks أوPlugin/Child Theme.

المرحلة 24: ماذا أسجل أثناء التشخيص؟

اكتب Timeline:

• الوقت.
• العرض.
• التغيير المنفذ.
• النتيجة.
• Log قبل/بعد.

بدون Log للتغييرات قد تعود لنفس الخطوة عدة مرات.

المرحلة 25: Post-fix Verification

بعد عودة الصفحة لا تعتبر المشكلة منتهية.

اختبر:

• Homepage.
• Admin.
• Forms.
• REST.
• Cron.
• Woo critical flow.
• Error logs.
• Cache.

المرحلة 26: Root Cause

اسأل لماذا حدث العطل:

• Update بلا Staging؟
• Plugin غير مدعومة؟
• Code بدون Version control؟
• موارد Hosting قليلة؟
• وظيفتان متداخلتان؟

إعادة الموقع فقط ليست Prevention.

المرحلة 27: Prevention

راجع تجهيز WordPress للإنتاج لبناء:

• Backup.
• Staging.
• Update policy.
• Rollback.
• Monitoring.
• Least privilege.

ماذا لا أفعل أثناء العطل؟

• لا أحذف Database.
• لا أركب 5 Plugins “إصلاح”.
• لا أرفع Memory بلا Evidence.
• لا أضع Permissions 777.
• لا أعرض Errors للزوار.
• لا أغير Theme على Production بلا Backup.
• لا أعدل Core.
• لا أنظف Database عشوائيًا.

Checklist تشخيص

أسئلة شائعة

ما أول خطوة لحل مشكلة WordPress؟

تحديد نطاق العطل ووقت بدايته وآخر تغيير قبل تنفيذ أي إصلاح.

هل أعطل كل Plugins أولًا؟

لا إذا Logs أوRecovery Mode تحدد المكون المسبب. التعطيل الجماعي Fallback عندما السبب غير معروف.

هل WP_DEBUG آمنة؟

استخدم Logging بصورة مؤقتة، وأبقِ WP_DEBUG_DISPLAY=false على Production.

هل Site Health تصلح المشكلة؟

هي أداة تشخيص تعرض Issues وEnvironment، وليست Fix تلقائية.

متى أستخدم Staging؟

عندما الاختبار نفسه قد يؤثر على الزوار أوالطلبات أوالبيانات.

الخلاصة

أفضل مهارة في إصلاح WordPress ليست حفظ مئة حل؛ هي تقليل مساحة الاحتمالات بأدلة. Scope → Timeline → Backup → Recovery/Logs → أصغر اختبار ممكن → Root Cause → Verification. بهذا المسار تتحول Troubleshooting من تجربة وخطأ إلى عملية هندسية قابلة للتكرار.

مصادر WordPress الرسمية

• Recovery Mode
• Site Health
• Site Health Screen