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

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

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

تأتي هذه القواعد من الكود الذي تستخدمه WordPress لتوليد الكتلة، وهي تطابق دليل .htaccess الخاص بـ WordPress. تكتب WordPress أيضًا ثلاثة أسطر تعليق بعد # BEGIN WordPress مباشرة، تحذّر من أن التعديلات بين العلامتين ستُستبدل. ولا تغيّر هذه الأسطر طريقة عمل القواعد.

في التثبيت داخل مجلد فرعي، تضع WordPress مسار المجلد الفرعي في RewriteBase وفي القاعدة الأخيرة معًا، مثل RewriteBase /blog/ وRewriteRule . /blog/index.php [L]. تستخدم شبكات المواقع المتعددة كتلة مختلفة، ولا تكتب WordPress هذا الملف لها تلقائيًا.

أهم النقاط

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

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

يشغّل RewriteEngine On وحدة mod_rewrite في Apache لهذا المجلد؛ وبدونه لا تفعل قواعد إعادة الكتابة التالية شيئًا.

يترك RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] عنوان URL كما هو (هذا معنى -) وينسخ ترويسة Authorization من الطلب إلى متغير في الخادم. تقرأ WordPress هذا المتغير لتحصل على اسم مستخدم وكلمة مرور أُرسلا في الترويسة، مثل كلمة مرور التطبيق.

يحدد 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 أي مقالة أو صفحة أو أرشيف يعنيه العنوان.

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

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

لا يحل ذلك المشكلة في هذه الحالات:

• الملف أو مجلده غير قابل للكتابة من قبل المستخدم الذي يشغّل PHP. تعرض الشاشة خطأ يفيد بأن ملف .htaccess غير قابل للكتابة، مع القواعد المطلوب لصقها. لدى بعض مزوّدي الاستضافة يعمل PHP بمستخدم نظام مختلف عن مالك الملفات التي ترفعها عبر FTP، لذا قد تمنع الأذونات التي تبدو سليمة في برنامج FTP عمل WordPress.
• أنت تستخدم nginx. يذكر دليل nginx الخاص بـ WordPress أن nginx لا يملك ملف إعدادات على مستوى المجلد مثل .htaccess، وأن WordPress لا تستطيع تغيير إعدادات الخادم. والتوجيه المكافئ هو تعليمة try_files في إعدادات الخادم، وعلى مسؤول النظام تحريرها.
• AllowOverride مضبوط على None لمجلد موقعك في إعدادات Apache الرئيسية. تقول وثائق Apache: “This means .htaccess files are completely ignored unless you explicitly enable them for a directory.” أي أن ملفات .htaccess تُتجاهل تمامًا ما لم تفعّلها صراحة لمجلد ما. قد تكتب WordPress ملفًا مثاليًا ومع ذلك لن يفعل شيئًا. تحتاج قواعد إعادة الكتابة إلى AllowOverride FileInfo (أو All)، وقد يتعين على مزوّد استضافتك تغيير ذلك.
• روابطك الدائمة مضبوطة على الوضع العادي (Plain). لا تحتاج العناوين العادية إلى قواعد إعادة الكتابة، لذا لا تنشئ WordPress الملف لها.

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

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

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

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

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

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

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

قد تضيف إضافة أو تعديل يدوي قواعد خاصة، مثل عمليات إعادة التوجيه أو الحماية من الربط المباشر للصور أو ترويسات التخزين المؤقت. أبقِها خارج كتلة WordPress، وفوقها حتى تعمل قبل قاعدتها الشاملة:

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

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
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 الملف، ويكفي تحميل شاشة الروابط الدائمة لحدوث ذلك. أما الأسطر قبل العلامتين وبعدهما فتبقى. وبخصوص إعادة التوجيه تحديدًا، راجع قواعد إعادة التوجيه في .htaccess لـ WordPress بالطريقة الصحيحة لمعرفة مكانها وكيفية تجنب الحلقات.

يشير خطأ 500 Internal Server Error الذي يظهر بعد تعديل الملف مباشرة إلى ما غيّرته للتو. تذكر وثائق Apache أن سجل الأخطاء سيسمّي على الأرجح تعليمة غير مسموح بها أو خطأ في الصياغة. قد تتسبب في ذلك قواعد منسوخة من شرح قديم: Order أمر غير صالح في Apache 2.4 ما لم تكن mod_access_compat محمّلة. تراجع عن التعديل لإعادة الموقع، ثم اقرأ سجل الأخطاء.

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

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

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

ما هو ملف .htaccess الافتراضي في WordPress؟ هو كتلة RewriteEngine التي تكتبها WordPress بين # BEGIN WordPress و # END WordPress في ملف .htaccess الموجود في جذر موقعك. تمرّر ترويسة Authorization إلى PHP وترسل أي طلب لا يطابق ملفًا أو مجلدًا حقيقيًا إلى index.php.

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

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

هل تعيد WordPress إنشاء .htaccess تلقائيًا؟ نعم، على Apache أو LiteSpeed مع mod_rewrite، إذا كانت الروابط الدائمة المخصصة مفعّلة وكانت WordPress قادرة على الكتابة هناك. يكفي فتح الإعدادات > الروابط الدائمة. يحتاج الملف المفقود إلى مجلد قابل للكتابة، ويجب أن يكون الملف الموجود نفسه قابلًا للكتابة. وإلا تعرض الشاشة خطأ، مع القواعد التي عليك لصقها يدويًا.

لماذا لا يحتوي nginx على ملف .htaccess خاص بـ WordPress؟ لا يملك nginx ملف إعدادات على مستوى المجلد مثل ملف .htaccess في Apache. يُكتب التوجيه نفسه كقاعدة try_files في إعدادات خادم nginx، وعلى مسؤول النظام تحريرها لأن WordPress لا تستطيع تغييرها.

لماذا تعطّل ملف .htaccess بعد حفظ الروابط الدائمة؟ تحقق مما إذا كانت قاعدة مخصصة قد وُضعت بين العلامتين # BEGIN WordPress و # END WordPress. تستبدل WordPress كل ما بينهما عند تحديث الملف، فتضيع تلك القاعدة. أبقِ القواعد المخصصة فوق العلامتين.

المصادر

• WordPress Advanced Administration: .htaccess
• WordPress Advanced Administration: Nginx
• الكود المصدري لـ WordPress: class-wp-rewrite.php، options-permalink.php، misc.php، load.php، user.php، vars.php
• Apache HTTP Server 2.4: .htaccess files، mod_rewrite، Upgrading to 2.4

---

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