أمان هيكل مجلدات ووردبريس: كيفية إغلاق الوصول إلى مجلد "wp-includes"

أمان هيكل مجلدات ووردبريس يتطلب إغلاق الوصول المباشر إلى مجلد "wp-includes" بطرق آمنة، وذلك عن طريق منع تنفيذ ملفات PHP الموجودة داخل هذا المجلد وإيقاف عرض المحتويات بدلاً من حظر الوصول إلى المجلد بالكامل. حيث يحتوي wp-includes على ملفات JavaScript وCSS وملفات ثابتة أخرى ضرورية لتشغيل نواة ووردبريس؛ وبالتالي، فإن حظر الوصول الكامل قد يؤثر سلبًا على تصميم الموقع أو وظيفة المحرر أو الإضافات. النهج الصحيح هو، إذا كنت تستخدم Apache، فرض قواعد .htaccess، وإذا كنت تستخدم Nginx، فرض قاعدة الموقع داخل كتلة الملقم لمنع الوصول المباشر إلى PHP، ثم التحقق من الموقع باستخدام استجابات 403/404 واختبار الصفحات الحرجة.

أحد الأخطاء الأكثر شيوعًا في أمان ووردبريس هو الاكتفاء بكلمة مرور قوية أو إضافة أمان واحدة فقط. حيث يقوم المهاجمون غالبًا بفحص المجلدات التي تحتوي على الملفات الأساسية، والإضافات القديمة، وأذونات الملفات غير الصحيحة، وقوائم المجلدات المفتوحة. يعد مجلد wp-includes أيضًا من الأهداف في هذه الفحوصات. في هذه الإرشادات، ستتعلم كيفية تقييد الوصول إلى wp-includes بخطوات قابلة للتطبيق في بيئات الاستضافة الحقيقية، وما هي القواعد التي قد تعطل الموقع، وأمثلة على التكوينات لكل من Apache وNginx، وطرق الاختبار وقائمة فحص الصيانة. يمكنك أيضًا النظر في خيارات استضافة WordPress لتشغيل موقع ووردبريس في بيئة أكثر أمانًا، وشهادة SSL كطبقة حماية عامة.

ما هو مجلد wp-includes ولماذا يجب حمايته؟

wp-includes هو أحد المجلدات الرئيسية التي تحتوي على المكتبات الأساسية لنواة ووردبريس. يتضمن نظام القوالب، ومكونات محرر الكتل، وREST API، ومعالجة الوسائط، والفئات، والوظائف، وملفات JavaScript المختلفة. بعبارة بسيطة، يعتبر wp-includes أحد غرف المحرك في ووردبريس؛ ليس مجال محتوى يجب على المستخدمين زيارته بشكل مباشر.

لا يحتاج الزائر العادي إلى فتح عنوان مثل site.com/wp-includes/. ومع ذلك، يمكن أن تظهر بعض الكيانات الثابتة تحت wp-includes في شفرة المصدر للصفحة. على سبيل المثال، يمكن تحميل ملفات السكريبت الافتراضية لووردبريس أو سكريبتات الرموز التعبيرية أو مكونات المحرر من هذا المجلد. ولذلك، يجب تحديد الهدف بشكل صحيح عند اتخاذ تدابير أمنية: إغلاق الوصول المباشر إلى ملفات PHP دون التأثير على تشغيل الملفات الثابتة.

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

ماذا يحقق إغلاق الوصول إلى wp-includes؟

إن منع تنفيذ PHP مباشرة من مجلد wp-includes لن يوقف جميع الهجمات بمفرده؛ ولكنه يقلل بشكل كبير من سطح الهجوم. خاصة في المواقع المصابة بالبرمجيات الخبيثة، يحاول المهاجمون تحميل ملفات PHP ضارة إلى المجلدات المتاحة أو استدعاء الملفات الموجودة. يمنع حظر تنفيذ ملفات PHP تحت wp-includes من الويب، مما يوفر حاجزًا إضافيًا في هذا السيناريو.

تقدم هذه التدابير الفوائد التالية:

• تقييد استدعاء ملفات PHP الأساسية عبر URL مباشرة.
• يمنع ظهور محتويات المجلد إذا كانت قائمة المجلدات مفتوحة.
• يقلل من تسرب المعلومات غير الضرورية ضد عمليات الفحص الآلية.
• يوفر حماية على مستوى خادم الويب حتى بدون إضافة أمان.
• يقوي الأمان متعدد الطبقات بالتزامن مع WAF، وSSL، وPHP المحدث، وأذونات الملفات.

النقطة المهمة هنا هي أن هذه العملية تعتبر طبقة أمان. إذا كانت لديك إضافة غير محدثة، أو كلمة مرور مسؤول ضعيفة، أو حساب FTP مخترق، فإن قاعدة wp-includes وحدها لن تكون كافية. الأمن هو مزيج من بنية الاستضافة، والتطبيق، وإدارة المستخدم، والصيانة المنتظمة. يمكن الإشارة إلى استضافة الويب الآمنة كأساس آمن، وأمان النطاق كحماية إضافية في إدارة النطاق.

الأخطاء الأكثر شيوعًا عند إغلاق wp-includes

إغلاق المجلد بالكامل

أحد الأخطاء الأكثر شيوعًا هو حظر جميع طلبات HTTP إلى مجلد wp-includes برمز 403. قد تبدو هذه الطريقة منطقية في البداية؛ ولكن نظرًا لأن ووردبريس يقوم بتحميل بعض الكيانات الثابتة من هذا المجلد، فقد تسبب في مشاكل غير متوقعة. على سبيل المثال، قد لا يفتح محرر الكتل، أو قد لا يتم تحميل بعض ملفات JavaScript، أو قد تظهر تشوهات تصميم صغيرة ولكنها حرجة في الواجهة.

تطبيق القاعدة دون اختبارها

حتى خطأ واحد في تكوين .htaccess أو Nginx يمكن أن يؤدي إلى حدوث خطأ 500 Internal Server Error. يكون تطبيق القاعدة مباشرة على المواقع التي تتلقى حركة مرور كثيفة خطرًا بشكل خاص. يجب أولاً أخذ نسخة احتياطية من الملف، وإذا أمكن، تجربته في بيئة staging، ثم الانتقال إلى الإنتاج بشكل منظم. إذا كانت خيارات الاستضافة في Hostragons تتضمن staging أو النسخ الاحتياطي، فيمكن إضافة نسخ احتياطي لاستضافة الويب كارتباط داخلي طبيعي.

الاعتماد الكامل على إضافة الأمان

الإضافات الأمنية مفيدة؛ ولكن القواعد على مستوى خادم الويب تدخل حيز التنفيذ في مراحل أبكر. إذا تم حظر الطلب من قبل Apache أو Nginx قبل الوصول إلى PHP، فإن استهلاك الموارد يقل أيضًا. لذلك، يجب عدم تجاهل قواعد الخادم الأساسية حتى عند استخدام الإضافات.

قائمة التحقق قبل التطبيق

إجراء بعض التحضيرات قبل تقييد الوصول إلى wp-includes يمكن أن يقلل من خطر الانقطاع بشكل كبير. يُنصح بقائمة التحقق التالية، خاصة في مواقع ووردبريس الحية:

• احصل على نسخة احتياطية من تكوين .htaccess أو Nginx الحالي.
• قم بتحديث نواة ووردبريس، والقوالب، والإضافات.
• تأكد من أن إصدار PHP الخاص بك هو إصدار مدعوم وآمن.
• تحقق من أذونات الملفات: يجب أن تكون المجلدات عادةً 755، والملفات 644.
• لا تترك أذونات الكتابة مفتوحة بشكل غير ضروري للملفات الحرجة مثل wp-config.php و.htaccess.
• إذا كنت تستخدم الإضافة للتخزين المؤقت، أو CDN، أو إضافة أمان، خطط لتنظيف الكاش بعد التعديل.
• قم بإعداد قائمة لاختبار المناطق الحرجة مثل لوحة الإدارة، الصفحة الرئيسية، صفحة المقالات، نموذج الاتصال، وصفحة الدفع.

تستغرق هذه التحضيرات حوالي 10-15 دقيقة؛ ولكنها تمنع الانقطاع الذي قد يستغرق ساعات بسبب قاعدة خاطئة. من الأكثر أمانًا إجراء التغييرات في أوقات المرور المنخفضة على المواقع المؤسسية.

إغلاق وصول PHP إلى wp-includes باستخدام .htaccess على خادم Apache

الطريقة الأكثر شيوعًا في استضافات Apache المشتركة هي استخدام ملف .htaccess. يمكن أن تمنع القواعد الصحيحة المضافة إلى ملف .htaccess الموجود في الدليل الرئيسي لووردبريس استدعاءات PHP معينة داخل wp-includes. قبل البدء، قم بتنزيل نسخة من الملف إلى جهاز الكمبيوتر الخاص بك أو قم بإنشاء نسخة احتياطية عبر مدير الملفات في لوحة التحكم الخاصة بالاستضافة.

قاعدة .htaccess المقترحة

تتركز المقاربة التالية على منع الوصول المباشر إلى PHP تحت wp-includes مع الحفاظ على تشغيل الملفات الثابتة:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-includes/.*[.]php$ - [F,L]
</IfModule>

فكرة هذه القاعدة بسيطة: إذا بدأ عنوان URL بـ wp-includes وانتهى بـ .php، يتم حظر الطلب. وبهذه الطريقة، لا يمكن استدعاء ملفات PHP داخل wp-includes من المتصفح. بينما تستمر الوصول إلى الملفات الثابتة مثل .js و.css و.png و.svg. هذه هي التوازن الأكثر أمانًا لواجهة ووردبريس ولوحة الإدارة.

إيقاف عرض قائمة المجلدات

إعداد حرج آخر هو إيقاف عرض قائمة المجلدات. إذا كانت قائمة المجلدات مفتوحة على الخادم، يمكن للمستخدمين رؤية محتوى بعض المجلدات. عادةً ما يكون إضافة السطر التالي إلى ملف .htaccess الرئيسي كافيًا:

Options -Indexes

هذا السطر يمنع ظهور قائمة الملفات في المجلدات التي لا تحتوي على ملف index. في معظم استضافات الويب الحديثة، تكون مغلقة بشكل افتراضي؛ ولكن من الجيد التحقق من ذلك كأفضل ممارسة أمنية.

الاختبار بعد التعديل

بعد إضافة القاعدة، قم بإجراء الاختبارات التالية:

• افتح siteadresiniz.com/wp-includes/؛ يجب ألا تظهر قائمة المجلدات.
• حاول استدعاء ملف PHP معروف تحت wp-includes مباشرة؛ يجب أن تحصل على 403 أو 404.
• تحقق من الصفحة الرئيسية، ومقال المدونة، ولوحة الإدارة.
• تحقق من وجود أخطاء 404/403 في قسم Console وNetwork في أدوات مطور المتصفح.
• إذا كنت تستخدم إضافة التخزين المؤقت أو CDN، قم بتنظيف الكاش.

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

إغلاق وصول PHP إلى wp-includes على خادم Nginx

في بيئات خوادم VPS أو الخوادم المخصصة أو المُدارة التي تستخدم Nginx، لا يعمل .htaccess. يجب إضافة القاعدة إلى ملف تكوين موقع Nginx، عادةً داخل كتلة الخادم. يتطلب هذا الوصول عبر SSH وإذن تعديل ملفات التكوين. إذا لم تكن متأكدًا، فمن الأفضل طلب المساعدة من فريق دعم الاستضافة.

قاعدة الموقع المقترحة لـ Nginx

يمكن تطبيق القاعدة الأساسية على النحو التالي:

location ~* ^/wp-includes/.*[.]php$ {
deny all;
}

هذه القاعدة تمنع الطلبات الواردة إلى ملفات PHP تحت wp-includes. من المهم اختبار التكوين بعد التعديل:

nginx -t

إذا كانت الاختبارات ناجحة، يتم إعادة تحميل Nginx:

systemctl reload nginx

يكون أمر reload هنا أكثر تحكمًا من أمر restart؛ حيث يتم تجديد التكوين دون قطع الاتصال بالكامل. ومع ذلك، يُنصح بتنفيذ التغييرات على المواقع الحرجة في أوقات مرور منخفضة.

نقاط يجب مراعاتها عند استخدام Nginx

• تأكد من أنك أضفت القاعدة إلى كتلة الخادم الصحيحة؛ قد يكون هناك عدة مواقع على نفس الخادم.
• إذا كنت تستخدم CDN أو proxy عكسي، قم بإجراء الاختبارات الحقيقية بعد تنظيف الكاش الخاص بـ CDN.
• تحقق من أن تكوين PHP-FPM يعالج الملفات اللازمة فقط.
• تحقق من ملفات السجل: تعرض access.log وerror.log القواعد الخاطئة بسرعة.

يمكن أن يؤدي ترتيب الموقع الخاطئ في بيئة Nginx إلى نتائج غير متوقعة. لذلك، تأكد من أن القاعدة لا تتعارض مع روابط permalink الخاصة بووردبريس وكتل معالجة PHP.

مقارنة الطرق

تلخص الجدول التالي الأساليب الرئيسية المستخدمة لتقييد الوصول إلى wp-includes:

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

أذونات الملفات وإعدادات الملكية

إغلاق الوصول إلى wp-includes سيكون غير فعال إذا كانت أذونات الملفات غير صحيحة. الأذونات المقبولة عمومًا في ووردبريس هي 755 للمجلدات و644 للملفات. تسمح هذه القيم لخادم الويب بقراءة الملفات مع تقليل أذونات الكتابة غير الضرورية. قد تكون هناك إعدادات مختلفة للمستخدمين والمجموعات في بعض بيئات الاستضافة، لذا يجب أن تأخذ في اعتبارك توصيات لوحة التحكم الخاصة بك.

تعتبر أذونات 777 خطرًا كبيرًا على الأمان. السماح للجميع بالكتابة إلى مجلد يمكن أن يسهل سيناريوهات تحميل الملفات الضارة. حتى في المجلدات التي يجب أن تكون قابلة للكتابة مثل wp-content/uploads، يجب منع تنفيذ PHP. بينما يجب أن يكون wp-includes في الظروف العادية غير قابل للكتابة من قبل المستخدمين باستثناء تحديثات ووردبريس.

يمكن التحقق من القيم التالية في تدقيق الأمان:

• مجلد wp-includes: عادةً 755
• ملفات PHP داخل wp-includes: عادةً 644
• wp-config.php: إذا أمكن، 600 أو أذونات أكثر تقييدًا تتناسب مع بنية الاستضافة
• .htaccess: عادةً 644، بدون أذونات كتابة غير ضرورية بعد التعديل

قد لا تتصرف هذه الإعدادات بنفس الطريقة على كل خادم. يمكن أن تؤدي الأذونات الخاطئة إلى عدم قدرة الموقع على التحديث أو قراءة الملفات. يجب مراجعة الصحة والتحقق من سجلات الأخطاء بعد التعديلات.

هل تقوم إضافات الأمان بهذا الإجراء؟

يمكن أن تقترح إضافات الأمان مثل Wordfence وiThemes Security بعض قواعد التقوية تلقائيًا. تكون هذه الإضافات مفيدة في حماية هجمات القوة الغاشمة، ومراقبة تغييرات الملفات، وفحص البرمجيات الخبيثة، وأمان الدخول. ومع ذلك، يجب التحقق مما تقوم به الإضافة فيما يتعلق بإغلاق الوصول إلى wp-includes.

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

إذا كنت تستخدم إضافة أمان، تحقق من الأمور التالية:

• تحقق مما إذا كانت الإضافة تضيف قاعدة إلى .htaccess أو Nginx.
• تأكد من عدم وجود تعارض بين قاعدتين تؤديان نفس الوظيفة.
• تحقق من عدم تغيير إعدادات الأمان بعد تحديث الإضافة.
• راقب تأثير الأداء من خلال تتبع استخدام موارد الكاش والخادم.

غالبًا ما يكون استخدام عدة إضافات أمان في نفس الوقت فكرة غير جيدة. يمكن أن تؤدي القواعد المتعارضة لجدران الحماية، وتسجيل الدخول، وإعادة الكتابة إلى انخفاض الأداء أو حظر غير صحيح.

اختبار حماية wp-includes: سيناريو عملي

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

• 1. افتح الصفحة الرئيسية في علامة تبويب خفية وتحقق مما إذا كان هناك أي تشوه بصري.
• 2. قم بزيارة مقال مدونة، وصفحة فئة، وصفحة نتائج بحث.
• 3. قم بتسجيل الدخول إلى لوحة wp-admin؛ افتح محرر الكتل ومكتبة الوسائط.
• 4. تحقق من قسم Console في أدوات مطور المتصفح.
• 5. تحقق من عدم حظر الملفات الثابتة تحت wp-includes بشكل غير ضروري في قسم Network.
• 6. حاول استدعاء ملف PHP مباشرة تحت wp-includes؛ يجب أن تتوقع رد 403 أو 404.
• 7. تحقق من سجلات أخطاء الخادم للبحث عن أخطاء جديدة ومتكررة.

يستغرق هذا الاختبار حوالي 5 دقائق ويكشف عن أي تكوينات خاطئة بسرعة. يجب أيضًا اختبار صفحات السلة والدفع وحسابات المستخدمين في المواقع التي لديها عمليات دفع مثل WooCommerce. يمكن حتى أن تؤثر عرقلة صغيرة لجافا سكريبت على معدل التحويل في المواقع التي تحقق إيرادات مباشرة.

تدابير إضافية لأمان هيكل مجلدات ووردبريس

تعتبر حماية wp-includes بداية جيدة؛ ولكن يجب التفكير في أمان ووردبريس بشكل شامل. تساعد التدابير الإضافية التالية على تقليل سطح الهجوم أكثر:

• حافظ على نواة ووردبريس محدثة بدلاً من محاولة إخفاء إصدار ووردبريس.
• احذف القوالب والإضافات غير المستخدمة تمامًا.
• اجعل اسم المستخدم الإداري صعب التخمين.
• استخدم المصادقة الثنائية.
• إذا كنت لا تستخدم XML-RPC، فقم بتقييد الوصول إليه.
• طبق حد معدل أو تحقق إضافي على wp-login.php.
• قم بإجراء النسخ الاحتياطي الآلي واختبار استعادة النسخ الاحتياطية.
• استخدم HTTPS في جميع أنحاء الموقع؛ فإن بيانات تسجيل الدخول والمعلومات بدون SSL تكون في خطر.

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

متى يجب أن تطلب دعمًا محترفًا؟

إضافة قاعدة .htaccess في استضافة Apache بسيطة وقابلة للإدارة لمعظم المستخدمين. ومع ذلك، إذا كنت تتعامل مع تكوين Nginx مخصص، أو شبكة مواقع متعددة، أو متجر WooCommerce، أو مواقع الأخبار ذات الحركة العالية، أو بوابة مؤسسية، فإن الحصول على دعم محترف قد يكون الخيار الأفضل. لأن القاعدة الأمنية يجب أن تكون صحيحة تقنيًا وأمنة من حيث استمرارية العمل.

يُنصح بطلب المساعدة من الخبراء في الحالات التالية:

• إذا كنت تستضيف عدة مواقع ووردبريس على الخادم.
• إذا كنت تستخدم Nginx وVarnish وCDN وWAF معًا.
• إذا زادت أخطاء 403 أو 404 أو 500 بعد التغييرات الأخيرة.
• إذا كانت الموقع قد تعرض سابقًا للإصابة بالبرمجيات الخبيثة.
• إذا كنت تشغل نظامًا يتعامل مع المدفوعات أو العضويات أو البيانات الشخصية.

تعد بنية الاستضافة الآمنة، والعزل الصحيح، والنسخ الاحتياطي المنتظم، والدعم المحترف من الأجزاء غير المرئية ولكنها حاسمة في أمان ووردبريس. عند اختيار البنية التحتية، يجب ألا تقتصر على مساحة القرص فقط؛ بل يجب أيضًا مراعاة خيارات النسخ الاحتياطي، وجدار الحماية، ودعم إصدار PHP، وإدارة SSL، وجودة الدعم الفني. في هذا السياق، يمكن أن تكون محتويات باقات استضافة Hostragons ونقل موقع ووردبريس مفيدة للقارئ.

الخاتمة

الطريقة الصحيحة لإغلاق الوصول إلى مجلد wp-includes في إطار أمان هيكل مجلدات ووردبريس ليست من خلال حظر المجلد بالكامل، ولكن من خلال إغلاق الوصول المباشر إلى ملفات PHP داخل wp-includes وإيقاف عرض قائمة المجلدات. يمكن تنفيذ هذه العملية بسرعة باستخدام .htaccess لـ Apache، وقواعد الموقع لـ Nginx. ومع ذلك، يجب أخذ نسخة احتياطية قبل كل تغيير وإجراء اختبارات على لوحة الإدارة والواجهة بعد ذلك.

باختصار: لا تعطل الملفات الثابتة، قيد وصول PHP، أغلق عرض قائمة المجلدات، تحقق من أذونات الملفات، وقم بالتحديث بانتظام. يمكنك استكشاف حلول استضافة ووردبريس واسم النطاق وSSL من Hostragons؛ وطلب الدعم بشأن التكوين المناسب لاحتياجاتك.

أسئلة شائعة

هل من الآمن إغلاق مجلد wp-includes بالكامل؟

عادةً ما لا يُنصح بذلك. يحتوي wp-includes على ملفات JavaScript وCSS وملفات ثابتة يحتاجها ووردبريس. يمكن أن يؤدي الحظر الكامل إلى تعطيل مظهر الموقع أو لوحة الإدارة. النهج الأكثر أمانًا هو إغلاق الوصول المباشر إلى ملفات PHP في هذا المجلد.

ماذا أفعل إذا حصلت على خطأ 500 بعد إضافة قاعدة .htaccess؟

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

هل يعمل .htaccess على خادم Nginx؟

لا. يستخدم .htaccess في بيئات Apache وLiteSpeed. يتم تطبيق قيود مماثلة على خوادم Nginx باستخدام قواعد الموقع داخل كتلة الخادم ويجب اختبار التكوين بعد التغيير باستخدام nginx -t.

هل تجعل هذه العملية موقع ووردبريس الخاص بي آمنًا تمامًا؟

لا. إغلاق الوصول إلى wp-includes PHP هو طبقة أمان مهمة ولكنها غير كافية بمفردها. يجب تطبيق التحديثات، وكلمات المرور القوية، والمصادقة الثنائية، وSSL، والنسخ الاحتياطية، وجدار الحماية، وأذونات الملفات الصحيحة معًا.

إذا كنت أستخدم إضافة أمان، هل يجب أن أضيف أيضًا قاعدة wp-includes؟

يعتمد ذلك على ما تقوم به الإضافة. تضيف بعض الإضافات قاعدة إلى .htaccess، بينما توفر البعض الآخر حماية فقط على مستوى التطبيق. عادةً ما يكون تقييد الوصول إلى PHP على مستوى الخادم بدون تعارض هو الحل الأكثر قوة بشكل عام.