404 في كل صفحة باستثناء الصفحة الرئيسية
نمط محدد للغاية مع قائمة قصيرة جدًا من الأسباب. لا تزال مشاركاتك موجودة ؛ جهاز التوجيه أمامهم ليس التوجيه.
404 Not Found — the requested page could not be found.
الصفحة الرئيسية هي عنوان URL الوحيد الذي لا يحتاج إلى قاعدة إعادة كتابة ، وهذا هو السبب في أنه الناجي الوحيد. تأكيد عن طريق طلب مشاركة بسلسلة استعلام بدلاً من الرابط الثابت - إذا تم تحميل ذلك ، فإن المحتوى جيد وطبقة إعادة الكتابة هي المشكلة بأكملها.
الأسباب الأرجح أولًا.
افحص القائمة بالترتيب. يتيح لك كل فحص تأكيد السبب أو استبعاده قبل تغيير أي شيء، لأن الحلول تختلف والتخمين يكلّف أكثر من تنفيذ أمر للتحقق.
| السبب | كيفية التحقق | الإصلاح |
|---|---|---|
| قواعد إعادة كتابة قديمة أو مفقودة | شكل سلسلة الاستعلام من تحميل آخر و الرابط الثابت الجميل لا. لا شيء حول المحتوى يختلف بين الطلبين. | تجديد القواعد. حفظ إعدادات الرابط الثابت يفعل ذلك من خلال الواجهة ؛ على سطر الأوامر هو مكالمة واحدة. |
| خادم الويب لا يرسل مسارات غير معروفة إلى WordPress | 404 هي صفحة خادم الويب الخاصة بدلاً من الموضوع. لم يتم تشغيل WordPress أبدًا ، لذلك لا يمكن إنتاجه. | إضافة المتحكم الأمامي الاحتياطي بحيث يتم تسليم أي مسار ليس ملف حقيقي إلى index.php. بدونه فقط يحل جذر المستند. |
| تم إيقاف تشغيل AllowOverride ، لذا يتم تجاهل .htaccess | على Apache ، الملف موجود وصحيح وتغييره ليس له أي تأثير على الإطلاق. | تمكين السماح بالتجاوز للدليل، أو نقل القواعد المكافئة إلى المضيف الافتراضي حيث يتم قراءتها دائمًا. |
| هيكل الرابط الثابت لا يمكن للموقع أن يخدمه | بدأت المشكلة مباشرة بعد تغيير بنية الرابط الثابت ، والعودة إلى الروابط الثابتة البسيطة تعيد كل شيء. | اختر بنية وجدد القواعد. الفئة الرائدة أو قاعدة نوع آخر مخصص يصطدم بمسار صفحة موجود هو الفخ المعتاد. |
الإصلاح خطوة بخطوة.
تفترض الأوامر توفر WP-CLI والوصول إلى سطر الأوامر. إن لم يتوفرا، تشرح كل خطوة الإجراء كي تنفذه من لوحة التحكم أو عبر SFTP.
إثبات أن المحتوى لا يزال هناك
إذا تم تحميل هذا ، فلن يتم فقد أي شيء وكان الإصلاح بالكامل في طبقة إعادة الكتابة.
curl -sS -o /dev/null -w '%{http_code}\n' 'https://example.com/?p=1'جدد القواعد.
أول شيء يجب تجربته ، وغالبًا ما يكون الأخير.
wp rewrite flush --hard wp rewrite list --format=count
تحقق من الخادم يقع في الواقع مرة أخرى إلى index.php
هذا هو نموذج nginx. بدونه، يتم تقديم المسارات الموجودة على القرص فقط.
location / { try_files $uri $uri/ /index.php$is_args$args; }استعادة جيدة معروفة .htaccess على أباتشي
كتلة المخزون. إذا لم تغير الكتابة شيئًا ، فسيتم إيقاف تشغيل AllowOverride ويتم تجاهل الملف.
# BEGIN WordPress RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] # END WordPressتأكيد رابط دائم حقيقي يحل الآن
اسأل WordPress عن عنوان URL الذي أنشأه بنفسه ، لذلك لا توجد فرصة لاختبار مسار لم يكن موجودًا أبدًا.
wp post list --post_type=post --posts_per_page=1 --field=url | xargs -I{} curl -sS -o /dev/null -w '%{http_code}\n' {}
ما تتولاه المنصة عنك.
يعد احتياطي وحدة التحكم الأمامية جزءًا من تكوين nginx لكل موقع منذ لحظة إنشائه ، لذلك لا يمكن أن يحدث الإصدار الأكثر شيوعًا من هذا - الخادم الذي يخدم الملفات الموجودة على القرص فقط. لا يوجد .htaccess في مسار الطلب ليتم تجاهله أو الكتابة فوقه بواسطة مكون إضافي أو فقد في الاستعادة ، لأن القواعد تعيش في تكوين خادم الموقع الخاص بدلاً من ملف داخل webroot.
الأسئلة الشائعة.
هل فقدت منشوراتي؟
لماذا لا تزال الصفحة الرئيسية تعمل؟
لقد مسحت القواعد ولم يتغير شيء ماذا الآن؟
هل يمكن أن يكون أحد المكونات الإضافية قد تسبب في ذلك؟
إن لم يكن هذا هو السبب.
قد تبدو هذه الأخطاء متشابهة في المتصفح.