قاعدة بيانات WordPress تخزن الجزء المنظم من محتوى وإعدادات الموقع: المقالات والصفحات والمستخدمين والتعليقات والخيارات والـmetadata والتصنيفات وغيرها. لكنها لا تخزن ملفات الصور والفيديو نفسها عادةً؛ الملفات الثنائية توجد غالبًا داخل wp-content/uploads، بينما تحتفظ قاعدة البيانات بسجل Attachment والـmetadata والمسارات المرتبطة بها.

WordPress تعمل مع نظام إدارة قواعد بيانات مثل MySQL أوMariaDB. أما SQL فهي لغة الاستعلام التي تستخدم لقراءة البيانات وتعديلها. MySQL ليست “لغة برمجة”، وPHP لا ترسل أوامر مباشرة عشوائية؛ WordPress توفر Database API وطبقة $wpdb وAPIs أعلى منها لتقليل الأخطاء والتعارضات.

المصادر الرسمية: WordPress Database API، wpdb Class Reference، وWordPress Requirements.

ما الذي يُخزن في قاعدة البيانات وما الذي يبقى في الملفات؟

العنصر	المكان المعتاد
عنوان ومحتوى المقال	Database
الصفحات وCustom Post Types	Database
المستخدمون وPassword hashes	Database
التعليقات	Database
إعدادات WordPress/Plugins	Database غالبًا
صورة JPEG/WebP نفسها	Filesystem/uploads غالبًا
Attachment metadata والمسار	Database
Theme/Plugin PHP/CSS/JS files	Filesystem
wp-config.php	Filesystem

لذلك Database backup وحدها ليست Full-site backup. استعادة موقع كامل تحتاج قاعدة البيانات والملفات، خصوصًا uploads وplugins/themes وأي ملفات مخصصة.

MySQL وMariaDB وSQL: الفرق

MySQL: نظام إدارة قواعد بيانات Relational DBMS.
MariaDB: نظام Relational DBMS متوافق على نطاق واسع مع WordPress.
SQL: لغة استعلام لإجراء SELECT/INSERT/UPDATE/DELETE وغيرها.
wpdb: طبقة WordPress البرمجية للتعامل مع قاعدة البيانات.

متطلبات WordPress الموصى بها وقت تحديث هذا الدليل تشمل MySQL 8.0+ أوMariaDB 10.11+. راجع صفحة Requirements الرسمية قبل ترقية Server لأن متطلبات WordPress وPlugins قد تتغير.

أين توجد بيانات الاتصال بقاعدة البيانات؟

توجد عادة في wp-config.php:

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

هذه بيانات حساسة. لا تنشر Screenshot لها، ولا ترسل الملف كاملًا في Ticket عام.

إذا كان هدفك تعديل الملف نفسه، راجع دليل wp-config.php.

بادئة الجداول Table Prefix

الأمثلة في الإنترنت تستخدم غالبًا wp_:

wp_posts
wp_options
wp_users

لكن wp_ ليست إلزامية. الموقع قد يستخدم:

mwp_posts
shop_options
abc_users

اقرأ قيمة $table_prefix من wp-config.php أوستخدم WordPress APIs بدل Hard-code لأسماء الجداول.

تغيير Prefix بعد إنشاء موقع حي ليس “حركة أمان بسيطة”؛ يحتاج إعادة تسمية جداول وتحديث Keys/References وقد يكسر الموقع. لا تنفذه على Production لمجرد أن Tutorial قديم قال إن wp_ خطر بحد ذاته.

الجداول الأساسية في WordPress

على تثبيت Single Site قياسي، WordPress Core تتعامل مع مجموعة جداول أساسية. الأسماء أدناه تفترض Prefix wp_ فقط للتوضيح:

الجدول	وظيفته الأساسية
wp_posts	Posts, Pages, Attachments وCPTs وغيرها من أنواع المنشورات
wp_postmeta	Metadata المرتبطة بالمنشورات
wp_comments	التعليقات وبعض البيانات المرتبطة بنظم تستخدم Comments API
wp_commentmeta	Metadata للتعليقات
wp_terms	أسماء Terms
wp_term_taxonomy	ربط Term بنوع Taxonomy مثل category/tag
wp_term_relationships	العلاقة بين Objects والTerms
wp_termmeta	Metadata للTerms
wp_users	الحسابات الأساسية
wp_usermeta	Metadata للمستخدمين والصلاحيات وغيرها
wp_options	إعدادات Site/Plugins وTransients وبعض بيانات runtime
wp_links	جدول Legacy قد يبقى موجودًا رغم أن Link Manager ليس ميزة رئيسية افتراضيًا

مهم: هذا ليس معناه أن كل موقع يحتوي هذه الجداول فقط. Plugins مثل WooCommerce وMailPoet وAction Scheduler وSEO plugins تستطيع إنشاء جداول إضافية.

wp_posts لا يحتوي “المقالات فقط”

اسم الجدول قد يضلل المبتدئ. wp_posts يخزن أنواعًا كثيرة من Objects:

Posts.
Pages.
Attachments.
Revisions.
Navigation items في بعض الأنظمة القديمة.
Custom Post Types التي تسجلها Plugins/Themes.

التمييز يتم عبر post_type وحقول أخرى، وليس بجدول منفصل لكل نوع افتراضيًا.

الصور: ماذا تخزن WordPress في Database؟

عندما ترفع صورة، WordPress تنشئ Attachment record في قاعدة البيانات وتخزن Metadata مثل الأحجام ومعلومات الملف، بينما ملف الصورة نفسه يوجد عادة تحت:

wp-content/uploads/YYYY/MM/

لذلك حذف Attachment row من قاعدة البيانات لا يساوي دائمًا حذف كل الملفات المادية بالطريقة الصحيحة، والعكس صحيح.

كلمات المرور ليست نصًا واضحًا

حقل user_pass لا يحتوي Password التي تستطيع قراءتها. WordPress تخزن Hash أحادي الاتجاه.

إذا نسيت كلمة المرور، لا تحاول “فك” القيمة من Database. استخدم دليل إعادة تعيين كلمة مرور WordPress. WP-CLI أوReset flow أفضل من التعديل اليدوي في DB عندما يكون متاحًا.

wp_options وAutoload

wp_options من أكثر الجداول حساسية للأداء لأن بعض الخيارات تُحمّل تلقائيًا في كل Request وفق خصائص Autoload.

المشكلة ليست “كل wp_options كبيرة = بطيئة”. ابحث عن:

Autoloaded data ضخمة.
Options يتيمة من Plugins حُذفت.
Transients متراكمة بسبب نظام معطل.
Plugin يخزن Payload كبيرة في Option واحدة.

لا تحذف Options لمجرد الاسم. بعض القيم قد تكون Licensing أوCron state أوConfiguration حرجة.

للتشخيص المتقدم استخدم دليل تحسين قاعدة بيانات WordPress بدون حذف بيانات مهمة.

Revisions وpostmeta: متى يصبح الحجم مشكلة؟

مواقع Page Builders وWooCommerce قد تنتج Metadata كثيرة. الحجم وحده ليس دليلًا على وجود خطأ. راقب:

Slow queries.
Indexes.
عدد Rows لكل Post.
Meta queries على datasets ضخمة.
Revisions غير المحدودة.
بيانات Plugins القديمة.

لا تنفذ DELETE جماعيًا للـpostmeta بدون معرفة Owner لكل Key.

WooCommerce وHPOS

في WooCommerce الحديثة، الطلبات لا يجب أن تُعامل كأنها Posts دائمًا. High-Performance Order Storage تستخدم جداول مخصصة للOrders في البيئات المفعلة، مثل:

_wc_orders
_wc_order_addresses
_wc_order_operational_data
_wc_orders_meta

لذلك أي Code أوReport جديد يجب أن يستخدم WooCommerce CRUD/API بدل SQL يفترض wp_posts وwp_postmeta.

wpdb: طبقة WordPress للتعامل مع DB

WordPress توفر الكائن العالمي $wpdb لاستعلامات تحتاجها ولا توفرها API أعلى مستوى.

<?php
global $wpdb;

$post_id = 123;
$row = $wpdb->get_row(
    $wpdb->prepare(
        "SELECT ID, post_title FROM {$wpdb->posts} WHERE ID = %d",
        $post_id
    )
);

لاحظ:

استخدام {$wpdb->posts} بدل Hard-code لـwp_posts.
استخدام $wpdb->prepare() للقيم الديناميكية.
عدم دمج User input مباشرة في SQL.

استخدم APIs أعلى مستوى عندما توجد

حتى لو تستطيع كتابة SQL، الأفضل غالبًا استخدام:

get_post() / WP_Query.
User APIs.
Options API.
Metadata API.
Term APIs.
WooCommerce CRUD.

هذه APIs تتعامل مع Cache وHooks وCompatibility أفضل من UPDATE مباشر على الجداول.

WP-CLI لفحص قاعدة البيانات

إذا لديك SSH وWP-CLI، تستطيع استخدام أوامر Database بصورة أوضح من phpMyAdmin في كثير من المهام.

عرض الجداول

wp db tables

تصدير نسخة

wp db export backup-before-change.sql

تحقق من المسار والصلاحيات ومساحة القرص، وانقل النسخة إلى Storage آمن إذا كانت تحتوي بيانات مستخدمين.

المصدر: WP-CLI – wp db tables.

phpMyAdmin: أداة إدارة وليست طريقة WordPress الأساسية

phpMyAdmin مفيدة لفحص DB أوExport/Import أوتشخيص طارئ. لكنها تعمل مباشرة على البيانات، لذلك تتجاوز WordPress Hooks وValidation في كثير من العمليات.

قبل أي Write:

تأكد أنك اخترت Database الصحيحة.
خذ Backup.
نفذ SELECT قبل UPDATE/DELETE لفهم Rows المستهدفة.
استخدم LIMIT أوTransaction عندما تدعم العملية والبيئة ذلك.
لا تنسخ SQL من مقال قديم وتنفذه على Production بلا مراجعة.

لو تستخدم cPanel، راجع دليل cPanel 2026 للوصول إلى Database tools بدون اعتبار cPanel شرطًا لكل استضافة.

لا تستخدم DELETE كمثال تعليمي عابر

مثال قديم مثل:

DELETE FROM wp_comments WHERE ...;

يمكن أن يمسح بيانات إنتاج نهائيًا. للتعلم ابدأ بـSELECT، واستخدم بيئة تجريبية.

Backup قبل Database migration أوcleanup

قبل تعديل Schema أوتنظيف جداول:

خذ Database backup قابلة للاستعادة.
يفضل Full-site backup أيضًا إذا التغيير مرتبط بPlugin/Theme.
اختبر Restore، لا تكتفِ بوجود ملف SQL.
سجل الوقت والإصدار قبل التغيير.
لا تعتمد على Backup موجودة على نفس القرص وحده.

Optimize Tables: ليس زر سرعة سحريًا

تشغيل OPTIMIZE TABLE لكل شيء دوريًا ليس استراتيجية Performance كاملة، وقد لا يعطي فائدة ملموسة حسب Engine وحالة الجداول.

قبل أي Optimization، حدد المشكلة:

هل Queries بطيئة؟
هل هناك Table bloat؟
هل Index ناقص؟
هل Autoload ضخمة؟
هل Plugin يكتب Rows بلا تنظيف؟

قِس قبل وبعد بدل اعتبار نجاح الأمر دليلًا على أن الموقع أصبح أسرع.

إضافة مستخدم مباشرة من DB؟

لا أوصي ببناء Administrator يدويًا عبر Insert في users فقط. مستخدم WordPress يحتاج أيضًا Metadata وRole/Capabilities صحيحة، والخطأ قد يخلق حسابًا غير صالح أوصلاحيات مفرطة.

استخدم WordPress Admin أوWP-CLI أوUser APIs. الوصول إلى Database وحده لا يجب أن يتحول إلى طريقة إدارة يومية.

أمان قاعدة البيانات

استخدم DB user بصلاحيات مناسبة فقط.
لا expose قاعدة البيانات للإنترنت بلا حاجة.
احمِ Hosting/SSH/phpMyAdmin بـMFA حيث يتوفر.
حافظ على WordPress/PHP/DB/plugins محدثة.
لا تخزن Secrets داخل Git.
راقب SQL injection على مستوى التطبيق وWAF، لكن أصل المشكلة يُعالج بالValidation/Prepared statements.
شفّر Backups الحساسة حسب سياسة التخزين.

تغيير Prefix لا يعوض أيًا من هذه الطبقات.

Error Establishing a Database Connection

إذا ظهرت الرسالة، الأسباب المعتادة تشمل Credentials خاطئة، DB server غير متاح، Host خاطئ، Tables تالفة أوضغط/موارد.

لا تبدأ بحذف جداول. استخدم دليل Error Establishing a Database Connection للتشخيص المتدرج.

Multisite مختلف

WordPress Multisite تضيف جداول Network/global وتكرر بعض الجداول لكل Site حسب البنية. لذلك لا تعتمد على قائمة Single Site لتنفيذ Script تنظيف داخل Network.

Checklist قبل تعديل قاعدة بيانات Production

Backup حديثة ومختبرة.
Staging عند التغيير الكبير.
Database الصحيحة مؤكدة.
Prefix الحقيقي معروف.
SELECT قبل UPDATE/DELETE.
لا SQL مباشر إذا توجد WordPress API مناسبة.
HPOS محسوبة عند WooCommerce.
لا User/Order passwords أوPII في Logs.
خطة Rollback واضحة.
Health check بعد التغيير.

الخلاصة

قاعدة بيانات WordPress في 2026 تخزن المحتوى المنظم والإعدادات والعلاقات والMetadata، بينما ملفات Media وTheme/Plugin تبقى عادة في Filesystem. استخدم MySQL/MariaDB كDBMS، وWordPress APIs أو$wpdb بدل SQL المباشر، ولا تفترض Prefix wp_ أوأن الطلبات دائمًا في wp_posts بسبب HPOS. خذ Backup قبل أي Write، وقِس المشكلة قبل Cleanup أوOptimization.

قاعدة بيانات WordPress في 2026: الجداول وwpdb والنسخ الاحتياطي والأمان