اضطر معظمنا ، سواء كانوا مطورين أو مصممين أو حتى مستخدمين نهائيين ، إلى تحمل واحدة على الأقل في حياتنا. هذه هي العملية المؤلمة المتمثلة في الحصول على خطأ داخلي في الخادم ومحاولة إصلاحه. كثير من الناس لا يهتمون بمعرفة المزيد – يريدون فقط إصلاحه. ولكن إذا لم تحاول فهم ذلك على الأقل ، فمن المؤكد أنك ستعاني من هذا المصير في كثير من الأحيان. يعد خطأ الخادم الداخلي 500 مهمًا للغاية لأنه يوقف جميع العمليات تمامًا ويمكن أن يؤدي إلى تعطيل موقعك بالكامل. لذلك إذا أردنا التخلص منه في أي وقت ، فنحن بحاجة إلى فهم أفضل لما يعنيه أولاً.
في هذه المقالة سأغطي أساسيات ما يعنيه هذا الخطأ ، وكيف يمكنك تحديد المشكلة وبالطبع كيفية إصلاحها. ولكن قبل البدء ، أريد أن أطلعك على أخطاء http (الموقع) المختلفة الموجودة وما يمكن أن تعنيه. إذا كنت تفضل يمكنك التخطي لأسفل إلى كيفية إصلاح خطأ WordPress 500 الخاص بك .
حالة HTTP الشائعة وأكواد الخطأ
أول الأشياء أولاً – سأشرح ما تعنيه هذه الأخطاء حقًا. توجد حاليًا قائمة بالحالة والأخطاء الخاصة بـ HTTP التي يمكن الوصول إليها لاستكشاف الأخطاء وإصلاحها بشكل أفضل. عادة ما يتم تقسيم هذه الأخطاء إلى أنواع. لذلك ، لاختصار هذا الأمر ، سنغطي أهم الأخطاء وأكواد الحالة المعلوماتية التي ستجدها أثناء العمل مع موقع WordPress الخاص بك.
استجابة 100 ضعف (الحالة)
يتم تقديم هذا النوع من الاستجابة مباشرة من خلال خادم الويب. اعتمادًا على شركة الاستضافة الخاصة بك ، يمكن تقديم الاستجابة إما عن طريق Apache أو nginx أو أي خادم ويب آخر تستخدمه الشركة. لا يرتبط هذا النوع من الاستجابة بالأخطاء. يتم استخدامها بشكل عام للإشارة إلى وجود اتصال. إنها رموز استجابة الحالة للاتصالات.
200x استجابة (نجاح)
الناجحون هم ما أسميهم. هذا النوع من الاستجابة يشير دائمًا إلى النجاح. هذا يعني أنه إما أن الخادم قد نجح في إجراء الاتصال بك ، أو أن الموارد المطلوبة قد تم تقديمها بشكل صحيح أو أنه تم إجراء اتصال وكيل.
يُعرف الرمز الأكثر نجاحًا باسم 200 OK. يمكنك أن ترى أمثلة على ذلك إذا كنت تستخدم أداة اختبار سرعة WordPress ، على سبيل المثال في أدوات Pingdom وتحاول اكتشاف FTTB (أول مرة للبايت). يتم دائمًا تقديم استجابة 200 OK لأول طلب تم تقديمه.
300x استجابة (إعادة توجيه)
رجال إعادة التوجيه. تتم إحالة هذه الرموز دائمًا إذا كان الرابط المحدد ينتقل إلى إعادة التوجيه. تشير رموز الحالة 300 إلى إعادة توجيه ناجحة ولا تعتبر أيضًا خطأ.
لنفترض أن لديك موقع SSL (HTTPS) ولديك أيضًا وصول مباشر إلى HTTP (غير آمن) وتريد إعادة توجيه الجميع إلى إصدار HTTPS من موقعك. يمكنك إنشاء إعادة توجيه لجميع الطلبات الواردة من HTTP للانتقال إلى HTTPS. إذا حاولت الدخول إلى موقعك عن طريق HTTP عن طريق الخطأ ، فسيتلقى متصفحك استجابة 300 تشير إلى إعادة التوجيه إلى إصدار HTTPS.
مثال آخر شائع قد تكون على دراية به هو عمليات إعادة التوجيه في الموقع لتحسين محركات البحث. ربما قمت بإزالة المنشورات أو الصفحات القديمة. بمساعدة مكون إضافي مثل Yoast SEO ، يمكنك 301 إعادة توجيه هذه إلى صفحات أحدث وأكثر صلة. أو استخدم إعادة توجيه مؤقتة 307 إذا كنت تعمل على تحديث وتريد توجيه المستخدمين إلى صفحة مختلفة قليلاً.
استجابة 400x (أخطاء العميل)
أخطاء العميل الشهيرة. تتضمن هذه الأنواع من الأخطاء مشاكل في متصفحك. عادةً ما يكون غير قادر على تحميل أصل معين (الأكثر شيوعًا هو الخطأ 404). هذه هي رموز الأخطاء التي لا تعتبر خطيرة.
قد يظهر الخطأ نفسه إذا حاولت الوصول إلى صورة غير موجودة على موقعك. على سبيل المثال ، قد ترغب في استخدام إعادة توجيه 410 لإخبار محركات البحث أن المحتوى قد تمت إزالته نهائيًا ، أو 451 إذا جعلت الصفحة غير متاحة لأسباب قانونية (مثل طلب قانون الألفية الجديدة لحقوق طبع ونشر المواد الرقمية).
استجابة 500x (أخطاء الخادم)
والآن وصلنا إلى بطلنا الرئيسي. أخطاء 500. كما ترى ، فهذه أخطاء مهمة وترتبط دائمًا بالخادم نفسه. أخطاء الخادم مهمة لأنها يمكن أن تعطل موقع الويب الخاص بك بشكل فعال . ومن هذه الأخطاء أهمها:
- خدمة 503 غير متوفرة
- 502 خطأ بوابة غير صالحة
- خطأ خادم داخلي 500
دعنا نستكشف الثلاثة منهم حسب الأهمية.
503 الخدمة غير متوفرة
الأقل خطورة هي خدمة 503 غير متوفرة. إذا ظهر هذا الخطأ ، فستواجه مشكلة في الموارد على خادم الويب. تظهر في كل الأوقات تقريبًا عندما يكون الخادم الخاص بك محملاً بشكل زائد. بعبارات واضحة ، إذا رأيت هذا الخطأ ، فاعلم أنه مؤقت وأنه مرتبط مباشرة بحركة مرور كبيرة جدًا وهذا يؤدي إلى زيادة التحميل على وحدة المعالجة المركزية. عندما لا تستطيع وحدة المعالجة المركزية وخادم الويب نفسه معالجة المزيد من الاتصالات الواردة لأنها وصلت إلى استخدام وحدة المعالجة المركزية بنسبة 100٪ ، فسترى هذا الخطأ المنبثق.
يمكنك إصلاح ذلك إما بالتبديل إلى خادم ويب أفضل (من Apache إلى Nginx على سبيل المثال) أو عن طريق تنفيذ مكون إضافي للتخزين المؤقت في WordPress على موقعك.
502 مدخل غير صالح
هذا ما أسميته خطأ التهيئة الخاطئ. هذا الخطأ لا يظهر بدون سبب. إذا كان لديك هذا الخطأ في أي وقت ، فالسبب على الأرجح هو أنك فعلت شيئًا وفعلته بشكل خاطئ. يحدث هذا عادةً عندما يحاول الأشخاص تعديل إعدادات Apache و PHP أو عند محاولة تحسين nginx. البوابة السيئة هي خطأ يحدث دائمًا تقريبًا عندما تفقد PHP FPM (Fast Process Manager) الاتصال. إما من التغيير والتبديل في الإعدادات الخاطئة أو بسبب تعطل العملية. هذا يقود خادم الويب للاستجابة ببوابة سيئة.
أسهل طريقة لإصلاح هذا الخطأ هي التحقق من تكوين PHP-FPM لأن هذا هو السبب الأكثر احتمالية لهذا الخطأ. يحدث هذا في كثير من الأحيان على جانب Nginx أكثر من Apache وتقريبًا لا يحدث أبدًا في خدمات الاستضافة التي تقدمها cPanel أو Plesk. هاتان اللوحتان الأخيرتان لديهما ضمانات لمنع حدوث خطأ في التكوين. ولكن ، يحدث ذلك كثيرًا عند إدارة VPS الخاص بك.
500 خطأ خادم داخلي
الولد الشرير الكبير للأخطاء. خطأ الخادم الداخلي 500 هو الأسوأ منهم جميعًا ، ويرجع ذلك أساسًا إلى أنه خطأ عام. إذا لم تكن لديك معرفة كافية حول كيفية التعامل معها ، فقد يكون ذلك بمثابة ألم حقيقي لأنه قد يؤدي إلى تعطل موقعك بالكامل. يؤدي الخطأ 502 bad gateway أيضًا إلى إبطاء موقعك ولكن من السهل تشخيصه وإصلاحه. كما ذكرنا ، يرتبط دائمًا بتكوين FPM.
أسباب 500 خطأ خادم داخلي وكيفية إصلاحها
أول شيء يجب فهمه حول الخطأ 500 هو أنه يمكن أن يكون ناتجًا عن عدد من العوامل المختلفة التي ترتبط دائمًا بالفشل في تنفيذ التعليمات البرمجية. بدلاً من محاولة تشخيص كل شيء في وقت واحد ، سأقدم لك قائمة بالأخطاء حسب نوع المشكلة وما كنت تفعله.
- عن طريق ترحيل موقع قديم إلى استضافة أحدث
- خطأ في htaccess في تكوين اباتشي
- خطأ في تنفيذ كود PHP
هناك حالات أخرى أقل شيوعًا يمكن أن تؤدي إلى حدوث خطأ داخلي في الخادم 500 ولكن من أجل البساطة وسهولة استخدام هذه المقالة ، سأركز على هذه الثلاثة.
1. ترحيل موقع أقدم إلى استضافة أحدث
هناك عدة طرق يمكن أن يظهر بها هذا الخطأ ولكن يبدو دائمًا أنه مرتبط بإصدار PHP المرتبط بخادم الويب الخاص بك. يمكن لإصدارات PHP الأحدث إنشاء خطأ داخلي في الخادم 500 على الفور إذا كان الموقع الحالي أو المكونات الإضافية لا تدعم الإصدار الحالي.
هذا الخطأ كلاسيكي على سبيل المثال ، عندما تقوم بترحيل موقعك من استضافة متواضعة بإصدار PHP أقدم إلى استضافة أحدث لا تقبل إلا الإصدارات الأحدث (7.0 وما فوق). إذا لم يتم تحديث موقعك مؤخرًا ، فقد يتسبب المكون الإضافي القديم في حدوث مشكلة. أطلق على هذا اسم “خطأ خادم داخلي في الترحيل” لأنه يحدث غالبًا عند ترحيل أحد المواقع.
المحلول
أفضل طريقة لإصلاح هذا الخطأ الرهيب عندما تحاول جاهدًا ترحيل موقع WordPress الخاص بك إلى استضافة جديدة هي عمل نسخة كاملة من المكونات الإضافية وموضوع موقعك. بعد القيام بذلك ، يرجى حذف جميع المكونات الإضافية من موقعك والمحاولة مرة أخرى. إذا اختفى الخطأ ، فمن المؤكد تقريبًا أن الخطأ قد تم إنشاؤه بواسطة إصدار أحدث من PHP على استضافتك والذي يرفض ببساطة تنفيذ التعليمات البرمجية على المكون الإضافي الأقدم. من خلال إعادة تحميل مكون إضافي واحد في كل مرة ، يمكنك بسهولة معرفة المكون الإضافي الذي تسبب في المشكلة.
تظهر هذه الأخطاء دائمًا عند ترحيل المواقع القديمة التي تعمل على PHP 5.4 و 5.6 إلى استضافة أحدث باستخدام PHP 7.0 أو 7.1 أو 7.2.
نفس الشيء ينطبق على موضوعك. نظرًا لأن السمات يمكنها تنفيذ كود PHP إضافي في ملفات function.php و single و page.php . من المرجح أن المظهر الأقدم بدون تحديثات يمكنه كسر موقعك بمجرد ترحيله إلى استضافة بإصدار أحدث من PHP ، وهذا الموقف مؤسف لأن الطريقة الوحيدة لإصلاح ذلك هي تغيير السمة وإعادة بناء موقعك. هذا هو السيناريو الأسوأ.
2. خطأ في تكوين Apache
لنفترض أنك كنت تقوم بتكوين مكون إضافي وفجأة تعطل كل شيء. إذا تلقيت خطأ خادم داخلي 500 أثناء التكوين ، على سبيل المثال مكون إضافي للتخزين المؤقت أو أي مكون إضافي متعلق بالتحسينات ، فأنت بحاجة إلى التحقق مما إذا كان المكون الإضافي قد أضاف رمزًا إضافيًا إلى ملف htaccess الخاص بك.
نظرًا لأنه يمكن تعديل apache في الوقت الفعلي عن طريق تكوين الوظائف في ملف .htaccess (والذي يكون مخفيًا دائمًا تقريبًا) ، فقد يؤدي التكوين السيئ إلى تعطيل موقعك.
المحلول
طريقة إصلاحه هي إما الوصول إلى موقعك من خلال FTP وتعديل ملف htaccess الخاص بك أو عن طريق التحرير المباشر ، على سبيل المثال باستخدام مستكشف الملفات على cPanel أو Plesk.
إذا كنت لا تعرف كيفية التراجع عن ما قام به المكون الإضافي وتحتاج إلى إعادة تشغيل موقعك مرة أخرى ، فقم بعمل نسخة من المحتويات الموجودة كملف نصي. احفظ هذا كنسخة احتياطية. ثم استبدل .htaccess بالكامل بالشفرة التالية.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
هذا هو ملف ووردبريس الافتراضي .htaccess . يجب أن تعمل مع أي موقع. لذا ، إذا كنت يائسًا ولا تعرف أي جزء تريد إزالته ، فما عليك سوى إزالة كل شيء ولصق هذا الرمز ، وسيوفر لك ذلك على الفور. يمكنك لاحقًا إزالة المكون الإضافي أو محاولة تهيئته مرة أخرى. أنت الآن تعرف طريقة لإنقاذك من هذا الخطأ الكارثي. على الأقل إذا كان متعلقًا بامتداد htaccess.
إذا كنت لا تعرف ما إذا كان متعلقًا بامتداد htaccess ، أو بدأ هذا الخطأ في الظهور دون لمس أي مكونات إضافية ، فقم بتشغيله بأمان. ما عليك سوى نسخ محتويات .htaccess ونسخ الرمز أعلاه لمحاولة التشخيص. إذا لم يتم إصلاح ذلك ، فاترك htaccess كما هو ثم جرب الاقتراح التالي.
3. خطأ في تنفيذ كود PHP
تعد هذه الأنواع من الأخطاء أكثر شيوعًا مما تعتقد ، وعادة ما تحدث إذا كان المكون الإضافي ينفذ تعليمات برمجية غير صالحة. الطريقة الأكثر شيوعًا لتنفيذ تعليمات برمجية غير صالحة هي محاولة تنفيذ تعليمات مهملة. ربما تحاول تشغيل مكون إضافي قديم تم تصميمه فقط للعمل مع ما يصل إلى PHP 5.4 أو 5.6 مع PHP 7.0 أو الإصدارات الأحدث. ستؤدي الوظائف المهملة وغير الصالحة إلى حدوث خطأ داخلي في الخادم لا يمكن تشخيصه إلا من خلال تمكين وضع تصحيح أخطاء WP.
قم بتمكين wp_debug
يمنحك وضع تصحيح أخطاء WordPress تفاصيل شاملة حول الخطأ الذي تم إلقاؤه والذي أدى إلى توقف التنفيذ. الطريقة التي نقوم بتمكينها هي عن طريق تغيير القيمة من “false” إلى “true” في wp_debug داخل الملف wp-config.php في المجلد الجذر لموقعك.
إذا كنت تستخدم Plesk أو cPanel ، فيمكنك القيام بذلك ببساطة عن طريق تغيير هذه القيمة باستخدام File Explorer وتحرير wp-config.php . يمكنك أيضًا اتباع دليل التصحيح هذا من خلال Blogvault للحصول على خطوات أكثر تفصيلاً.
بمجرد تحرير الملف ، ستتمكن من رؤية الخطأ الفعلي الذي تم إنشاؤه والذي أوقف التنفيذ. سيوضح الخطأ أيضًا المسار والملف حيث حدث هذا ، لذلك من السهل تخمين المكون الإضافي الذي تسبب في حدوث ذلك. من خلال تعطيله ، يمكننا تخطي الخطأ وتحديث المكون الإضافي لاحقًا أو إزالته ، اعتمادًا على الموقف.
المحلول
تتضمن الغالبية العظمى من مثيلات خطأ خادم داخلي 500 إصدارات أقدم أو مكونات إضافية . من خلال تبديل السمة الخاصة بك إلى أي سمة WP قياسية ، ستتمكن من استعادة الوصول إلى موقعك. سيؤدي تعطيل المكونات الإضافية المتعارضة أيضًا إلى إرجاع وصولك إلى لوحة التحكم. إذا صادفت موقفًا يكون موضوعك فيه هو المسؤول عن كسر الموقع ، فإن أفضل طريقة لإصلاحه هي عن طريق إنشاء ملف مضغوط للموضوع المذكور من مجلد السمة wp-content / theme / yourtheme ثم حذفه من موقعك. سيؤدي هذا إلى إزالة الخطأ حتى تتمكن من استعادة الوصول إلى موقعك. يمكنك بعد ذلك إعادة تحميله وتحديثه دون تفعيله. يمكنك أن تفعل الشيء نفسه مع المكونات الإضافية.
يمكن إصلاح المواقف الأكثر شيوعًا ل 500 خطأ داخلي في الخادم عن طريق التحديث. في الحالات التي لا يتوفر فيها تحديث للمكوِّن الإضافي / السمة المذكور ، يمكنك محاولة التبديل إلى إصدار PHP أقدم. لكن اعلم أن هذا حل قصير الأجل. تصبح الإصدارات الأحدث من PHP مستقرة ويتم إهمال الإصدارات الأقدم بانتظام. عاجلاً أم آجلاً سيتوقف موقعك عن العمل بالتأكيد. سيكون أفضل نهج دائمًا هو تحديث أو إزالة / استبدال المكونات الإضافية المعنية.
تذكر دائمًا أنه من الأفضل المنع والتحديث بدلاً من محاولة التحكم في الضرر لاحقًا.
اختتام دليلنا لأخطاء خادم WordPress 500 الداخلية
يمكن أن يكون خطأ الخادم الداخلي في WordPress 500 بمثابة ألم حقيقي. ولكن في معظم الحالات ، يمكن تشخيصها وإصلاحها بسهولة عن طريق إزالة / تحديث الأجزاء المتضاربة من موقعك. على الرغم من إمكانية ظهور هذه الأخطاء خارج نطاق القاعدة (على سبيل المثال عند تطوير مكون إضافي) ، فإن هذا يتجاوز الغرض من هذه المقالة.