ملف .htaccess الافتراضي في WordPress: محتواه وكيفية استرجاعه

ملف .htaccess الافتراضي في WordPress هو الكتلة القصيرة من RewriteEngine التي يكتبها البرنامج في ملف .htaccess بجذر موقعك، لكي تُحل الروابط الدائمة مثل /2026/10/اسم-المقال/ بدلًا من ظهور خطأ 404. يبدو هكذا:

# 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

هذه هي الكتلة الدقيقة، مأخوذة من الدليل الرسمي لـ WordPress حول Apache HTTP Server ومنطق إعادة الكتابة الموثّق في صفحة HelpHub حول الروابط الدائمة الجميلة. إذا لم يكن RewriteBase الخاص بك هو / — مثلًا لأن WordPress مُثبتة في مجلد فرعي — فستطابق تلك المسار بدلًا من ذلك، وهذا أمر طبيعي أيضًا، تولّده WordPress نفسها.

أهم النقاط

• تولّد WordPress هذه الكتلة تلقائيًا، فقط على Apache وLiteSpeed، كل مرة يكون الملف قابلًا للكتابة وتحفظ فيها الإعدادات > الروابط الدائمة.
• إذا كان الملف مفقودًا أو تالفًا، تُظهر جميع الروابط الدائمة باستثناء الصفحة الرئيسية خطأ 404، لأن الصفحة الرئيسية وحدها يمكن إيجادها دون قواعد إعادة الكتابة.
• أي شيء تضيفه أنت أو إضافة ما يجب أن يكون فوق # BEGIN WordPress، وليس داخل العلامات أبدًا — تستبدل WordPress كل ما بينهما في كل حفظ للروابط الدائمة.

تحتاج إلى إعادة بناء الملف بمسارك الحقيقي وبعض القواعد الإضافية؟ مولّد .htaccess لـ WordPress يجمّع ملفًا صحيحًا مباشرة في متصفحك.

ماذا يفعل كل سطر

يُفعّل RewriteEngine On وحدة mod_rewrite في Apache لهذا المجلد؛ بدون هذا السطر، كل ما يليه معطّل.

يخبر RewriteBase / خادم Apache أن المسارات المعاد كتابتها نسبية إلى جذر الموقع. تضبط WordPress هذا بما يتوافق مع مكان الموقع الحقيقي — التثبيت في مجلد فرعي يحصل على RewriteBase /blog/، وليس /.

RewriteRule ^index\.php$ - [L] حارس بلا تأثير: إذا كان الطلب بالفعل index.php، تتوقف إعادة الكتابة ويمر الطلب دون تغيير.

سطرا RewriteCond هما المنطق الحقيقي. يسأل %{REQUEST_FILENAME} !-f و !-d عن “هل هذا الطلب لا يطابق ملفًا حقيقيًا، ولا يطابق مجلدًا حقيقيًا؟”. يجب أن يكون كلاهما صحيحًا ليتم تشغيل القاعدة الأخيرة — بهذا تُقدَّم صورة حقيقية أو ملف CSS أو ملف PDF مرفوع مباشرة ولا تلمس توجيه WordPress أبدًا.

RewriteRule . /index.php [L] هي ما يجعل الروابط الدائمة تعمل: كل ما نجا من الشرطين السابقين — أي ليس ملفًا أو مجلدًا حقيقيًا — يُرسل إلى index.php، ويقرر توجيه WordPress الخاص (WP_Query، علامات إعادة الكتابة) أي مقال أو صفحة أو أرشيف يعنيه هذا الرابط فعليًا.

متى تعيد WordPress إنشاء هذا الملف، ومتى تفشل في ذلك

تحاول WordPress كتابة .htaccess بنفسها كل مرة تفتح فيها الإعدادات > الروابط الدائمة وتضغط حفظ التغييرات، حتى لو لم يتغيّر شيء على الشاشة. يُشغّل هذا الحفظ دالة flush_rewrite_rules()، التي تحاول فتح .htaccess للكتابة وإدراج الكتلة الحالية بين العلامات.

تفشل هذه المحاولة بصمت، تاركة الملف مفقودًا أو قديمًا، عندما:

• يكون الملف أو المجلد الأصل غير قابل للكتابة من قبل المستخدم الذي يشغّل PHP. في العديد من خدمات الاستضافة المشتركة، تعمل PHP بمستخدم نظام مختلف عن المستخدم الذي رفع الملفات عبر FTP، لذا قد تمنع الأذونات التي تبدو صحيحة في عميل FTP كتابة WordPress على أي حال.
• تستخدم nginx. .htaccess آلية خاصة بـ Apache وLiteSpeed فقط (تشرح وثائق Apache نفسها حول AllowOverride السبب: لا يملك nginx ملف تهيئة لكل مجلد يعيد قراءته مع كل طلب). المكافئ في nginx هو توجيه try_files داخل كتلة server، التي لا يمكن تحريرها إلا من قبل من له وصول إلى الخادم؛ لا تستطيع WordPress أبدًا كتابتها عنك.
• يكون AllowOverride معيّنًا على None لمجلد موقعك في تهيئة Apache الرئيسية. هذا هو الإعداد الذي يسمح أساسًا لملف .htaccess بتجاوز أي شيء؛ وثائق Apache واضحة: مع AllowOverride None، “يتم تجاهل ملفات .htaccess تمامًا” — يمكن لـ WordPress كتابة ملف مثالي، وسيبقى بلا تأثير حتى يتغيّر هذا الإعداد على مستوى الخادم.
• تم حذف الملف أو لم يكن موجودًا أصلًا، ولم يُطلق شيء في عملية الحفظ إعادة إنشاء — وأكثر الأسباب شيوعًا أن بنية الروابط الدائمة كانت نفسها مسبقًا، فلم ترَ WordPress أي تغيير لإعادة كتابته.

كيفية استرجاعه يدويًا

إذا أظهرت المقالات والصفحات خطأ 404 بينما تعمل الصفحة الرئيسية بشكل طبيعي، فهذه هي العلامة النموذجية لملف .htaccess مفقود أو معطّل. أصلح الأمر بخطوتين.

1. جرّب أولًا الحل بضغطة واحدة. انتقل إلى الإعدادات > الروابط الدائمة في لوحة تحكم WordPress واضغط حفظ التغييرات دون تغيير أي شيء. إذا كان الملف قابلًا للكتابة، يكفي هذا وحده لإعادة إنشائه وينتهي الأمر.

2. إذا لم يحل ذلك المشكلة، أنشئ الملف يدويًا. اتصل عبر FTP/SFTP أو مدير الملفات الخاص بمزوّد استضافتك، وانتقل إلى المجلد الذي تم تثبيت WordPress فيه (الذي يحتوي على wp-config.php)، وتحقق مما إذا كان .htaccess موجودًا أصلًا — إنه ملف مخفي، وبعض مديري الملفات يخفونه افتراضيًا؛ فعّل “إظهار الملفات المخفية”.

• إذا كان مفقودًا، أنشئ ملفًا جديدًا باسم .htaccess تمامًا (ليس .txt، ولا شيء قبل النقطة).
• الصق الكتلة الافتراضية أعلاه، وعدّل RewriteBase إذا كانت WordPress في مجلد فرعي.
• احفظ وأعد تحميل الرابط الدائم لمقال للتأكد من أنه يعمل.

إذا استمر ظهور 404 بعد ذلك، فقد تحوّل السبب من “.htaccess مفقود” إلى “.htaccess متجاهَل” — اسأل مزوّد استضافتك عن AllowOverride، لأن ملفًا صحيحًا في مجلد أُمر Apache بتجاهله يتصرف بالضبط كغياب الملف.

قواعدك الخاصة في مقابل كتلة WordPress

يمكن لإضافة أو تعديل يدوي إضافة قواعد خاصة — إعادة توجيه، حماية من hotlinking، رؤوس التخزين المؤقت. هذه كتلة مستقلة ومنفصلة عن التي تولّدها WordPress، ولا ينبغي للاثنتين أن تتداخلا أبدًا:

# قواعد أضفتها أنت أو إضافة — فوق علامات WordPress
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # مثال: حماية من hotlinking، قواعد التخزين المؤقت، إلخ.
</FilesMatch>

# 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

كل ما يوضع بين # BEGIN WordPress و # END WordPress يُحذف بصمت في المرة التالية التي يحفظ فيها أي شخص شاشة الروابط الدائمة، لأن WordPress تعامل هذا الجزء كله كملكية خاصة بها وتعيد كتابته بالكامل. هذا هو السبب الأكثر شيوعًا لشكوى “اختفت قاعدتي الخاصة” — لم تُحذف عمدًا أبدًا، بل كانت فقط داخل كتلة تعتبرها WordPress ملكًا لها. بخصوص إعادة التوجيه على وجه التحديد، راجع قواعد إعادة توجيه .htaccess في WordPress بالطريقة الصحيحة لمعرفة أين يجب أن تكون وكيفية تجنب الحلقات.

هذا أيضًا السبب الأكثر شيوعًا لخطأ 500 Internal Server Error مفاجئ مباشرة بعد تحرير الملف: قاعدة منسوخة من منشور منتدى كُتبت لإصدار مختلف من Apache (صيغة Order/Deny من 2.2 مخلوطة بصيغة Require من 2.4) تكسر تحليل الملف بالكامل، بما في ذلك كتلة WordPress الموجودة أسفله، فيسقط الموقع كله — وليس فقط الجزء الذي لمسته.

ما بعد الكتلة الافتراضية

تتعامل الكتلة الافتراضية فقط مع توجيه الروابط الدائمة. إذا أردت أيضًا تشديد الوصول إلى الملفات الحساسة أو إضافة تلك القلة من قواعد .htaccess التي تقلل حقًا من سطح الهجوم — منع تنفيذ PHP في /uploads، رفض الطلبات المباشرة إلى wp-config.php — راجع قواعد أمان .htaccess في WordPress التي تساعد حقًا. وإذا كانت الروابط الدائمة تُظهر 404 لسبب آخر — بنية روابط دائمة خاطئة، طبقة تخزين مؤقت تقدّم قواعد قديمة، تعارضات في المواقع المتعددة بالمجلدات الفرعية — يتناول روابط WordPress الدائمة التي لا تعمل الأسباب الأخرى.

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

ما هو ملف .htaccess الافتراضي في WordPress؟ هو كتلة RewriteEngine التي تكتبها WordPress بين # BEGIN WordPress و # END WordPress لكي تُحل الروابط الدائمة إلى index.php بدلًا من ظهور 404.

ما هو الكود الدقيق لملف .htaccess الافتراضي في WordPress؟ RewriteEngine On، و RewriteBase /، وقاعدة تمرير لـ index.php، وشرطان يتحققان من أن الطلب ليس ملفًا أو مجلدًا حقيقيًا، وقاعدة أخيرة ترسل كل ما عدا ذلك إلى index.php. الكتلة الكاملة مذكورة في بداية هذا الدليل.

لماذا تُظهر جميع مقالاتي خطأ 404 باستثناء الصفحة الرئيسية؟ يمكن إيجاد الصفحة الرئيسية دون أي قاعدة إعادة كتابة؛ كل رابط دائم آخر يحتاج إليها. ينتج ملف .htaccess مفقود أو تالف على Apache هذا النمط بالتحديد.

هل تعيد WordPress إنشاء .htaccess تلقائيًا؟ فقط إذا كان الملف قابلًا للكتابة — إعادة حفظ الإعدادات > الروابط الدائمة تُشغّل ذلك. إذا كان الملف غير قابل للكتابة، أو مفقودًا في استضافة لا تولّده تلقائيًا، أو كان AllowOverride معطّلًا، لا تستطيع WordPress إصلاح ذلك عنك ويجب عليك إنشاء الملف أو تصحيحه يدويًا.

لماذا لا يحتوي nginx على ملف .htaccess خاص بـ WordPress؟ يعمل .htaccess فقط على Apache وLiteSpeed. لا يملك nginx ملف تهيئة لكل مجلد ويتجاهل .htaccess تمامًا؛ يُكتب التوجيه نفسه كقاعدة try_files في كتلة server في nginx.

لماذا تعطّل ملف .htaccess بعد حفظ الروابط الدائمة؟ وُضعت قاعدة خاصة داخل علامات # BEGIN WordPress / # END WordPress بدلًا من فوقها، واستبدلت WordPress هذا الجزء بالكامل عند الحفظ التالي للروابط الدائمة.

---

ابنِ ملف .htaccess نظيفًا وصحيحًا — الكتلة الافتراضية للروابط الدائمة بالإضافة إلى أي قواعد أمان أو إعادة توجيه تحتاجها فعليًا — باستخدام مولّد .htaccess المجاني لـ WordPress.