مقالات ووردبريس تُرجع خطأ 404 بينما الصفحة الرئيسية تعمل

إذا كانت صفحتك الرئيسية تُحمَّل بشكل سليم بينما كل مقالة وصفحة فردية تُرجع خطأ 404، فهذا يعني أن قواعد إعادة كتابة الروابط (URL rewrite rules) التي يعتمد عليها ووردبريس مفقودة أو معطوبة في ملف .htaccess. أسرع حل: اذهب إلى الإعدادات ← الروابط الدائمة (Settings → Permalinks) في لوحة تحكم ووردبريس واضغط حفظ التغييرات دون تغيير أي شيء. هذا يُجبر ووردبريس على إعادة توليد كتلة إعادة الكتابة. وإذا استمرّت أخطاء 404، فهذا يعني أن ملف .htaccess غير قابل للكتابة من قِبل خادم الويب، أو أن Apache مُهيّأ لتجاهله، أو أنك تعمل على Nginx (الذي لا يستخدم .htaccess إطلاقًا).

لماذا تعمل الصفحة الرئيسية بينما لا تعمل المقالات

تعمل صفحتك الرئيسية لأن الطلب الموجَّه إلى / يُخدَّم مباشرةً من index.php في جذر المستند. لا حاجة لأي إعادة كتابة.

أما الطلب الموجَّه إلى /2026/my-post/ فمختلف. هذا المسار ليس مجلدًا حقيقيًا على القرص. ولكي يستجيب ووردبريس له، يجب على Apache أن يوجّه الطلب داخليًا إلى index.php، ثم يقرأ ووردبريس قيمة REQUEST_URI، ويطابقها مع قواعد إعادة الكتابة المخزَّنة في خيار rewrite_rules في قاعدة البيانات، ويحلّ متغيرات الاستعلام (WP::parse_request())، ثم يُحمّل المقالة الصحيحة.

عملية التسليم من Apache إلى index.php هي الجزء الذي يتعطّل. فهي تعتمد كليًا على هذه الكتلة في .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

يقول سطرا RewriteCond: إذا لم يكن المسار المطلوب ملفًا حقيقيًا (!-f) ولا مجلدًا حقيقيًا (!-d)، فأرسِله إلى index.php. احذف هذه الكتلة، وسيبحث Apache عن مجلد فعلي باسم /2026/my-post/، ولن يجده، فيُرجع خطأ 404 الخاص به — قبل أن يرى ووردبريس الطلب أصلًا.

لماذا يستبدل ووردبريس ملف .htaccess عند حفظ الروابط الدائمة

هذا هو الجزء الذي تتجاهله معظم الأدلة. عندما تضغط على حفظ في شاشة الروابط الدائمة، يستدعي ووردبريس الدالة flush_rewrite_rules(). وعلى Apache مع ملف .htaccess قابل للكتابة، يؤدي ذلك إلى تشغيل save_mod_rewrite_rules()، التي تعيد توليد الكتلة أعلاه عبر WP_Rewrite::mod_rewrite_rules() وتكتبها مجددًا باستخدام insert_with_markers().

الدالة insert_with_markers() لا تمسّ إلا الأسطر الواقعة بين # BEGIN WordPress و # END WordPress. كل ما هو خارج هذين العلامتين يُترك دون مساس. وكل ما بينهما يُحذف ويُعاد كتابته. بل إن الإصدارات الأحدث من ووردبريس تطبع التحذير مباشرةً داخل الملف:

Any changes to the directives between these markers will be overwritten.

إذًا فعبارة «ووردبريس يستبدل ملف .htaccess الخاص بي» صحيحة لكنها محدودة: فهو لا يعيد كتابة سوى كتلته المُعلَّمة، وفقط عندما يكون الملف قابلًا للكتابة. أما إذا كان الملف غير قابل للكتابة، فإن الحفظ لا يفعل شيئًا على القرص بصمت. يعرض ووردبريس إشعارًا أصفر في شاشة الروابط الدائمة يطلب منك لصق القواعد يدويًا، وإذا فاتك هذا الإشعار فستبقى كتلة إعادة الكتابة مفقودة وتستمر كل مقالة في إرجاع خطأ 404.

كيفية إصلاحها، بالترتيب

1. أعِد حفظ الروابط الدائمة. الإعدادات ← الروابط الدائمة ← حفظ التغييرات. لا حاجة لأي تعديل. هذا يعيد تشغيل عملية التحديث ويعيد كتابة الكتلة. وهو يحلّ غالبية الحالات، بما في ذلك القواعد القديمة بعد عملية نقل الموقع.

2. تأكّد من وجود .htaccess وأنه قابل للكتابة. يوجد في المجلد نفسه الذي يحتوي على wp-config.php. وهو ملف مخفي (dotfile)، لذا فعِّل خيار «إظهار الملفات المخفية» في برنامج FTP لديك أو استخدم:

ls -la /path/to/wordpress/.htaccess

إذا كان مفقودًا، فأنشئه والصق الكتلة الصحيحة. وإذا كان تثبيتك موجودًا في مجلد فرعي، فيجب أن يتطابق RewriteBase وهدف إعادة الكتابة النهائي مع ذلك المسار — والخطأ في هذا هو السبب الأكثر شيوعًا لبقاء الكتلة المُلصقة يدويًا تُرجع خطأ 404. مولّد ملف .htaccess الخاص بنا يبني الكتلة الدقيقة لمسار تثبيتك حتى لا تضطر إلى التخمين.

3. تأكّد من أن Apache مسموح له بقراءة .htaccess. إذا كان المضيف الظاهري (virtual host) يحتوي على AllowOverride None، فإن Apache يتجاهل الملف تمامًا بغضّ النظر عن محتواه. أنت بحاجة إلى AllowOverride All (أو على الأقل FileInfo) على مجلد ووردبريس. وهذا موجود في إعدادات الخادم، وليس في .htaccess، لذا فهو يتطلّب صلاحية الوصول إلى الخادم:

<Directory /var/www/html>
    AllowOverride All
</Directory>

4. تأكّد من تفعيل mod_rewrite. على Debian/Ubuntu:

sudo a2enmod rewrite
sudo systemctl restart apache2

5. على Nginx، لا يوجد ملف .htaccess. توضع إعادة الكتابة في كتلة الخادم (server block) بدلًا من ذلك:

location / {
    try_files $uri $uri/ /index.php?$args;
}

تشخيص سريع: خطأ 404 هذا لِمن؟

انظر إلى صفحة 404. إذا كانت صفحة خطأ غير مُنسَّقة من Apache أو من المضيف، فهذا يعني أن Apache لم يصل إلى ووردبريس إطلاقًا — وهذه مشكلة في .htaccess أو في إعدادات الخادم (الخطوات 2–4). أما إذا كانت صفحة 404 المنسَّقة الخاصة بقالبك، فهذا يعني أن ووردبريس يستقبل الطلب لكنه لا يستطيع مطابقته — القواعد في قاعدة البيانات قديمة، وإعادة حفظ الروابط الدائمة (الخطوة 1) هي الحل. هذا التمييز وحده يوفّر على معظم الناس ساعة من التخمين.

ما لا ينبغي فعله

لا تعطّل جميع إضافاتك أولًا. عَرَض «المقالات تُرجع 404 والصفحة الرئيسية تعمل» بمفرده هو مشكلة في إعادة الكتابة، وليس تعارضًا بين الإضافات. تعطيل الإضافات هو الردّ التلقائي في المنتديات، لكنه لا يمسّ هذه المشكلة تقريبًا أبدًا.

لا تستخدم chmod 777 على ملف .htaccess. يحتاج ووردبريس إلى أن يكون الملف قابلًا للكتابة من قِبل مستخدم خادم الويب، وهذا ليس نفس أن يكون قابلًا للكتابة من قِبل الجميع (world-writable). الصلاحية 644 مع المالك الصحيح آمنة وكافية؛ أما 777 فهي ثغرة أمنية لن تصلح التوجيه على أي حال.

لا تلصق قواعد إعادة كتابة مخصّصة داخل علامتَي # BEGIN WordPress / # END WordPress. سيتم مسحها في المرة التالية التي يحفظ فيها أي شخص الروابط الدائمة. ضع التوجيهات المخصّصة فوق سطر # BEGIN WordPress.

لا تُعِد تثبيت ووردبريس. ملفات النواة سليمة. المشكلة هي كتلة نصية واحدة مفقودة، وليست تثبيتًا تالفًا.

لا تلُم قالبك. توجيه الروابط الدائمة جزء من نواة ووردبريس. لا يمكن للقالب أن يتسبّب فيه ولا أن يصلحه.

لا تزال عالقًا؟

إذا كنت قد أعدت حفظ الروابط الدائمة، وتأكّدت من وجود الكتلة وأنها قابلة للكتابة، وضبطت AllowOverride All، فإن المشتبه به المتبقي هو إضافة أمان أو قاعدة على مستوى المضيف تعيد توليد .htaccess أو تقفله من دون علمك. تحقّق من طابع وقت تعديل الملف مباشرةً بعد حفظ الروابط الدائمة — فإذا لم يتغيّر، فهناك شيء يمنع الكتابة. أعِد توليد كتلة نظيفة باستخدام مولّد ملف .htaccess، والصقها، ثم أعِد الاختبار مع تحديث كامل للصفحة (hard refresh).