it-swarm.asia

كيفية القضاء على أخطاء 404 غريبة في الفسفور الابيض الادارية؟

أدير موقع WordPress مع حوالي 70 ملحقًا نشطًا.

في كثير من الأحيان ، سأحصل على صفحة خطأ عشوائية ("لم يتم العثور على" ، على الرغم من أنني لم أتحقق من الرؤوس لمعرفة ما إذا كانت 404) على صفحة /wp-admin/ التي تظهر من دون مكان.

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

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

تصحيح:

معلومات الاستضافة: DreamHost؛ أعتقد أن الخادم يقوم بتشغيل إصدار دبيان مخصص باستخدام Apache httpd

8
dgw

كنت أواجه مشكلات طوال اليوم فيما يبدو أنه 404 حالة من عدم اليقين.

على أي حال ، لقد انتهيت للتو من الدردشة مع أحد موظفي الدعم الفني dreamhost الذي أخبرني أن حساب المستخدم الذي أمتلكه معهم كان يصل إلى حدود موارد ذاكرة العملية (جميع العمليات) وهذا هو ما تسبب في حدوث مشكلات غريبة تتعلق بـ htaccess. كنت أتلقى أخطاء 404 متقطعة من ملف htaccess الذي لم يكن يجب استدعاؤه على الإطلاق! كان dreamhost مع خادم منزل مسكون.

على ما يبدو ، فإن عملية قتل الروبوت التي يستخدمها dreamhost ستقتل عملية الويب في الوسط ومن ثم لسبب ما ، يحاول Apache (الآن غيبوبة) إنهاء مهمته (يبذل قصارى جهده للخروج بشكل نظيف من النهاية غير المألوفة إلى استعلام فرعي) هو أفضل تخميني). يرمي خطأ 500 في سجل المتشعب الرئيسي ، ولكن بعد القيام بذلك ، فإنه في الواقع ينطلق شرط إعادة الكتابة والقاعدة التي كان يجب ألا يتم إطلاقها (باستخدام الملف القياسي -f وملف الدليل htaccess أعلاه) - وهو لا تكتب إدخال سجل جديد! طلب جديد (رجل غير مرئي) ثم يقوم بتشغيل ملف الفهرس في السطر الأخير من ملف htaccess

احذر حدود الموارد في حسابات dreamhost الأساسية! إذا تجاوزت حدودها ، ولديك htcess مع خطوط mod_rewrite سترى أشياء غريبة لا تصلح إلا ليلة العيد القديسين - رجال غير مرئيين ، مسكون 404s! عمليات أوندد! غيبوبة اباتشي! htaccess تتحرك من تلقاء نفسها! ييكيس!

آمل أن يكون هذا يساعدك على تجنب بعض ساعات من الألم.

6
sophistry

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

تفقد صفحة "لم يتم العثور على" التي يتم تقديمها لك بشكل أفضل (استعرض باستخدام Opera وافتح لوحة Info التي ستظهر لك الرؤوس ، واستعرض بدلاً من ذلك مع Firefox وتمكّن Firebug مع تمكين لوحة "Net") وابحث في جميع الإضافات الخاصة بك لمعرفة ما إذا كانت قد تخدمها مباشرة. إذا لم يكن الأمر كذلك ، فقم بإلقاء نظرة على سجل خادم الويب لمعرفة المصدر الدقيق الذي يتعذر عليه تقديمه ؛ قد يقوم أحد المكونات الإضافية ببعض إعادة التوجيه أو إعادة الكتابة الهائلة ، لذا فهو ليس بالضرورة عنوان URL الذي تراه في المتصفح الذي يسبب 404.

4
Asbjørn Ulsberg

لا يمكنني إلا أن أقوم بتجربة تجربتي الخاصة ، وحتى الآن لم أجد قاعدة "محددة" لإصلاح الكل المشكلات بضربة واحدة.

تكمن المشكلة الرئيسية في إعداد DreamHost في أنه ، في المعركة الأبدية للحفاظ على استهلاك الذاكرة كحد أدنى ، فإن ذلك يعني التخلص من أكبر عدد ممكن من الميزات - أي ، كل ذلك سيقلل من عرض النطاق الترددي (جيد للزوار!) أو وحدة المعالجة المركزية (جيد للخادم ، لكن DreamHost لا يتحكم في استهلاك وحدة المعالجة المركزية بقوة كما يتحكم في RAM). على سبيل المثال ، هذا يعني التخلص من gzip'ed HTML + CSS (والذي سيستهلك وحدة المعالجة المركزية + ذاكرة الوصول العشوائي) أو أي من المكونات الإضافية المصغرة المتعددة (التي سوف تستهلك RAM كذلك). كلما كانت ذاكرة التخزين المؤقت الأكثر تطوراً (أنا مغرم باستخدام W3 Total Cache ، أو على الأقل WP Super Cache) ، سيتم استهلاك RAM أيضًا).

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

أفضل النتائج حتى الآن على المواقع المزدحمة هي إلغاء تحديد سرعة الصفحة وأمن الويب الإضافي الذي سيستهلك على ما يبدو الكثير من ذاكرة الوصول العشوائي ، والاعتماد بدلاً من ذلك على مزيج من W3 Total Cache و Cloudflare (خدمة وكيل عكسي مجانية). ستنفذ Cloudflare فعليًا نفس الشيء مثل وحدة "أمان الويب الإضافي" ، ولكن نظرًا لأنه يعمل خارج DreamHost ، فلا بأس بذلك. يستهلك W3 Total Cache قدرًا كبيرًا من الذاكرة ، ولكن بمجرد تخزين الصفحات بشكل ثابت محليًا ، ستعمل Cloudflare على تخزينها مؤقتًا بكفاءة عالية - حتى تحصل على 404/500 أثناء تحرير المنشورات ، على الأقل لن يختبرها زوار موقعك (يمكن لـ Cloudflare أيضًا تقديم صفحات ثابتة حتى لو كان DreamHost يعطي 404 أو 500).

أيضًا ، بفضل هذه المقالة ، اكتشفت أن FastCGI يستخدم أكثر من [CGI] RAM. وبما أن PHP 5.3 أفضل في إدارة RAM (مجموعة البيانات المهملة الأكثر عدوانية وتقليل تسرب الذاكرة) ، فقد قمت بالتبديل التجريبي إلى PHP 5.3 CGI (وليس FastCGI) ) بدون تحسين سرعة الصفحة أو أمان الويب الإضافي ، الاعتماد على W3 Total Cache + Cloudflare لتسريع الموقع. الآن backoffice أبطأ (استهلاك وحدة المعالجة المركزية أكثر!) ولكن على الأقل لا أرى 404/500 (حتى الآن!).

ما زلت غير راض عن هذه المجموعة ، لذلك سأستمر بالتأكيد في ضبط Tweak DreamHost على أمل تقليل RAM أكثر من الاستمرارية وما زلت أحصل على أداء مناسب. كما قال @ dgw ، يمكنني أيضًا استخدام الكثير من المكونات الإضافية - لأنني أحتاج إلى وظائفها. ليس كل شخص يستضيف WP مع DreamHost لديه احتياجات مدون بسيطة ؛ كلما زاد تعقيد الموقع ، زاد عدد الوظائف التي سيتطلبها ... وهذا هو جمال WordPress ، كل ما تحتاجه هو استخدام المكونات الإضافية التي تحتاجها حقًا ، والحفاظ على جوهر WP التثبيت البسيط إذا كنت سعيد مع قليل من الاحتياجات. الإضافات ، ليست بالضرورة "سيئة" أو ثقيلة على الموقع ؛ ولكن صحيح أن البعض قد يستهلك الكثير من ذاكرة الوصول العشوائي ...

3
Gwyneth Llewelyn

هذه مجرد فكرة تقريبية: إذا تلقيت خطأ 404 "حقيقي" (مع تعيين الرؤوس) ، فيمكنك البحث من خلال الإضافات والبحث عن وظيفة PHP header() ورقم 404. قد يؤدي ذلك إلى خفض عدد المكونات الإضافية من 70 إلى بعض المكونات الإضافية. ثم تحتاج فقط للتحقق من هؤلاء.

يمكن القيام بذلك بسهولة من خلال IDE مثل Eclipse PDT الذي يوفر البحث عن استدعاء دالة PHP محدد.

بجانب ذلك ، ولكن بدون أي ضمان أنه يعمل بنجاح ، هو كتابة مكون إضافي يتم ربطه في إعداد الرأس ومن ثم يمنحك تتبع الرمز الذي يقوم بالفعل بتعيين 404 (backtrace). لن يعمل هذا إلا إذا كان المكوّن الإضافي يستخدم وظيفة واجهة برمجة تطبيقات WordPress. الطريقة الأولى للبحث عن الدالة PHP ستعمل بغض النظر عن WP API.

3
hakre

مزيد من المعلومات اللازمة:

1) لماذا الكثير من الإضافات؟

2) ما هو نظام التشغيل الذي يعمل عليه مزود الاستضافة الخاص بك؟

3) ما خادم الويب؟

4) هل لديك حق الوصول إلى سجلات خادم httpd ، وخاصة سجلات الأخطاء؟

5) ماذا تقول سجلات الخطأ في الإطار الزمني المحيط بهذه القضايا؟

(الآن ، قول الحقيقة ، إذا كنا نعمم على "متوسط ​​J6P الذي يشغل WordPress قد يكون لديه هذا السؤال الدقيق ، يمكننا أن نبدأ بتوجيه J6P المذكور للإجابة على الأسئلة الخمسة المذكورة أعلاه على الأقل ...)

2
ZaMoose