ما بنية ملفات ووردبريس وكيف تضبط صلاحياتها بأمان؟

في اللحظة التي تفتح فيها مدير الملفات لأول مرّة وتدخل مجلّد موقعك، تصدمك القائمة: عشرات الملفات بأسماء غامضة تبدأ كلها بـwp-، ومجلّدات لا تعرف أيّها مهمّ وأيّها يمكن الاستغناء عنه. الغريزة الأولى عند أغلب المبتدئين واحدة من اثنتين: إمّا الخروج فورًا وعدم لمس شيء، وإمّا الشجاعة الزائدة وحذف ما يبدو غير ضروري — وكلاهما مكلف.

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

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

الجزء الثاني من القصّة — والأكثر إهمالًا في المحتوى العربي — هو الصلاحيات. رقم صغير مثل 644 أو 755 يحدّد من يستطيع قراءة ملفك ومن يستطيع الكتابة فيه ومن يستطيع تنفيذه. اضبطه بشدّة زائدة فيتعطّل رفع الصور والتحديثات؛ وارخِه فتفتح بابًا للمهاجمين. في هذا الدليل نمشي في البنية كاملة أولًا، ثم ندخل عالم الصلاحيات بتفصيل عملي: ما الرقم الصحيح لكل شيء، وكيف تصلحه بأمر واحد، ولماذا يخدعك الرقم أحيانًا لأن المشكلة الحقيقية في المالك لا في الصلاحية.

أين يسكن موقعك على الخادم فعلًا؟

قبل أن ندخل في الملفات، نحتاج أن نتّفق على نقطة البداية: الجذر (Document Root)، وهو المجلّد الذي يعرضه الخادم عندما يزور أحدهم اسم نطاقك.

على أغلب الاستضافات المشتركة التي تعمل بلوحة cPanel، اسم هذا المجلّد public_html. وعلى بعض اللوحات الأخرى قد يكون httpdocs أو www أو htdocs. وعلى خادم تديره بنفسك قد يكون مسارًا مثل /var/www/example.com/public. الاسم يختلف، لكن الدور واحد: كل ما بداخله متاح للعالم عبر المتصفّح، وكل ما خارجه غير متاح. إن كنت لا تعرف بعد كيف تصل إلى هذا المجلّد أصلًا، فابدأ من دليل استخدام لوحة cPanel للمبتدئين الذي يشرح مدير الملفات خطوة بخطوة، أو من رفع الملفات عبر FTP وبرنامج FileZilla إن كنت تفضّل العمل من جهازك مباشرة.

هنا فرق مهمّ يخلط بين المبتدئين: هل ووردبريس مثبّت في الجذر مباشرة أم داخل مجلّد فرعي؟ إن ثبّتّه في الجذر، فستجد wp-admin وwp-includes وwp-content مباشرة داخل public_html، ورابط موقعك يكون example.com. وإن ثبّتّه داخل مجلّد فرعي مثل public_html/blog، فستجدها هناك ورابطك example.com/blog. لا شيء خطأ في الحالتين، لكن معرفة أيّهما لديك تحدّد المسار الذي ستكتبه في أي شرح تقني تقرؤه لاحقًا، وتحدّد أيضًا أين تبحث عن الملفات عند أي مشكلة.

الشكل العام لتثبيت نظيف يبدو هكذا:

public_html/
├── wp-admin/            ← نواة: لوحة التحكّم (لا تعدّل)
├── wp-includes/         ← نواة: مكتبات ووردبريس (لا تعدّل)
├── wp-content/          ← ملفّاتك أنت
│   ├── themes/
│   ├── plugins/
│   ├── uploads/
│   ├── mu-plugins/      ← قد لا يوجد افتراضيًا
│   ├── languages/
│   └── upgrade/         ← مؤقّت أثناء التحديث
├── wp-config.php        ← إعدادات الاتصال والمفاتيح الأمنية
├── .htaccess            ← قواعد الخادم (أباتشي / LiteSpeed)
├── index.php
├── wp-load.php
├── wp-settings.php
├── wp-login.php
├── xmlrpc.php
└── ... باقي ملفات النواة

لاحظ أن المجلّدات الثلاثة الكبرى تظهر في الأعلى دائمًا، وأن ملفات الجذر متناثرة بينها بأسماء تبدأ كلها تقريبًا بـwp-. هذا الترتيب ليس تفصيلًا جماليًا، بل هو خريطة المسؤوليات: من يملك تعديل ماذا.

ملفات الجذر: ما وظيفة كل واحد منها؟

ملفات الجذر هي أوّل ما تراه، وأخطر ما يمكن العبث به. أغلبها ملفات نواة لا تحتاج للمسها أبدًا، لكن اثنين منها — wp-config.php و.htaccess — استثناء: هما ملفّاك أنت، ولن يمسّهما التحديث.

wp-config.php — أخطر ملف في موقعك

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

النتيجة المباشرة: من يقرأ هذا الملف يملك قاعدة بياناتك. لذلك يستحقّ معاملة خاصّة في الصلاحيات — سنعود إليه بالتفصيل بعد قليل. ونقطة مهمّة كثيرًا ما تُغفَل: بعض الاستضافات ترفع هذا الملف مستوى واحدًا فوق الجذر (خارج public_html) لأن ووردبريس يبحث عنه في المجلّد الأب تلقائيًا إن لم يجده. هذا ترتيب أكثر أمانًا لأن الملف يصبح خارج متناول المتصفّح تمامًا.

قاعدة عملية: لا تعدّل هذا الملف من دون نسخة احتياطية منه على جهازك. فاصلة منقوطة ناقصة أو مسافة زائدة بعد وسم الإغلاق تكفي لإسقاط الموقع كاملًا بشاشة بيضاء.

.htaccess — الملف الذي يظهر ويختفي

إن كان خادمك يعمل بأباتشي أو LiteSpeed، فستجد ملفًّا اسمه .htaccess في الجذر. النقطة في بداية الاسم تجعله مخفيًّا افتراضيًا — ولهذا يقسم كثيرون إنه غير موجود، ثم يجدونه بمجرّد تفعيل خيار «إظهار الملفات المخفية» في مدير الملفات أو برنامج FTP.

ووردبريس يكتب فيه تلقائيًا كتلة صغيرة محاطة بتعليقَي # BEGIN WordPress و# END WordPress، وظيفتها توجيه كل الطلبات إلى index.php حتى تعمل الروابط الدائمة الجميلة. كل ما تكتبه أنت خارج هذه الكتلة يبقى كما هو، وكل ما تكتبه بداخلها قد يُمحى عند إعادة حفظ الروابط الدائمة.

استخداماته تتجاوز الروابط بكثير: إعادة التوجيه، إجبار HTTPS، منع الوصول لملفات معيّنة، تفعيل ضغط وتخزين المتصفّح. ولأن الموضوع واسع بذاته، تجد قواعده كاملة بالأمثلة في الدليل الشامل لملف htaccess. ما يهمّنا هنا فقط: هو ملفك، وليس ملف نواة، ولن يمسّه أي تحديث. وإن كان خادمك يعمل بـNginx فلن تجد هذا الملف أصلًا — القواعد تُكتب في إعدادات الخادم مباشرة ولا تملك أنت تعديلها على استضافة مشتركة.

المجلّدات الثلاثة الكبرى: من يملك تعديل ماذا؟

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

wp-admin: مطبخ لوحة التحكّم

كل ما تراه بعد تسجيل الدخول — قائمة المقالات، شاشة الإعدادات، مدير الوسائط، محرّر الإضافات — يعيش هنا. هذا المجلّد هو التجسيد البرمجي لما نشرحه مفاهيميًّا في تعريف wp-admin في الويكي.

النقطة الحاسمة: لا يوجد أي سبب مشروع لتعديل ملف داخل wp-admin. إن قرأت شرحًا يطلب منك ذلك فالشرح قديم أو خاطئ. ووردبريس يوفّر خطّافات (hooks) وفلاتر رسمية لتغيير سلوك لوحة التحكّم من داخل إضافة صغيرة أو ملف functions.php في القالب الابن — وهذه التعديلات تنجو من التحديثات، بينما تعديلك المباشر يُمحى في أول تحديث أمني.

وهناك جانب أمني: تعديل ملف نواة يجعل موقعك يفشل في فحوص سلامة الملفات، ويصعّب على أي أداة فحص التمييز بين تعديلك أنت وتعديل مهاجم زرع شيفرة خبيثة. مواقع كثيرة اكتشفت اختراقها متأخّرًا لأن أصحابها اعتادوا رؤية «ملفات نواة معدّلة» في التقارير وتجاهلوها.

wp-includes: محرّك ووردبريس

إن كان wp-admin هو الواجهة، فـwp-includes هو المحرّك. هنا تعيش الدوال التي يستدعيها كل قالب وكل إضافة: التعامل مع قاعدة البيانات، بناء الاستعلامات، إدارة المستخدمين والصلاحيات، توليد الروابط، نظام الخطّافات نفسه. وهنا أيضًا تعيش مكتبات جافاسكربت التي يشحنها ووردبريس معه مثل jQuery.

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

داخل wp-content: المجلّد الوحيد الذي يخصّك

الآن ندخل الجزء الأهمّ عمليًّا. كل ما بنيته وثبّتّه ورفعته موجود هنا، ولا شيء منه يأتي مع ووردبريس افتراضيًا سوى قالب واحد وإضافة أو اثنتين.

themes — القوالب

كل قالب يسكن في مجلّد باسمه داخل themes. يمكنك أن تحتفظ بعشرة قوالب مثبّتة وواحد فقط مفعّل، لكن الأفضل حذف ما لا تستخدمه: القالب غير المفعّل ما زال ملفًّا على الخادم يحتاج تحديثات أمنية، ومن يتجاهلها يترك ثغرة نائمة. القاعدة العملية: احتفظ بالقالب المفعّل + قالب افتراضي واحد كخطّة طوارئ، واحذف الباقي. وإن كنت لم تحسم خيارك بعد فـدليل اختيار قالب ووردبريس المناسب يساعدك على الاختيار قبل أن تملأ المجلّد بتجارب.

النقطة الأهمّ هنا: لا تعدّل ملفات القالب مباشرة إن كان قالبًا تحصل منه على تحديثات. تحديث القالب يستبدل ملفاته تمامًا كما تفعل النواة، فيمحو تعديلاتك. الحلّ الصحيح هو القالب الابن (Child Theme): مجلّد صغير مستقلّ يرث كل شيء من القالب الأب ويحتوي فقط على ما غيّرته أنت. هكذا يبقى تخصيصك ناجيًا من كل تحديث.

plugins — الإضافات

نفس المنطق: مجلّد لكل إضافة. وهنا تكمن أشهر حيلة إنقاذ في عالم ووردبريس: إعادة تسمية مجلّد الإضافة تعطّلها فورًا. إن انهار موقعك بعد تحديث إضافة ولم تعد لوحة التحكّم تُفتح، تدخل عبر مدير الملفات أو FTP، وتعيد تسمية مجلّد الإضافة المشتبه بها (مثلًا من some-plugin إلى some-plugin-off)، فلا يجدها ووردبريس ويعطّلها تلقائيًّا ويعود الموقع. ولو أردت تعطيل كل الإضافات دفعة واحدة، أعد تسمية مجلّد plugins نفسه. هذه الحيلة وغيرها مشروحة بالتفصيل في دليل حلّ أخطاء ووردبريس الشائعة.

للتذكير: كل إضافة شيفرة إضافية تعمل مع كل طلب، وكل إضافة سطح هجوم إضافي. اختر باعتدال — وقائمة الإضافات الأساسية لأي موقع نقطة بداية أفضل من تثبيت كل ما تراه في نتائج البحث.

uploads — مكتبة الوسائط

كل صورة ترفعها من لوحة التحكّم تهبط هنا، مرتّبة افتراضيًا في مجلّدات 2026/07. ولأن ووردبريس يولّد عدّة مقاسات لكل صورة (مصغّرة، متوسّطة، كبيرة، وأي مقاسات يطلبها قالبك)، فإن صورة واحدة قد تنتج ستّة ملفات فعلية أو أكثر. هذا يفسّر لماذا يصبح uploads أثقل مجلّد في الموقع بفارق كبير، ولماذا يستهلك عدد الملفات حصّتك على الاستضافة المشتركة أسرع ممّا تتوقّع. ضغط الصور قبل الرفع يوفّر مساحة مضاعفة لهذا السبب بالذات.

نقطة أمنية جوهرية: uploads هو المجلّد الوحيد الذي يجب أن يكون قابلًا للكتابة من الخادم دائمًا، وهذا بالضبط ما يجعله الهدف الأول لأي مهاجم. السيناريو الكلاسيكي: يستغلّ ثغرة في إضافة لرفع ملف PHP خبيث داخل uploads، ثم يناديه من المتصفّح فيُنفَّذ. الوقاية المعروفة هي منع تنفيذ PHP داخل wp-content/uploads عبر قاعدة في ملف htaccess أو في إعدادات الخادم — إجراء من سطرين يغلق فئة كاملة من الهجمات.

mu-plugins — الإضافات الإلزامية

اسم المجلّد اختصار لـ«Must-Use Plugins»، وهو مجلّد لا ينشئه ووردبريس افتراضيًا — إمّا تنشئه أنت وإمّا ينشئه مضيفك. وما يجعله مختلفًا جذريًّا عن plugins العادي أمران:

الأول: أي ملف PHP توضع فيه يعمل تلقائيًّا بلا تفعيل. لا يظهر له زرّ «تفعيل»، ويُحمَّل قبل الإضافات العادية.

الثاني — والأهمّ: لا يمكن تعطيله من لوحة التحكّم إطلاقًا. يظهر في تبويب منفصل باسم «إلزامية» لكن بلا زرّ تعطيل ولا حذف. الطريقة الوحيدة لإيقافه هي حذف الملف من الخادم.

هذا يجعله سلاحًا ذا حدّين. مفيد جدًّا للمطوّرين وللمضيفين الذين يريدون فرض إعداد لا يستطيع العميل تعطيله بالخطأ. وخطير جدًّا لأن المهاجمين يعرفونه: زرع باب خلفي داخل mu-plugins يجعله يعمل مع كل طلب، ولا يظهر في قائمة الإضافات المعتادة، ولا يمكن تعطيله من اللوحة. لهذا يجب أن يكون هذا المجلّد ضمن أوّل ما تفحصه عند الاشتباه. ملاحظة تقنية أخيرة: ووردبريس يقرأ ملفات PHP في المستوى الأول فقط من mu-plugins ولا يدخل المجلّدات الفرعية — فإن كانت إضافتك مجلّدًا كاملًا، تحتاج ملف محمّل صغير في المستوى الأول يستدعيها.

languages و upgrade

مجلّد languages يحتوي ملفات الترجمة: النواة في مستواه الأول، وترجمات الإضافات في languages/plugins وترجمات القوالب في languages/themes. لا تحتاج للمسه ما لم تكن تصحّح ترجمة بنفسك؛ ووردبريس يديره تلقائيًا عندما تغيّر لغة الموقع من الإعدادات.

مجلّد upgrade مساحة عمل مؤقّتة: عندما يحدّث ووردبريس نفسه أو إضافة، ينزّل الحزمة ويفكّها هنا قبل نقلها لمكانها. في الوضع الطبيعي يكون فارغًا تقريبًا. إن وجدته ممتلئًا بمجلّدات قديمة، فهذا أثر تحديثات فشلت في منتصف الطريق — وحذف محتوياته آمن تمامًا. والأهمّ: إن لم يكن هذا المجلّد قابلًا للكتابة، ستفشل كل التحديثات التلقائية بلا رسالة واضحة. حذف المجلّد نفسه آمن أيضًا لأن ووردبريس يعيد إنشاءه عند الحاجة — إن كان يملك صلاحية ذلك.

ووردبريس أسرع وأكثر أمانًا بلا إعدادات

ووردبريس المُدار من wpressly: سرعة وكاش وحماية وتحديثات تلقائية مع دعم عربي — ركّز على محتواك لا على السيرفر.

جرّب ووردبريس المُدار

ما الذي يجوز لمسه وما الذي لا يجوز؟

الآن نستطيع اختصار كل ما سبق في قاعدة واحدة قابلة للتطبيق: إن كان الملف سيُستبدَل عند التحديث، فلا تعدّله؛ وإن كان لن يُستبدَل، فهو مسؤوليّتك.

من هذه القاعدة تنبع القرارات كلها:

تريد تغيير شكل الموقع؟ لا تلمس ملفات القالب الأب. أنشئ قالبًا ابنًا وضع تعديلاتك فيه. تفاصيل ذلك كاملة في كيف تخصّص قالب ووردبريس.

تريد إضافة وظيفة برمجية صغيرة؟ ضعها في functions.php الخاص بالقالب الابن، أو — وهو الأفضل للوظائف غير المرتبطة بالشكل — في إضافة صغيرة خاصّة بك. لماذا الأفضل؟ لأن الوظيفة التي تكتبها في القالب تختفي يوم تغيّر القالب، بينما الإضافة تبقى.

تريد تعطيل شيء في لوحة التحكّم؟ استخدم خطّافًا، لا تعديلًا في wp-admin.

تريد تغيير سلوك إضافة اشتريتها؟ لا تعدّل ملفاتها — سيمحو التحديث عملك. ابحث عن خطّاف توفّره الإضافة، أو تواصل مع مطوّرها.

وقبل أي تعديل جادّ على موقع حيّ، جرّبه على نسخة تجريبية منفصلة. أغلب خطط الاستضافة المحترمة توفّر اليوم زرًّا واحدًا يُنشئ لك نسخة اختبار كاملة، فتتحوّل التعديلات المخيفة إلى تجربة بلا مخاطرة على الزوّار.

الصلاحيات: ماذا تعني 644 و755 فعلًا؟

ندخل الآن الجزء الذي يخيف الجميع بلا سبب. الأمر أبسط بكثير ممّا يبدو بمجرّد فهم منطق الأرقام.

كل ملف ومجلّد على خادم لينكس له ثلاث فئات من «الناس»:

• المالك (User) — الحساب الذي يملك الملف.
• المجموعة (Group) — مجموعة حسابات لها معاملة مشتركة.
• الآخرون (Others) — أي حساب آخر على الخادم، بما فيه عمليات لا تخصّك.

ولكل فئة ثلاث صلاحيات ممكنة: القراءة (r) = 4، الكتابة (w) = 2، التنفيذ (x) = 1. تجمع الأرقام لتحصل على رقم واحد لكل فئة، وتصفّ الأرقام الثلاثة بالترتيب: المالك، ثم المجموعة، ثم الآخرون.

فـ644 تعني: المالك يقرأ ويكتب (6)، والمجموعة تقرأ (4)، والآخرون يقرؤون (4). و755 تعني: المالك كل شيء (7)، والمجموعة تقرأ وتنفّذ (5)، والآخرون كذلك (5).

سؤال يربك المبتدئين: لماذا تحتاج المجلّدات صلاحية «تنفيذ» أصلًا؟ لأن معنى «التنفيذ» يختلف على المجلّد: هو صلاحية الدخول إلى المجلّد والوصول لما بداخله. مجلّد بصلاحية 644 (بلا تنفيذ) لا يمكن الدخول إليه إطلاقًا، وستحصل على خطأ 403 على كل ما بداخله. هذا سبب القاعدة الشهيرة: المجلّدات 755 والملفات 644، لا العكس ولا الخلط.

جدول الصلاحيات الموصى بها

لماذا 640 لـwp-config.php؟ لأن الرقم يعني: المالك يقرأ ويكتب، المجموعة تقرأ، والآخرون لا شيء. على خادم مشترك يستضيف مئات الحسابات، هذا يمنع أي حساب آخر على نفس الخادم من قراءة كلمة مرور قاعدة بياناتك. بعض إعدادات الخوادم لا تقبل هذا التشديد وتردّ بخطأ 500 — إن حدث ذلك، أعده إلى 644 وحاول 600 إن كان PHP يعمل بمستخدمك مباشرة.

كيف تصلح الصلاحيات دفعة واحدة؟

عبر مدير الملفات أو FileZilla تستطيع تغيير الصلاحيات بالفأرة، وهذا كافٍ لملف أو اثنين. أمّا لتصحيح موقع كامل فتحتاج سطر الأوامر عبر SSH — وإن كان ذلك جديدًا عليك فابدأ من أساسيات SSH للمبتدئين.

الأمران الصحيحان، ويُنفَّذان من داخل مجلّد الموقع:

# انتقل أولًا إلى جذر الموقع — تحقّق بـ pwd قبل أي شيء
cd ~/public_html
pwd

# كل المجلّدات إلى 755
find . -type d -exec chmod 755 {} \;

# كل الملفات إلى 644
find . -type f -exec chmod 644 {} \;

# ثم شدّد ملف الإعدادات وحده
chmod 640 wp-config.php

النقطة . في بداية الأمر تعني «المجلّد الحالي وكل ما بداخله». وهنا أخطر خطأ ممكن في هذا المقال كلّه: تشغيل هذين الأمرين وأنت في المجلّد الخطأ. إن نفّذتهما في مجلّد المنزل ~ مثلًا، فستغيّر صلاحيات ملفات إعدادات حسّاسة خارج الموقع، وقد تكسر الوصول إلى الخادم عبر SSH لأن مجلّد .ssh وملف authorized_keys لهما صلاحيات صارمة جدًّا (700 و600) يرفض SSH العمل بدونها. نفّذ pwd قبل كل مرّة وتأكّد أن المخرَج هو مسار موقعك بالضبط.

نسخة أسرع للمواقع الكبيرة تستخدم + بدل \; فتشغّل chmod مرّة واحدة لكل دفعة بدل مرّة لكل ملف:

find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

وللاطّلاع على الوضع الحالي قبل التغيير:

# عرض الصلاحيات والمالك لمحتويات المجلّد
ls -la

# البحث عن أي شيء بصلاحية 777 في الموقع
find . -perm 0777

المالك والمجموعة: السبب الحقيقي وراء أغلب المشاكل

هنا الجزء الذي يغيب عن 90% من الشروحات، وهو سبب حيرة كثيرين: ضبطتُ كل الصلاحيات على 755 و644 بالضبط، ومع ذلك ووردبريس لا يستطيع الرفع ولا التحديث.

السبب أن الصلاحية الرقمية نصف المعادلة فقط. النصف الآخر هو: من هو المالك؟ عندما يحاول ووردبريس كتابة ملف، فإن الذي يكتب فعليًّا هو عملية PHP التي يشغّلها الخادم بمستخدم معيّن. إن كان الملف مملوكًا لمستخدم مختلف عن مستخدم PHP، فإن ووردبريس يقع في فئة «الآخرون» — و«الآخرون» في 644 لا يملكون صلاحية كتابة. النتيجة: فشل صامت، مع صلاحيات تبدو مثالية على الورق.

هذه المشكلة نادرة على الاستضافة المشتركة المُدارة جيّدًا، لأن المضيف يضبط الملكية تلقائيًّا. وهي شائعة جدًّا على خادم تديره بنفسك: تنسخ الملفات عبر SSH بمستخدم root أو بمستخدمك الشخصي، بينما يعمل الخادم بمستخدم مثل www-data. النتيجة: كل شيء يبدو صحيحًا وكل شيء معطّل.

العلاج تصحيح الملكية لا رفع الرقم:

# مثال: جعل مستخدم الخادم www-data يملك ملفات الموقع
sudo chown -R www-data:www-data /var/www/example.com

# لمعرفة المستخدم الذي يعمل به الخادم فعليًّا
ps aux | grep -E 'apache|nginx|php-fpm' | head

تحذير: لا تنفّذ chown عشوائيًّا على استضافة مشتركة — غالبًا لن تملك الصلاحية أصلًا، وإن ملكتها فقد تكسر الحساب. اسم المستخدم يختلف بين الأنظمة (www-data على دبيان وأوبنتو، apache أو nginx على روكي ولينكس المشتقّة، واسم حسابك على إعدادات PHP-FPM المعزولة لكل مستخدم). تحقّق أولًا، ثم نفّذ.

جاهز لإطلاق موقعك على استضافة سريعة؟

خطط استضافة wpressly على أقراص NVMe مع SSL مجاني ودعم عربي — اختر الخطة المناسبة لحجمك وانطلق اليوم.

اكتشف خطط الاستضافة

تشخيص المشاكل: أعراض الصلاحيات الخاطئة وحلّها

هذه أشهر أربعة أعراض في العالم الحقيقي، وكيف تميّز بينها بسرعة.

فشل رفع الصور

الرسالة المعتادة: «فشل في كتابة الملف على القرص» أو «المجلّد المحدّد غير قابل للكتابة». ثلاثة احتمالات بالترتيب: (1) مجلّد uploads بصلاحية أقلّ من 755؛ (2) ملكيته لا تطابق مستخدم الخادم — وهذا الأشيع على الخوادم الخاصة؛ (3) امتلأت مساحة الحساب أو حصّة عدد الملفات، وهي حالة تُخطئ التشخيص كثيرًا لأن الرسالة نفسها تظهر. ابدأ دائمًا بفحص المساحة قبل أن تعبث بالصلاحيات: df -h على خادمك أو مؤشّر المساحة في لوحة التحكّم.

احتمال رابع أقلّ شيوعًا: مسار مجلّد الرفع محدّد يدويًّا بمسار خاطئ في إعدادات ووردبريس أو عبر ثابت في wp-config.php — يحدث عادةً بعد نقل موقع بين خادمين.

تعذّر تحديث الإضافات أو النواة

الأعراض: رسالة «تعذّر إنشاء المجلّد» أو تجمّد شريط التقدّم أو رجوع للصفحة بلا تغيير. الجاني الأول هو wp-content/upgrade — إمّا غير موجود، أو غير قابل للكتابة، أو ممتلئ ببقايا تحديثات فشلت سابقًا. الحلّ الأسرع: احذف محتوياته كاملة، وتأكّد أن صلاحيته 755 وملكيّته صحيحة، ثم أعد المحاولة. وإن كان المجلّد غير موجود، أنشئه يدويًّا بنفس الصلاحية.

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

خطأ 403 Forbidden

الفرق الحاسم: هل يظهر على الموقع كلّه أم على صفحة واحدة؟

إن ظهر على الموقع كلّه، فالسبب غالبًا مجلّد بلا صلاحية دخول — راجع صلاحية public_html نفسها وكل المجلّدات فوقه في المسار. أحيانًا يكون السبب أبسط: غياب ملف index.php من الجذر بينما الخادم لا يسمح بعرض قائمة المجلّد.

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

ووردبريس يطلب بيانات FTP عند تثبيت إضافة

هذا العَرَض تحديدًا شبه دليل قاطع على مشكلة ملكية، لا صلاحية. ما يحدث: ووردبريس يحاول الكتابة مباشرة، يفشل، فيفترض أنه لا يملك وصولًا لنظام الملفات، ويعرض عليك نموذج بيانات FTP كخطّة بديلة ليكتب عبره.

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

الحلّ الخاطئ الشائع — والذي ستجده في نصف نتائج البحث — هو إضافة define('FS_METHOD', 'direct'); إلى wp-config.php. هذا لا يصلح شيئًا، بل يجبر ووردبريس على المحاولة المباشرة رغم فشلها، فيتحوّل السؤال المزعج إلى خطأ صامت أصعب في التشخيص. استخدمه فقط بعد أن تصحّح الملكية فعلًا وتتأكّد أن الكتابة تعمل.

والحلّ الأسوأ على الإطلاق: وضع 777 على wp-content ليعمل التثبيت. نعم قد يعمل، ونعم ستدفع الثمن لاحقًا.

ماذا تنسخ احتياطيًا وماذا يمكن تجاهله؟

فهم البنية يوفّر عليك مساحة ووقتًا في النسخ الاحتياطي، لأن نصف الملفات على موقعك تقريبًا قابل للتنزيل من جديد مجانًا في أي لحظة.

الخلاصة في سطر: wp-content + wp-config.php + قاعدة البيانات = موقعك كاملًا. ما عداها ملفات نواة يمكن تنزيلها من ووردبريس في أي وقت. هذا يقلّص حجم نسختك بشكل ملموس ويسرّع استعادتها. أمّا استراتيجية النسخ نفسها — كم مرّة، وأين تُخزَّن، وكيف تختبر الاستعادة — فموضوع مستقلّ نغطّيه في الدليل الشامل للنسخ الاحتياطي لووردبريس.

خمسة أخطاء متكرّرة تجنّبها

تعديل ملف نواة «لمرّة واحدة فقط». لا توجد مرّة واحدة. التعديل يضيع في أول تحديث، ثم تعيده، ثم تنساه، ثم تحتار لماذا يعود السلوك القديم كل شهر.

حذف مجلّدات لتوفير مساحة. حذف wp-includes أو مجلّد قالب مفعّل يسقط الموقع فورًا. إن كانت المساحة ضيّقة فابدأ بضغط الصور وتنظيف النسخ القديمة وupgrade وcache — لا بملفات النواة.

رفع ملفات خارج public_html وانتظار ظهورها. الملف الذي لا يقع داخل الجذر لا يراه المتصفّح أبدًا، مهما انتظرت أو حدّثت الصفحة.

استخدام محرّر الملفات المدمج في لوحة التحكّم لتعديل خطير. خطأ صياغة واحد فيه يسقط الموقع، وقد تفقد قدرتك على الدخول لإصلاحه لأن المحرّر نفسه داخل اللوحة. عطّل هذا المحرّر تمامًا — إنه أيضًا من أوّل ما يستغلّه مهاجم حصل على حساب إداري، كما نفصّل في دليل تأمين موقع ووردبريس.

نسيان الملفات المخفية عند النقل. عند نقل موقع بين استضافتين، ينسى كثيرون .htaccess لأنه لا يظهر افتراضيًّا، فتنكسر الروابط الدائمة وإعادة التوجيه في الموقع الجديد. فعّل «إظهار الملفات المخفية» قبل أي عملية نقل.

موقع آمن يبدأ من استضافة آمنة

استضافة wpressly تأتيك بـSSL مجاني وحماية مدمجة ونسخ احتياطي تلقائي — أمّن موقعك وزوّارك من اليوم الأول.

اكتشف الاستضافة الآمنة

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

هل يمكنني حذف مجلّد wp-includes لتوفير مساحة؟

لا إطلاقًا. wp-includes يحتوي المكتبات والدوال الأساسية التي يستدعيها ووردبريس مع كل طلب، وحذفه يوقف الموقع فورًا بخطأ فادح. حجمه بضعة ميجابايتات فقط ولا يشكّل عبئًا يُذكر مقارنةً بمجلّد uploads الذي يمثّل عادةً أكثر من 90% من حجم الموقع. إن كنت تبحث عن مساحة، ابدأ بضغط الصور وحذف مقاسات الصور غير المستخدمة، وتنظيف بقايا wp-content/upgrade وcache، وحذف القوالب والإضافات غير المفعّلة — هذه مصادر مساحة حقيقية وآمنة.

ما الصلاحية الصحيحة لملف wp-config.php بالضبط؟

القيمة الموصى بها هي 640: المالك يقرأ ويكتب، المجموعة تقرأ، والآخرون لا شيء. وعلى خادم خاص تتحكّم فيه بالكامل يمكنك التشديد إلى 600 فيمنع حتى المجموعة. الهدف واحد: منع أي حساب آخر على الخادم من قراءة بيانات اتصال قاعدة بياناتك. بعض إعدادات الاستضافة لا تقبل هذا التشديد وتردّ بخطأ 500 عند فتح الموقع — إن حدث ذلك أعد الملف فورًا إلى 644 واسأل الدعم عن الحدّ الذي يسمح به إعدادهم بدل تجربة أرقام عشوائيًّا.

لماذا لا أجد مجلّد mu-plugins في موقعي؟

لأن ووردبريس لا ينشئه افتراضيًا. المجلّد اختياري تمامًا، ولا يظهر إلا إذا أنشأته أنت أو أنشأه مضيفك أو أنشأته إضافة تحتاجه. غيابه ليس مشكلة ولا نقصًا في التثبيت. وإن أردت استخدامه، أنشئه بنفسك داخل wp-content بصلاحية 755 وضع فيه ملف PHP في المستوى الأول — سيعمل تلقائيًّا بلا تفعيل. لكن تذكّر القاعدة الحاسمة: ما تضعه هناك لا يمكن تعطيله من لوحة التحكّم إطلاقًا، والطريقة الوحيدة لإيقافه هي حذف الملف من الخادم مباشرة.

هل صلاحية 777 آمنة إذا استخدمتها مؤقّتًا فقط ثم أعدتها؟

لا. «مؤقّتًا» كلمة مطاطة في الواقع العملي: الفحوص الآلية التي تبحث عن مجلّدات قابلة للكتابة تعمل على مدار الساعة، ونافذة الدقائق تكفي. والأخطر أن أغلب الناس ينسون الإعادة فعلًا، فتبقى 777 شهورًا. وحتى لو التزمت، فالحلّ نفسه خاطئ: إن كان الرفع لا يعمل بـ755 فالمشكلة في ملكية الملفات (user/group) لا في الرقم، ورفع الرقم يخفي العَرَض ولا يعالج السبب. صحّح الملكية بـchown أو اطلب من الدعم فعل ذلك، وستعمل 755 بلا أي مشكلة.

ما الفرق بين تعديل ملفات القالب وتعديل ملفات النواة؟

الاثنان يضيعان عند التحديث، لكن الفرق في الحلّ. تعديل ملفات النواة (wp-admin وwp-includes) لا مبرّر له إطلاقًا: البديل الصحيح دائمًا هو خطّاف أو فلتر داخل إضافة صغيرة. أمّا تعديل ملفات القالب فهو حاجة مشروعة جدًّا، والحلّ الصحيح هو القالب الابن الذي يرث كل شيء من القالب الأب ويحتفظ بتعديلاتك في مجلّد منفصل لا يمسّه التحديث. القاعدة العامة: تخصيص الشكل يذهب للقالب الابن، وتخصيص الوظائف يذهب لإضافة خاصّة بك.

ملف debug.log ظهر في wp-content — هل أحذفه؟

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

كيف أعرف أن ملفًّا في موقعي مشبوه أو خبيث؟

أربعة مؤشّرات مجتمعة أقوى من أي واحد منفردًا: تاريخ تعديل حديث لملف لم تلمسه؛ ملف PHP في مكان لا يليق به مثل wp-content/uploads أو مجلّدات السنوات؛ اسم عشوائي أو يقلّد أسماء النواة مثل wp-cache-x1.php في الجذر؛ ومحتوى مضغوط أو مشفّر يبدأ بدوال مثل eval وbase64_decode. رتّب الملفات حسب تاريخ التعديل واستعرض أحدثها أولًا. وعند تأكّد الشكّ لا تكتفِ بحذف الملف — فالأبواب الخلفية تأتي عادةً في مجموعات، والحلّ الكامل مشروح في دليل اكتشاف البرمجيات الخبيثة وإزالتها.

هل أستطيع نقل مجلّد wp-content إلى مكان آخر؟

نعم تقنيًّا. ووردبريس يدعم ثوابت في wp-config.php تسمح بتغيير مسار wp-content ورابطه، وبعض إعدادات الأمان المتقدّمة تستفيد من ذلك. لكن الإجابة العملية لأغلب المواقع هي: لا تفعل. كثير من الإضافات والقوالب تفترض المسار الافتراضي وتكتبه مباشرة في شيفرتها، والنتيجة روابط صور مكسورة وملفات أنماط لا تُحمَّل ومشاكل يصعب تتبّعها. الفائدة الأمنية من النقل هامشية مقارنةً بإجراءات أساسية مثل تحديث كل شيء بانتظام ومنع تنفيذ PHP داخل uploads وتقييد الوصول إلى لوحة التحكّم.

المصادر

• توثيق ووردبريس — تحرير wp-config.php
• ووردبريس — تقوية أمان التثبيت