تعارض الإضافات في ووردبريس: اكتشف الإضافة المذنبة في 5 جولات

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

هل المشكلة تعارض فعلاً؟

تعارض الإضافات (Plugin Conflict) يعني أن قطعتين من الكود تتنافسان على المورد نفسه: سكربت JavaScript، أو خطّاف (Hook)، أو عنصر HTML، أو ذاكرة الخادم. كل إضافة قد تعمل بشكل سليم وحدها، والعطل يظهر من اجتماعهما.

قبل أن تبدأ البحث، طابق العَرَض مع الاحتمال الأقرب:

العَرَض	الاحتمال الأقرب	ابدأ من هنا
شاشة بيضاء أو «حدث خطأ فادح»	خطأ PHP في إضافة أو قالب	بريد وضع الاسترداد ثم debug.log
—	—	—
خطأ 502 أو 503 أو 504	ضغط على الخادم أو توقفه	الدعم الفني للاستضافة، لا الإضافات
فورم لا يُرسل، قائمة لا تفتح، زر لا يستجيب	خطأ JavaScript أو ترتيب تحميل السكربتات	Console المتصفح
المشكلة تظهر للزوار فقط لا لك وأنت مسجّل	الكاش أو الـ CDN	تفريغ الكاش وإيقاف التحسينات مؤقتاً
رسالة Allowed memory size exhausted	حد ذاكرة PHP	رفع WP_MEMORY_LIMIT

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

قبل أن تلمس أي إضافة: نسخة احتياطية وسجل أخطاء

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

ثم فعّل سجل أخطاء ووردبريس (debug.log) بإضافة هذه الأسطر في wp-config.php فوق سطر «That’s all, stop editing»:

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

بهذا تُكتب الأخطاء في wp-content/debug.log دون أن تظهر للزوار. افتح الملف وابحث عن أي مسار يحتوي /plugins/؛ اسم المجلد الذي يليه هو اسم الإضافة المشتبه بها.

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

اقرأ الخطأ قبل أن تخمّن

ثلاثة أماكن تدلك على المذنب في دقائق، وتغنيك غالباً عن التجربة العمياء:

1. بريد وضع الاسترداد (Recovery Mode): عند الخطأ القاتل يرسل ووردبريس إلى بريد المدير رابط دخول يوقف الإضافة المعطوبة مؤقتاً. راجع صندوق البريد والـ Spam قبل أي شيء.
2. ملف debug.log: يذكر الملف والسطر الذي توقف عنده التنفيذ.
3. Console المتصفح: للمشكلات التي لا تُسقط الموقع، وهي الأكثر شيوعاً مع الفورمات والقوائم والفلاتر.

لقراءة Console افتح الصفحة في نافذة خاصة، اضغط F12، وانتقل إلى تبويب Console ثم أعد التحميل. رسائل مثل Uncaught TypeError أو jQuery is not defined أو $ is not a function تعني أن سكربتاً فشل أو حُمّل بترتيب خاطئ. اضغط رابط الملف بجوار الخطأ، وسيظهر مسار مثل /wp-content/plugins/plugin-name/ يحدد الإضافة صاحبة السكربت.

بعض الأخطاء لا تظهر إلا عند التفاعل، فاضغط الزر أو أرسل الفورم والـ Console مفتوح. وفي تبويب Network ابحث عن سكربتات تعيد 404، أو عن مكتبة واحدة تُحمَّل مرتين بإصدارين مختلفين، فهذه علامة تعارض كلاسيكية.

طريقة التنصيف: 5 جولات بدل 30

لو لم تدلك الرسائل على المذنب، لا تعطّل الإضافات واحدة واحدة. مع 30 إضافة نشطة قد تحتاج 30 جولة، وكل جولة على الموقع الحي تعني صفحة مكسورة أمام الزوار. الأسرع أن تقسم القائمة نصفين في كل جولة، فتصل إلى الإضافة المذنبة بين 30 إضافة في نحو 5 جولات.

طريقة التنصيف

اعثر على الإضافة المذنبة في 5 جولات

1. ثبّت الأساس

   اترك القالب ومحرر الصفحات مفعّلين، واعمل على نسخة اختبار.

2. عطّل النصف

   عطّل نصف الإضافات الباقية بالإجراء الجماعي.

3. اختبر بنظافة

   فرّغ الكاش وافتح الصفحة في نافذة خاصة.

4. احصر الاحتمال

   اختفت المشكلة؟ المذنب في النصف المعطّل. وإلا ففي المفعّل.

5. كرر حتى تبقى واحدة

   30 إضافة تحتاج نحو 5 جولات بدل 30.

ابن موقعك قطعة قطعةarabcms.com

1. ثبّت الأساس: اترك القالب والإضافة التي بُني عليها الموقع (مثل Elementor) مفعّلين طوال البحث.
2. عطّل نصف الإضافات الباقية من Plugins → Installed Plugins بالإجراء الجماعي (Bulk Actions).
3. اختبر بعد تفريغ الكاش وفي نافذة خاصة.
4. اختفت المشكلة؟ المذنب في النصف المعطّل: أعد تفعيله وقسّمه من جديد.
5. ما زالت موجودة؟ المذنب في النصف المفعّل: أعد تفعيل الآخر وقسّم هذا.
6. كرر حتى تبقى إضافة واحدة.

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

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

في Elementor: لو المشكلة داخل المحرر نفسه (لا يفتح أو يدور بلا توقف)، جرّب وضع الأمان (Safe Mode) من أدوات Elementor أولاً؛ فهو يحمّل المحرر دون بقية الإضافات والقالب. وفي مواقع JetEngine لا تعطّل JetEngine ضمن التنصيف، لأن الـ Listings والحقول ستختفي وستظن أن المشكلة حُلّت.

لما لوحة التحكم نفسها تقع

لو الأدمن لا يفتح ولم يصلك بريد وضع الاسترداد، فأمامك طريقان.

عبر واجهة سطر أوامر ووردبريس (WP-CLI) إن كانت استضافتك توفر SSH، وهي الأسرع:

wp plugin list --status=active
wp plugin deactivate plugin-slug
wp plugin activate plugin-slug

عبر FTP أو مدير الملفات في cPanel أو hPanel: ادخل wp-content/plugins وأعد تسمية مجلد الإضافة المشتبه بها (أضف _off مثلاً)، فيعطّلها ووردبريس تلقائياً. ولو لم تعرف أيها، أعد تسمية مجلد plugins كله، ادخل لوحة التحكم، أعد الاسم الأصلي، ثم فعّل الإضافات بطريقة التنصيف.

طبقات تنساها: الكاش والـ CDN وذاكرة PHP

نسبة كبيرة مما يبدو «تعارض إضافات» سببها طبقة تقع بين الإضافات والزائر.

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

الـ CDN مثل Cloudflare قد يخزّن صفحات ديناميكية أو يؤجل السكربتات عبر Rocket Loader. لو المشكلة تظهر للزوار فقط، فرّغ كاش الـ CDN وأوقف تحسيناته مؤقتاً، ثم أعدها واحدة واحدة.

التخزين المؤقت للكائنات (Object Cache) مثل Redis قد يُبقي إعدادات قديمة بعد التحديث، فتتصرف الإضافة وكأن شيئاً لم يتغير. فرّغه من لوحة الاستضافة وأعد الاختبار.

حد ذاكرة PHP يظهر أولاً مع المواقع المبنية بمحررات الصفحات وإضافاتها. ارفعه من wp-config.php فوق سطر «stop editing»:

define( 'WP_MEMORY_LIMIT', '768M' );

القيمة 768 ميجابايت هي ما توصي به Crocoblock لمواقعها. تحقق من القيمة الفعلية في Tools → Site Health → Info → Server؛ لو لم تتغير فالاستضافة تفرض سقفاً، وارفعه من php.ini في لوحة الاستضافة أو اطلبه من الدعم الفني.

بصراحة: خطط الاستضافة المشتركة الرخيصة الشائعة في مصر والمنطقة كثيراً ما تأتي بحد ذاكرة أقل بكثير من ذلك، ولا يكفي تعديل wp-config.php لتجاوزه. لو موقعك مبني على Elementor Pro وJetEngine وWooCommerce معاً، فاسأل الدعم عن حد الذاكرة الحقيقي قبل أن تبحث عن تعارض غير موجود.

وجدت المذنب، ماذا الآن؟

لا تحذف أول إضافة تشير إليها التجربة. اختر الحل حسب نوع التعارض:

• إضافتان تؤديان الوظيفة نفسها (كاش مع كاش، SEO مع SEO، حماية مع حماية): احتفظ بواحدة فقط. هذا التعارض متوقع وليس عيباً في أي منهما.
• سكربت يتعطل بعد التحسين: أضف استثناءً في إضافة الكاش بدل إطفاء التحسين كله.
• إضافة قديمة لم تُحدَّث منذ مدة: ابحث عن بديل يُحدَّث بانتظام.
• إضافتان سليمتان تتصادمان: راجع سجل التغييرات (Changelog) ومنتدى الدعم لكلتيهما بحثاً عن مشكلة معروفة، ثم راسل المطوّر مرفقاً لقطة الخطأ من Console أو سطر debug.log. اللقطة توفر عليك عدة ردود ذهاباً وإياباً.
• لا حل قريب والموقع متوقف: ارجع إلى آخر نسخة احتياطية سليمة، ثم أكمل البحث في بيئة الاختبار.

كيف تقلل التعارضات من الأساس

• حدّث بجدولك أنت لا بجدول الإضافات: اترك تحديثات الأمان الصغيرة لنواة ووردبريس تلقائية، وحدّث الإضافات والقوالب والإصدارات الكبيرة يدوياً على بيئة الاختبار، على دفعات صغيرة. التأجيل الطويل ليس حلاً، فالمواقع غير المحدثة تُخترق لا تتعطل فقط.
• راجع الإضافة قبل تثبيتها: تاريخ آخر تحديث، وجودة سجل التغييرات، وسرعة رد المطوّر في المنتدى، ووجود شكاوى عن تعارض مع إضافات تستخدمها أصلاً.
• قلّل عدد المطوّرين لا عدد الإضافات فقط: الإضافات من مطوّر واحد غالباً تُختبر معاً، وعند المشكلة تعرف من تسأل. عشرون مطوّراً يعني عشرين جدول إصدارات وعشرين فريق دعم.
• لا تراهن على إضافة Health Check: إضافة Health Check & Troubleshooting من فريق WordPress.org كانت توفر وضع اختبار يعطّل الإضافات لحسابك وحدك، لكنها لم تُحدَّث منذ يوليو 2024، ولم تُختبر على آخر ثلاثة إصدارات من ووردبريس.

الأسئلة الشائعة

س: كيف أعرف أي إضافة سببت الشاشة البيضاء في ووردبريس؟
ج: راجع بريد المدير بحثاً عن رابط وضع الاسترداد أولاً، ثم افتح wp-content/debug.log وابحث عن مسار يحتوي /plugins/. لو لا يوجد سجل، أعد تسمية مجلدات الإضافات عبر FTP أو عطّلها بـ WP-CLI حتى يعود الموقع.

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

س: الفورم لا يرسل ولا توجد أي رسالة خطأ، فما السبب؟
ج: غالباً خطأ JavaScript. افتح Console بـ F12 وأرسل الفورم وراقب الرسائل الحمراء. السبب الأشيع إضافة كاش تؤجل السكربتات أو تدمجها، والحل استثناء سكربت الفورم من التحسين.

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

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

الخلاصة

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

مراجع إضافية: Debugging in WordPress — WordPress Developer Resources، Health Check & Troubleshooting — WordPress.org

مرجع المقال (بالإنجليزية): WordPress Plugins Compatibility Issues Guide (2026) — Crocoblock
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.