ما هو ملف wp-config.php وكيف تعدّله بأمان؟

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

ما هو ملف wp-config.php ومن أين جاء؟

ووردبريس نظام مفتوح المصدر، ونسخة الملفات التي تنزّلها من الموقع الرسمي واحدة عند الجميع — لا تعرف قاعدة بياناتك ولا كلمة مرورها ولا اسم نطاقك. فكيف تصبح هذه النسخة العامة موقعك أنت؟ الجواب هو wp-config.php: الملف الوحيد الذي يفصل بين شيفرة ووردبريس العامّة وبين إعدادات تثبيتك الخاصّ. هو حلقة الوصل بين الشيفرة والبيانات، وبينه وبين قاعدة بياناتك تقوم الحياة كلّها.

في النسخة التي تنزّلها لن تجد ملفًا بهذا الاسم إطلاقًا. ستجد بدلًا منه ملفًا اسمه wp-config-sample.php — نموذج فيه كل الثوابت بقيم فارغة أو وهمية. عند تشغيل معالج تثبيت ووردبريس ومَلء شاشة بيانات قاعدة البيانات، يأخذ ووردبريس هذا النموذج، ويستبدل القيم ببياناتك، ويكتب الناتج في ملف جديد اسمه wp-config.php. أما مثبّتات لوحات التحكّم (مثل Softaculous وWordPress Toolkit) فتفعل الشيء نفسه آليًا خلف الكواليس. وإن فشلت الكتابة بسبب صلاحيات المجلّد، يعرض ووردبريس محتوى الملف على الشاشة ويطلب منك إنشاءه يدويًا ولصق المحتوى فيه.

متى يُقرأ هذا الملف بالضبط؟

فهم موضع الملف في دورة التحميل يشرح لك لماذا أخطاؤه قاتلة إلى هذا الحدّ. عند أي طلب — صفحة، أرشيف، طلب AJAX، حتى تسجيل دخول — يبدأ التنفيذ من index.php الذي يستدعي wp-blog-header.php، وهذا بدوره يستدعي wp-load.php، وأول ما يفعله wp-load.php هو البحث عن wp-config.php وتحميله. أي أن هذا الملف يُنفَّذ قبل أن يتّصل ووردبريس بقاعدة البيانات، وقبل أن تُحمَّل النواة، وقبل أن تعمل أي إضافة أو قالب، وقبل أن يُطبع أي حرف من الصفحة.

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

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

كل ما تراه في موقعك — المقالات، الصفحات، التعليقات، المستخدمون، الإعدادات، حتى الإضافات المفعّلة — محفوظ في قاعدة بيانات MySQL/MariaDB، لا في الملفات. الملفات هي المحرّك، وقاعدة البيانات هي المحتوى. وwp-config.php هو المفتاح الذي يفتح الباب بينهما. إن ضاعت بيانات هذا الملف أو تغيّرت كلمة مرور قاعدة البيانات دون تحديثه، لن يستطيع ووردبريس قراءة حرف واحد من محتواك، وستظهر لك الرسالة الشهيرة «تعذّر الاتصال بقاعدة البيانات». إدارة قاعدة البيانات نفسها — إنشاؤها، وإنشاء مستخدم لها، وتصدير نسخة منها — موضوع مستقلّ يشرحه دليل إدارة قواعد MySQL عبر phpMyAdmin.

أين يوجد الملف وكيف تفتحه؟

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

هناك موضع ثانٍ مقبول يجهله كثيرون: مجلّد واحد أعلى جذر التثبيت. ووردبريس مبرمَج بحيث إن لم يجد wp-config.php في الجذر، بحث عنه تلقائيًا في المجلّد الأب — بشرط ألّا يحتوي ذلك المجلّد الأب على تثبيت ووردبريس آخر. هذا يعني أنك تستطيع نقل الملف خطوة واحدة للخارج (إلى مستوى /home/user/ مثلًا بدل /home/user/public_html/) فيبقى الموقع يعمل، بينما يخرج الملف من المجلّد الذي يخدمه الخادم للويب.

طرق الوصول إلى الملف

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

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

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

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

تشريح الملف من أعلاه لأسفله

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

الملف يبدأ بوسم فتح PHP، ثم كتلة تعليق تشرح ما بداخله، ثم تأتي الطبقات بالترتيب: بيانات قاعدة البيانات، فبادئة الجداول، فمفاتيح الأمان، ثم مساحة الثوابت الحرّة، ثم الخط الفاصل، ثم سطران أخيران لا تلمسهما: تعريف الثابت ABSPATH الذي يحدّد المسار المطلق لمجلّد ووردبريس، ثم استدعاء wp-settings.php الذي يشغّل النظام كلّه. هذان السطران هما اللذان «يُقلعان» ووردبريس فعليًا، وأي ثابت تكتبه بعدهما يصل متأخّرًا جدًا — بعد أن تكون النواة قد قرأت الإعدادات وبنت قراراتها عليها — فلا يؤثّر شيئًا.

بيانات قاعدة البيانات: قلب الملف

هذه أوّل كتلة في الملف وأخطرها، وهي السبب الأول لرسالة «تعذّر الاتصال بقاعدة البيانات».

define( 'DB_NAME', 'user_wpdb' );
define( 'DB_USER', 'user_wpuser' );
define( 'DB_PASSWORD', 'ضع-كلمة-المرور-هنا' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

ثلاث ملاحظات عملية. الأولى: DB_HOST ليس localhost دائمًا. بعض المزوّدين يفصلون خادم قواعد البيانات عن خادم الويب فيعطونك عنوانًا مثل mysql.example.com، وبعضهم يستخدم منفذًا غير قياسي فيصبح العنوان 127.0.0.1:3307. لا تخمّن هذه القيمة أبدًا — انسخها من لوحة التحكّم أو من رسالة إنشاء قاعدة البيانات. الثانية: DB_CHARSET يجب أن يبقى utf8mb4 وليس utf8 القديم؛ الفرق أن utf8mb4 يدعم أربعة بايتات لكل محرف فيعرض الرموز التعبيرية وبعض المحارف العربية النادرة صحيحةً بدل علامات استفهام. الثالثة: كلمة المرور مكتوبة هنا بنصّ صريح غير مشفّر، وهذه حقيقة تقنية لا مفرّ منها — ووردبريس يحتاجها كما هي ليتّصل. لهذا تحديدًا يجب ألّا يخرج هذا الملف من خادمك أبدًا.

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

بادئة الجداول: $table_prefix

بعد كتلة قاعدة البيانات مباشرةً يأتي متغيّر — لا ثابت — اسمه $table_prefix:

$table_prefix = 'wp_';

معناه أن كل جدول في قاعدة البيانات يبدأ اسمه بهذه البادئة: wp_posts، wp_options، wp_users… إلخ. وفائدتها الأصلية تقنية بحتة: أن تستطيع تثبيت أكثر من موقع ووردبريس في قاعدة بيانات واحدة دون أن تتصادم جداولها، وذلك بإعطاء كل تثبيت بادئة مختلفة.

يشيع في المحتوى العربي أن تغيير البادئة من wp_ إلى شيء عشوائي «إجراء أمني مهم». الحقيقة أدقّ من ذلك: هو يعطّل بعض هجمات حقن SQL الآلية العمياء التي تفترض الأسماء الافتراضية، لكنه لا يوقف مهاجمًا يستطيع قراءة أسماء الجداول أصلًا، ولا يعوّض عن تحديث الإضافات. والأهم: تغيير البادئة على موقع يعمل عملية خطرة تتطلّب إعادة تسمية كل الجداول وتعديل قيم داخل wp_options وwp_usermeta معًا؛ خطأ واحد فيها يفقدك صلاحيات الإدارة. إن أردت بادئة مخصّصة فاخترها وقت التثبيت لا بعده.

ولا تخلط بين بادئتين مختلفتين تمامًا. بادئة الجداول ($table_prefix) شيء، وبادئة حساب الاستضافة شيء آخر. لوحات التحكّم تضيف تلقائيًا اسم حسابك كبادئة لأسماء قواعد البيانات ومستخدميها — فإن أنشأت قاعدة اسمها blog وحسابك wpress، يصبح الاسم الفعلي wpress_blog، ويجب أن تكتبه كاملًا في DB_NAME لا مختصرًا. نسيان هذه البادئة سبب متكرّر جدًا لفشل الاتصال بعد نقل موقع من خادم إلى آخر، ولا علاقة له بـ$table_prefix من قريب ولا بعيد.

مفاتيح الأمان (salts): ثمانية ثوابت لا تُهمَل

الكتلة الثالثة في الملف هي ثمانية ثوابت بقيم طويلة عشوائية:

define( 'AUTH_KEY',         'قيمة عشوائية طويلة' );
define( 'SECURE_AUTH_KEY',  'قيمة عشوائية طويلة' );
define( 'LOGGED_IN_KEY',    'قيمة عشوائية طويلة' );
define( 'NONCE_KEY',        'قيمة عشوائية طويلة' );
define( 'AUTH_SALT',        'قيمة عشوائية طويلة' );
define( 'SECURE_AUTH_SALT', 'قيمة عشوائية طويلة' );
define( 'LOGGED_IN_SALT',   'قيمة عشوائية طويلة' );
define( 'NONCE_SALT',       'قيمة عشوائية طويلة' );

وظيفتها ليست تشفير كلمات المرور — كلمات المرور محفوظة مجزّأة (hashed) في قاعدة البيانات. وظيفتها توقيع وتعمية ملفّات الكوكيز ورموز التحقّق (nonces) التي يستخدمها ووردبريس ليعرف أنك أنت. الكوكي الذي يبقيك مسجّل الدخول موقَّع بهذه المفاتيح؛ ومن دونها يصبح تزوير جلسة إدارية أسهل بكثير. لهذا لا يجوز أبدًا ترك القيم الافتراضية put your unique phrase here كما هي، ولا نسخ مفاتيح موقع إلى موقع آخر.

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

ثوابت التطوير والتشخيص

هذه الكتلة لا توجد في الملف افتراضيًا (باستثناء WP_DEBUG بقيمة false)، وأنت من يضيفها عند الحاجة.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

هذه التركيبة الرباعية هي الصيغة الوحيدة الآمنة على موقع حيّ: شغّل التشخيص، اكتبه في سجلّ، ولا تعرضه على الشاشة. النتيجة ملفّ نصّي في wp-content/debug.log يسجّل كل خطأ وتحذير وإشعار إهمال مع وقته، تفتحه وتقرأه على مهل بدل مطاردة الأعراض. أمّا WP_DEBUG_DISPLAY بقيمة true فيطبع الأخطاء في وجه الزوّار مباشرةً — وهي تكشف مسارات الملفات على الخادم وأسماء الدوال وأحيانًا أجزاء من الاستعلامات، أي أنها تسريب معلومات يفيد المهاجم.

للتحكّم في مكان السجلّ اكتب مسارًا بدل true، وهذا هو الخيار الأفضل أمنيًا:

define( 'WP_DEBUG_LOG', '/home/user/logs/wp-errors.log' );

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

ثوابت الأمان العملية

هنا تكمن أكبر قيمة يضيفها هذا الملف لموقعك، بثلاثة أسطر لا أكثر:

define( 'DISALLOW_FILE_EDIT', true );
define( 'FORCE_SSL_ADMIN', true );
define( 'DISALLOW_FILE_MODS', true );

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

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

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
	$_SERVER['HTTPS'] = 'on';
}

ثوابت الأداء والمحتوى

هذه الكتلة تعالج مشكلتين شائعتين: نفاد الذاكرة، وتضخّم قاعدة البيانات.

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
define( 'WP_POST_REVISIONS', 5 );
define( 'AUTOSAVE_INTERVAL', 300 );
define( 'EMPTY_TRASH_DAYS', 7 );
define( 'WP_CACHE', true );

WP_MEMORY_LIMIT هو أكثر ثابت يُساء فهمه في القائمة. هو لا يزيد ذاكرة خادمك، بل يطلب من PHP رفع السقف المسموح — وإن كان مزوّد الاستضافة قد ثبّت حدًّا أدنى منه على مستوى الخادم، فطلبك يُتجاهل ببساطة. أي أن كتابة 1024M هنا على خطّة مشتركة محدودة لن تفعل شيئًا سوى إعطائك شعورًا زائفًا بالأمان. القيمة العملية في معظم الحالات بين 256M و512M؛ وإن ظلّ الخطأ يتكرّر فالمشكلة إمّا إضافة تلتهم الذاكرة، وإمّا أن خطّتك بلغت سقف مواردها فعلًا وحان وقت الترقية.

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

أمّا WP_CACHE فلا تضعه يدويًا إن كنت تستخدم إضافة كاش. إضافات الكاش تضيف هذا الثابت بنفسها عند التفعيل وتحذفه عند التعطيل، ومعه ملفّ advanced-cache.php داخل wp-content؛ وتعريفه يدويًا دون وجود ذلك الملف قد ينتج تحذيرًا أو سلوكًا غريبًا. اترك المهمّة لإضافة الكاش التي تختارها، ولا تضف السطر إلا إن طلب منك مزوّدك ذلك صراحةً.

عناوين الموقع: WP_HOME و WP_SITEURL

هذان الثابتان يستحقّان قسمًا مستقلًا لأنهما ينقذان مواقع ويكسران مواقع بالقدر نفسه:

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

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

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

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

تعطيل wp-cron الداخلي

ووردبريس يشغّل مهامّه المجدولة — نشر المقالات المؤجّلة، النسخ الاحتياطي، فحوص التحديثات — عبر آلية داخلية اسمها wp-cron. المشكلة أن هذه الآلية تعتمد على الزيارات: لا تعمل إلا حين يفتح أحدهم صفحة في موقعك. النتيجة عيبان متضادّان: موقع بلا زوّار تتأخّر مهامّه أو لا تعمل أصلًا، وموقع بزيارات كثيفة يستدعي wp-cron.php آلاف المرّات في الساعة فيستهلك موارده بلا داعٍ.

الحلّ المعتاد سطر واحد:

define( 'DISABLE_WP_CRON', true );

الأمر الذي ستضعه في المهمّة المجدولة يشبه هذا:

wget -q -O - "https://example.com/wp-cron.php?doing_wp_cron" >/dev/null 2>&1

كيف تعدّل الملف بأمان؟

هذه الخطوات ليست زينة — كل واحدة منها منعت عطلًا حقيقيًا عند أحدهم من قبل:

1. خذ نسخة من الملف أولًا. انسخه باسم wp-config-backup-2026-07-30.php واحفظه خارج المجلّد المخدوم للويب أو نزّله إلى جهازك. ونسخة احتياطية كاملة للموقع أفضل، وفق دليل النسخ الاحتياطي لووردبريس.
2. استخدم محرّر نصوص عادي. محرّر الشيفرة في لوحة التحكّم، أو Notepad++ أو VS Code على جهازك. لا تستخدم Word ولا أي محرّر منسّق: هذه البرامج تضيف تنسيقًا خفيًّا وتحوّل علامات الاقتباس المستقيمة إلى مائلة فتكسر الشيفرة.
3. اكتب فوق الخط الفاصل. كل define جديد يوضع قبل سطر /* That's all, stop editing! ... */.
4. غيّر شيئًا واحدًا في كل مرّة. أضف ثابتًا، احفظ، حدّث الموقع، تأكّد أنه يعمل، ثم انتقل للتالي. إن أضفت خمسة ثوابت دفعةً واحدة وسقط الموقع، لن تعرف أيّها السبب.
5. احفظ الترميز UTF-8 بلا BOM. علامة الـBOM بايتات غير مرئية في بداية الملف تسبّب خطأ الترويسات — وأغلب المحرّرات تتيح اختيار «UTF-8 without BOM» عند الحفظ.
6. لا تترك سطرًا فارغًا في الأعلى أو الأسفل. الملف يبدأ بوسم فتح PHP في السطر الأول تمامًا، والأفضل ألّا يحتوي وسم إغلاق في نهايته أصلًا.

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

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

قاعدة الحماية في ملف .htaccess — على خوادم أباتشي وLiteSpeed — تكون هكذا:

<Files wp-config.php>
	Require all denied
</Files>

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

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

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

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

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

استكشاف الأخطاء بعد تعديل الملف

شاشة بيضاء بعد الحفظ مباشرةً

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

«تعذّر الاتصال بقاعدة البيانات»

هذه الرسالة تعني أن الملف نُفِّذ بنجاح لكن بياناته لم توصل إلى قاعدة البيانات. الترتيب المنطقي للفحص: تأكّد أولًا أن DB_NAME مكتوب بالبادئة كاملة (wpress_blog لا blog)، ثم أن DB_USER هو المستخدم الصحيح وأنه مُسنَد فعلًا إلى تلك القاعدة بصلاحيات كاملة — وهي خطوة ينساها الجميع بعد إنشاء مستخدم جديد. بعدها جرّب تغيير كلمة المرور من لوحة التحكّم إلى واحدة بسيطة مؤقّتًا وحدّثها في الملف؛ إن عمل الموقع فالمشكلة كانت في كلمة المرور أو في محرف خاص فيها. وأخيرًا DB_HOST: إن كنت واثقًا من الثلاثة الأولى فجرّب 127.0.0.1 بدل localhost أو راجع مزوّدك. كل هذه الفحوص تجريها بأمان من phpMyAdmin دون لمس بياناتك.

headers already sent

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

خروج كل المستخدمين فجأة

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

قائمة تحقّق سريعة قبل أن تغلق الملف

قبل أن تحفظ وتغلق، مرّ على هذه النقاط الستّ: هل أخذت نسخة احتياطية؟ هل كل ثوابتك الجديدة فوق الخط الفاصل؟ هل قيم قاعدة البيانات الأربع مطابقة تمامًا لما في لوحة التحكّم؟ هل مفاتيح الأمان الثمانية موجودة وليست القيم الافتراضية؟ هل WP_DEBUG_DISPLAY مضبوط على false إن كان التشخيص مفعّلًا؟ هل صلاحيات الملف 600 أو 640؟ إن أجبت بنعم على الستّة، فأنت في وضع أفضل من الأغلبية الساحقة من مواقع ووردبريس العربية.

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

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

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

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

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

أين أجد ملف wp-config.php بالضبط؟

في جذر تثبيت ووردبريس، أي المجلّد نفسه الذي يحتوي wp-admin وwp-includes وwp-content — وهو غالبًا public_html في الاستضافة المشتركة. إن ثبّت ووردبريس في مجلّد فرعي فالمسار يصبح مثل public_html/blog/wp-config.php. وقد يكون في مجلّد واحد أعلى الجذر لأن ووردبريس يبحث هناك تلقائيًا إن لم يجده في مكانه المعتاد. تصل إليه عبر مدير الملفات في لوحة التحكّم أو عبر FTP، ولن تجده داخل لوحة ووردبريس لأن محرّرها لا يعرض ملفات الجذر إطلاقًا.

ماذا لو حذفت الملف بالخطأ؟

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

هل تغيير مفاتيح الأمان يحذف بياناتي؟

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

لماذا لا يعمل الثابت الذي أضفته؟

راجع ثلاثة أشياء بالترتيب. الأول وأشيعها: أن يكون السطر مكتوبًا تحت /* That's all, stop editing! */ بدل فوقه — فما بعد ذلك السطر لا يُقرأ كإعداد. الثاني: خطأ في اسم الثابت أو صيغته، فالأسماء حسّاسة لحالة الأحرف وتُكتب كلها بحروف كبيرة، والقيم المنطقية true وfalse تُكتب بلا علامات اقتباس بينما النصّية مثل '256M' تُكتب بها. الثالث: أن يكون الثابت معرّفًا مرّتين في الملف — التعريف الأول يفوز دائمًا والثاني يُتجاهل مع تحذير.

هل أنقل الملف خارج مجلّد public_html فعلًا؟

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

ما الفرق بين WP_DEBUG و WP_DEBUG_LOG و WP_DEBUG_DISPLAY؟

WP_DEBUG هو المفتاح الرئيسي الذي يفعّل وضع التشخيص كلّه، وبدونه لا يعمل الثابتان الآخران. WP_DEBUG_LOG يحدّد أين تُكتب الأخطاء: بقيمة true تُكتب في wp-content/debug.log، ويمكنك إعطاؤه مسارًا خاصًّا خارج المجلّد المخدوم للويب وهو الأأمن. WP_DEBUG_DISPLAY يحدّد هل تُطبع الأخطاء على الشاشة أمام الزوّار. على موقع حيّ: الأول true، والثاني true أو مسار، والثالث false دائمًا — لأن عرض الأخطاء يكشف مسارات خادمك للمهاجمين.

هل يكفي DISABLE_WP_CRON لتحسين أداء موقعي؟

لا، بل قد يعطّل موقعك إن اكتفيت به. الثابت يوقف الآلية الداخلية التي تشغّل المهامّ المجدولة مع كل زيارة، لكنه لا يستبدلها بشيء. من دون خطوة ثانية تتوقّف بصمت: المقالات المؤجّلة، والنسخ الاحتياطي التلقائي، ورسائل الاشتراك، وفحوص التحديثات — بلا أي رسالة تحذير. الخطوة الثانية إلزامية: أنشئ مهمّة مجدولة حقيقية على الخادم تستدعي wp-cron.php كل خمس أو عشر دقائق من لوحة التحكّم أو عبر SSH.

هل أضع شيفرة PHP عادية في wp-config.php؟

تقنيًا نعم، لكن عمليًا لا تفعل إلا لضرورة نادرة. الملف يُحمَّل قبل نواة ووردبريس، فدوال مثل add_filter وadd_action لن تعمل لأن النظام لم يُحمَّل بعد. وأي شيفرة تطبع مخرجات ستسبّب خطأ headers already sent فورًا. الاستثناءات المقبولة محدودة: سطور ضبط الوسيط العكسي، وتعريف متغيّرات بيئة. أمّا التعديلات الوظيفية فمكانها ملفّ functions.php في قالب فرعي، أو إضافة صغيرة خاصّة بك — وكلاهما أسهل في التعطيل عند حدوث عطل.

المصادر

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