دليل wp-config.php في WordPress 2026: أهم الإعدادات والاستخدامات الآمنة

ملف wp-config.php هو ملف إعداد رئيسي في WordPress. يحتوي على بيانات الاتصال بقاعدة البيانات، مفاتيح المصادقة، Table Prefix، وعدد من Constants التي تغيّر سلوك WordPress قبل تحميل النظام بالكامل.

هذه الصفحة مخصصة لفهم ما الذي يمكن ضبطه داخل الملف ومتى يكون ذلك مناسبًا. إذا كان هدفك هو طريقة فتح الملف وحفظه بدون كسر الموقع، استخدم دليل تعديل wp-config.php بأمان.

المصدر الرسمي: WordPress Developer Handbook – wp-config.php.

ما هو wp-config.php؟

عند تثبيت WordPress، يتم إنشاء wp-config.php عادةً من الملف wp-config-sample.php أوتقوم أداة التثبيت بإنشائه تلقائيًا. الملف يعرّف القيم التي يحتاجها WordPress قبل الاتصال بقاعدة البيانات وتحميل الإعدادات من داخلها.

لا تعتبره مكانًا عامًا لإضافة أي كود PHP. الوظائف التي تنتمي إلى القالب مكانها القالب، والوظائف العامة القابلة للنقل مكانها Plugin أوCode Snippets مناسب.

بيانات الاتصال بقاعدة البيانات

أهم الثوابت الأساسية هي:

define( 'DB_NAME', 'database_name' );
define( 'DB_USER', 'database_user' );
define( 'DB_PASSWORD', 'database_password' );
define( 'DB_HOST', 'localhost' );

قد يختلف DB_HOST حسب الاستضافة؛ ليس دائمًا localhost. لا تغيّر هذه القيم إلا إذا تغيرت قاعدة البيانات أوالمستخدم أوالخادم فعليًا.

Charset وCollation

define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

لا تعدّل DB_COLLATE عشوائيًا على موقع قائم. تغيير Charset/Collation لموقع حي يحتاج تقييمًا لقاعدة البيانات نفسها وليس مجرد تعديل Constant.

Security Keys وSalts

WordPress تستخدم مجموعة مفاتيح للمصادقة وتوقيع Cookies. المجموعة الصحيحة تتضمن:

AUTH_KEY
SECURE_AUTH_KEY
LOGGED_IN_KEY
NONCE_KEY
AUTH_SALT
SECURE_AUTH_SALT
LOGGED_IN_SALT
NONCE_SALT

يمكن توليد قيم جديدة من WordPress Secret-Key Service.

تغيير هذه القيم يؤدي عادةً إلى تسجيل خروج الجلسات الحالية، لذلك هو إجراء مفيد عند الاشتباه في سرقة Sessions أوبعد Incident أمني، وليس تعديلًا يجب تنفيذه دوريًا بلا سبب.

Table Prefix

$table_prefix = 'wp_';

الـPrefix يحدد بادئة جداول WordPress. تغييره أثناء التثبيت سهل نسبيًا، لكن تغييره بعد تشغيل الموقع ليس مجرد تعديل هذا السطر؛ تحتاج إعادة تسمية الجداول ومراجعة قيم metadata/options التي قد تحتوي Prefix.

مهم: تغيير wp_ ليس طبقة أمان جوهرية ضد SQL Injection. الكود الآمن، تحديثات النظام، Least Privilege، Prepared Queries، والحماية على مستوى التطبيق والخادم أهم بكثير.

WP_DEBUG وDebug Log

للتشخيص على Staging:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

هذا يجعل WordPress تسجل رسائل Debug عادةً في wp-content/debug.log عند تفعيل التسجيل. لا تترك Logs تنمو بلا حدود، ولا تعرض الأخطاء للزوار على Production لأنها قد تكشف مسارات ومعلومات تقنية.

WP_ENVIRONMENT_TYPE

WordPress تدعم تعريف نوع البيئة:

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

القيم المعروفة تشمل local وdevelopment وstaging وproduction. هذا لا يحمي البيئة ولا يفعّل Noindex تلقائيًا؛ هو Context يمكن أن تستخدمه Core أوPlugins أوالكود المخصص لتغيير السلوك.

Memory Limits

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

هذه القيم تطلب من WordPress حدودًا للذاكرة، لكنها لا تستطيع تجاوز القيود التي يفرضها PHP أوالاستضافة. إذا كان memory_limit على الخادم أقل أوغير قابل للتغيير، تعديل wp-config.php لن يرفع الحد فعليًا.

لا تحل مشكلة تسريب ذاكرة أوPlugin سيئة فقط برفع Memory Limit باستمرار.

Revisions وAutosave

يمكنك تحديد عدد Revisions:

define( 'WP_POST_REVISIONS', 10 );

أوإيقافها بالكامل:

define( 'WP_POST_REVISIONS', false );

لكن إيقاف Revisions كليًا غالبًا ليس أفضل قرار للمواقع التحريرية. الأفضل تحديد حد منطقي إذا كان الحجم يمثل مشكلة.

كما يمكن تغيير Autosave interval:

define( 'AUTOSAVE_INTERVAL', 120 );

القيمة بالثواني.

سلة المهملات

define( 'EMPTY_TRASH_DAYS', 15 );

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

تعطيل محرر الملفات من لوحة الإدارة

define( 'DISALLOW_FILE_EDIT', true );

هذا يمنع تحرير Theme/Plugin files من محرر WordPress الداخلي، وهو إعداد دفاعي منطقي في كثير من مواقع Production.

أما:

define( 'DISALLOW_FILE_MODS', true );

فهو أقوى بكثير؛ يمنع تحديث/تثبيت Plugins/Themes من لوحة WordPress. لا تفعّله إلا إذا كان Deployment workflow لديك يدير الملفات خارجيًا.

WP_HOME وWP_SITEURL

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

تستطيع بهذه الثوابت فرض عناوين محددة حتى لو كانت القيم المخزنة في قاعدة البيانات مختلفة. مفيد في بعض حالات Migration أوRecovery، لكنه قد يخفي مشكلة إذا استخدمته بدون فهم الفرق بين Home URL وWordPress Address.

لا تستخدمه كعلاج دائم لكل Redirect loop. افحص HTTPS وProxy headers وServer redirects وDatabase values أيضًا.

Automatic Updates

يمكن التحكم في بعض سلوك التحديثات عبر Constants مثل:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

إيقاف Auto Updates بالكامل يرفع عبء الصيانة. لا تستخدمه إلا ضمن Deployment process واضح يضمن تنفيذ تحديثات الأمان في وقت مناسب.

Database Repair

define( 'WP_ALLOW_REPAIR', true );

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

ولا تعتبر Repair/Optimize حلًا عامًا لبطء قاعدة البيانات. استخدمه فقط عند وجود مشكلة مناسبة لهذه الأداة.

WP_CONTENT_DIR وWP_CONTENT_URL

يمكن تخصيص مسار مجلد المحتوى، لكن هذا تغيير معماري متقدم:

define( 'WP_CONTENT_DIR', '/absolute/path/content' );
define( 'WP_CONTENT_URL', 'https://example.com/content' );

تغيير المسار قد يؤثر في Plugins، Deployment، Cache، CDN، Backups وروابط الملفات. لا تستخدمه باعتباره “حيلة أمان”.

Proxy وHTTPS

في بعض البيئات خلف Reverse Proxy أوLoad Balancer قد تحتاج معالجة HTTPS على مستوى Server/proxy configuration. لا تنسخ أكواد $_SERVER عشوائيًا إلى wp-config.php بدون فهم بنية الشبكة، لأن إعدادًا خاطئًا قد يسبب Redirect loop.

WordPress Cron

يمكن تعطيل تشغيل WP-Cron عند Page Load:

define( 'DISABLE_WP_CRON', true );

لا تفعل ذلك إلا إذا أعددت System Cron أوScheduler بديلًا. وإلا ستتوقف المهام المجدولة مثل النشر المؤجل وبعض الإيميلات وWooCommerce tasks.

كيف تحمي wp-config.php؟

الحماية العملية تعتمد على:

• صلاحيات Filesystem صحيحة.
• عدم كشف الملف عبر Web server.
• عدم رفعه إلى Git repository عام.
• عدم إرسال محتواه كاملًا في Tickets أوScreenshots.
• حماية Hosting/SSH/SFTP credentials.

WordPress تستطيع أيضًا قراءة wp-config.php من مستوى واحد أعلى من جذر التثبيت في بعض البنى، لكن نقل الملف ليس بديلًا عن صلاحيات ونظام خادم مضبوط.

أين تضع Constants المخصصة؟

في المعتاد ضعها قبل:

/* That's all, stop editing! Happy publishing. */

ولا تكرر نفس Constant مرتين.

إعدادات لا أنصح بتغييرها بلا سبب

• Table Prefix على موقع حي.
• Content directory paths.
• Database charset/collation.
• Memory إلى أرقام ضخمة.
• إيقاف Updates بالكامل.
• إيقاف WP-Cron بدون بديل.
• تعريف URLs لتغطية مشكلة Redirect غير مفهومة.

Checklist قبل تعديل wp-config.php

• Backup للملف.
• وصول SFTP/File Manager للاسترداد.
• تعرف المصدر الرسمي للـConstant.
• تغيير واحد في كل مرة.
• Staging للتغييرات عالية المخاطر.
• عدم كشف Secrets.
• اختبار الموقع والـLogs بعد الحفظ.

الفرق بين هذا الدليل ودليل التعديل

هذه الصفحة مرجع ما الذي يفعله wp-config.php وما أهم Constants. أما خطوات فتح الملف، التعامل مع BOM وSmart Quotes وSyntax والاسترداد بعد خطأ، فهي في دليل تعديل wp-config.php بأمان.

الخلاصة

wp-config.php ملف إعداد حرج في WordPress، وليس مكانًا لإضافة أي كود عشوائي. استخدمه للثوابت التي يحتاجها WordPress مبكرًا: قاعدة البيانات، مفاتيح الأمان، Debug، Memory، Environment، Cron وبعض سياسات الملفات. أهم قاعدة: لا تغيّر إعدادًا لا تفهم تأثيره، وخذ Backup قبل أي تعديل.