WordPress ڈیٹابیس کنکشن کی خرابی: اسے کیسے ٹھیک کریں

آپ اپنی سائٹ کھولتے ہیں اور ہر صفحہ — فرنٹ اینڈ اور wp-admin دونوں — ایک واحد سرمئی جملے سے بدل جاتا ہے: ڈیٹابیس کنکشن قائم کرنے میں خرابی۔ کچھ رینڈر نہیں ہوتا، کیونکہ کچھ ہو ہی نہیں سکتا۔ WordPress صفحہ بنانے تک پہنچا ہی نہیں۔

یہ ذہنی خاکہ اس کی مرمت کو تیز کر دیتا ہے۔ WordPress آپ کا سارا مواد — پوسٹس، صفحات، ترتیبات، صارفین — فائلوں میں نہیں بلکہ ایک MySQL ڈیٹابیس میں رکھتا ہے۔ ہر درخواست پر یہ wp-config.php سے چار لاگ اِن تفصیلات پڑھتا ہے، اُس ڈیٹابیس سے جڑتا ہے، اور جو درکار ہو نکال لاتا ہے۔ اس خرابی کا مطلب ہے کہ وہ کنکشن آزمایا گیا اور مسترد ہو گیا۔ حل یہ جاننا ہے کہ کیوں مسترد ہوا، اور صرف تین امکانات ہیں۔

تین وجوہات، امکان کی ترتیب سے

1. wp-config.php میں کوئی غلط کریڈینشل — ہوسٹ بدلنے کا معمول کا نتیجہ۔
2. ڈیٹابیس سرور بند یا حد سے زیادہ مصروف ہے — آپ کی طرف سے کچھ نہ بدلنے کا معمول کا نتیجہ۔
3. ڈیٹابیس خراب ہے — کم عام، اور یہ خود کو مختلف انداز میں ظاہر کرتا ہے۔

انہیں اسی ترتیب سے دیکھیں۔

پہلا مرحلہ: چار کریڈینشلز جانچیں

اپنی سائٹ کی جڑ میں wp-config.php کو SFTP یا اپنے ہوسٹ کے فائل مینیجر سے کھولیں۔ چار سطریں کنکشن طے کرتی ہیں:

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

ان میں سے ہر ایک کو بالکل وہی ہونا چاہیے جو آپ کے ہوسٹ نے مختص کیا۔ اپنے ہوسٹنگ کنٹرول پینل کا ڈیٹابیس حصہ کھولیں (cPanel میں یہ “MySQL Databases” ہے) اور حرف بہ حرف موازنہ کریں:

• DB_NAME — ہوسٹ اکثر نام کے آگے آپ کے اکاؤنٹ کا سابقہ لگاتے ہیں، جیسے cpaneluser_wpdb۔ سابقہ نام کا حصہ ہے۔
• DB_USER — وہی سابقہ لاگو ہوتا ہے، اور صارف کو اُس ڈیٹابیس سے مختص ہونا چاہیے، صرف موجود نہیں۔
• DB_PASSWORD — بلا مقابلہ سب سے عام مجرم۔ اگر یقین نہ ہو تو کنٹرول پینل میں اسے ری سیٹ کریں اور نئی قدر پیسٹ کریں۔ آخر میں اضافی خالی جگہ یا اسمارٹ کوٹ سے ہوشیار رہیں۔
• DB_HOST — localhost فرض نہ کریں۔ بہت سے ہوسٹ ایک مخصوص ڈیٹابیس سرور استعمال کرتے ہیں جس کا پتہ mysql.yourhost.com جیسا ہوتا ہے، کبھی کبھی :port کے ساتھ۔ کنٹرول پینل درست قدر دکھاتا ہے۔

چونکہ یہ فائل بالکل وہی جگہ ہے جہاں یہ چار قدریں رہتی ہیں، اس لیے ایک صاف اور درست کوٹ شدہ wp-config.php دوبارہ بنانے کا محفوظ ترین طریقہ wp-config.php جنریٹر ہے — ڈیٹابیس کے چار خانے بھریں اور نتیجہ پرانے بلاک پر پیسٹ کر دیں۔

یہی ایک مرحلہ تقریباً ہر منتقلی کے بعد خرابی ٹھیک کر دیتا ہے، کیونکہ جو کریڈینشلز پرانے ہوسٹ پر درست تھے وہ نئے پر غلط ہوتے ہیں۔

دوسرا مرحلہ: تصدیق کریں کہ ڈیٹابیس سرور واقعی چل رہا ہے

اگر کریڈینشلز درست ہیں اور خرابی برقرار ہے — خاص طور پر اگر یہ آپ کی طرف سے بغیر کسی تبدیلی کے خود بخود نمودار ہوئی — تو خود ڈیٹابیس سرور مشتبہ ہے۔

شیئرڈ ہوسٹنگ پر یہ عام اور عموماً عارضی ہوتا ہے: MySQL سروس ٹریفک کے دباؤ میں دب جاتی ہے یا فی اکاؤنٹ کنکشن حد کو چھو لیتی ہے اور نئے کنکشن مسترد کرنے لگتی ہے۔ عام طور پر چند منٹ میں سنبھل جاتی ہے۔ کوئی سخت قدم اٹھانے سے پہلے تھوڑا انتظار کر کے دوبارہ لوڈ کریں۔

یہ جانچنے کے لیے کہ کریڈینشلز WordPress سے آزادانہ طور پر معتبر بھی ہیں یا نہیں، wp-config.php کے ساتھ ایک ننھا اسکرپٹ رکھ دیں:

<?php
$link = mysqli_connect('localhost', 'your_database_user', 'your_database_password');
if (!$link) {
    die('Connection failed: ' . mysqli_connect_error());
}
echo 'Connected — the server and credentials are fine.';

اپنے اصل DB_HOST، DB_USER اور DB_PASSWORD استعمال کریں۔ اگر یہ Connected چھاپے تو آپ کی لاگ اِن تفصیلات کام کرتی ہیں اور مسئلہ کہیں اور ہے (خراب ڈیٹابیس، تیسرا مرحلہ)۔ اگر یہ کنکشن خرابی چھاپے تو پیغام بتا دیتا ہے کون سی: “Access denied” کا مطلب غلط صارف یا پاس ورڈ؛ “Can’t connect to MySQL server” کا مطلب غلط ہوسٹ یا واقعی بند سروس — ہوسٹ سے رابطے کا وقت ہے۔ کام مکمل ہوتے ہی اسکرپٹ حذف کر دیں۔

تیسرا مرحلہ: خراب ڈیٹابیس کی مرمت کریں

ایک نشانی خرابی کو کنکشن کے مسئلے سے الگ کرتی ہے: فرنٹ اینڈ لوڈ ہوتا ہے مگر wp-admin خرابی دکھاتا ہے، یا اس کے برعکس۔ اگر کنکشن واقعی مسترد ہوتا تو دونوں مردہ ہوتے۔ ایسی تقسیم خراب ٹیبلوں کی طرف اشارہ کرتی ہے۔

WordPress میں ایک اندرونی مرمت ٹول موجود ہے۔ wp-config.php میں، “stop editing” کے تبصرے سے اوپر، ایک سطر شامل کریں:

define( 'WP_ALLOW_REPAIR', true );

پھر یہ URL براہِ راست اپنے براؤزر میں کھولیں:

https://yoursite.com/wp-admin/maint/repair.php

یہ بغیر لاگ اِن کھلتا ہے — یہی مقصد ہے، کیونکہ ہو سکتا ہے آپ باہر بند ہوں — اور “Repair Database” اور “Repair and Optimize Database” پیش کرتا ہے۔ اسے چلائیں۔

پھر فوراً وہ سطر wp-config.php سے حذف کر دیں۔ جب تک یہ موجود ہے، انٹرنیٹ پر کوئی بھی وہ URL کھول کر آپ کے ڈیٹابیس پر مرمت چلا سکتا ہے۔ یہ کوئی اختیاری صفائی نہیں؛ یہ اُس سوراخ کو بند کرنا ہے جو آپ نے ابھی کھولا۔

چوتھا مرحلہ: جب مرمت جڑ ہی نہیں پاتی

اگر مرمت کا صفحہ خود کنکشن خرابی دکھائے تو مرمت کے لیے کچھ ہے ہی نہیں — ڈیٹابیس تک بالکل رسائی نہیں، اس لیے آپ پہلے یا دوسرے مرحلے پر واپس آ جاتے ہیں۔ اُس مقام پر قابلِ اعتماد قدم یہ ہے کہ ڈیٹابیس کو اپنے ہوسٹ کے تازہ ترین بیک اپ سے بحال کریں۔ زیادہ تر کنٹرول پینل روزانہ خودکار ڈیٹابیس اسنیپ شاٹ رکھتے ہیں؛ کل رات کی بحالی تقریباً ہمیشہ اُس خرابی کے پیچھے بھاگنے سے تیز اور محفوظ ہوتی ہے جس سے آپ جڑ ہی نہیں سکتے۔

وہ مشورے جنہیں بے فکر ہو کر نظرانداز کر دیں

“بس WordPress دوبارہ انسٹال کر دیں۔” یہ خرابی ڈیٹابیس کنکشن کے بارے میں ہے، کور فائلوں کے بارے میں نہیں۔ دوبارہ انسٹال کرنا وہی فائلیں بدل دیتا ہے جو ٹھیک کام کر رہی ہیں اور کسی خراب چیز کو چھوتا ہی نہیں۔

“اپنی PHP میموری حد بڑھا دیں۔” میموری ختم ہونا ایک الگ خرابی ہے جس کا پیغام مختلف ہے۔ حد بڑھانا مسترد شدہ ڈیٹابیس کنکشن کے لیے کچھ نہیں کرتا اور صرف یہ چھپاتا ہے کہ آپ نے کبھی کریڈینشلز جانچے ہی نہیں۔

“اپنا کیش صاف کریں۔” ناکامی PHP میں اُس وقت ہوتی ہے جب کوئی کیش صفحہ پیش کر ہی نہیں سکتا۔ جب تک کنکشن مسترد ہو رہا ہے، کیش صاف کرنے سے کچھ نہیں بدلتا؛ یہ صرف سائٹ واپس آنے کے بعد کرنے لائق ہے۔

“ڈیٹابیس براہِ راست ایڈٹ کر کے ٹھیک کریں۔” کنکشن کے کام کرنے کی تصدیق سے پہلے ہی phpMyAdmin سے ہاتھ کے ذریعے ٹیبل ایڈٹ کرنے لگنا وہی راستہ ہے جو ایک عارضی بندش کو مستقل ڈیٹا نقصان میں بدل دیتا ہے۔ پہلے کنکشن کی تصدیق کریں؛ ڈیٹا کو سب سے آخر میں چھوئیں، اور صرف بیک اپ سے۔

اب بھی مسئلہ حل نہ ہو؟

اگر ٹیسٹ اسکرپٹ سے کریڈینشلز کی تصدیق ہو جاتی ہے، سرور چل رہا ہے، اور مرمت جڑ کر بغیر خرابی رپورٹ دیتی ہے، مگر سائٹ پھر بھی پیغام دکھاتی ہے، تو باقی بچا مشتبہ ایسا پلگ ان ہے جو اپنے الگ کنکشن سے ڈیٹابیس سے بات کرتا ہے — کوئی کیشنگ یا ڈیٹابیس پلگ ان جس نے پرانا ہوسٹ محفوظ کر رکھا ہے۔ اسے خارج کرنے کے لیے wp-content/plugins کا نام SFTP سے plugins-off کر دیں۔ اگر خرابی صاف ہو جائے تو پلگ ان ایک ایک کر کے واپس لائیں یہاں تک کہ وہ لوٹ آئے۔