WordPress ڈیٹابیس میں سائٹ URL کیسے بدلیں بغیر سیریلائزڈ ڈیٹا توڑے

WordPress ڈیٹابیس پر سادہ UPDATE ... SET column = REPLACE(column, 'oldurl', 'newurl') مت چلائیں۔ یہ ٹیکسٹ تو درست بدل دے گا اور ساتھ ہی آپ کی سیٹنگز بھی تباہ کر دے گا، کیونکہ WordPress ارے اور آبجیکٹ کو PHP-سیریلائزڈ سٹرنگز کے طور پر محفوظ کرتا ہے، اور یہ فارمیٹ اپنے اندر موجود ہر سٹرنگ کی بائٹ لمبائی بھی درج کرتا ہے۔ خام SQL ریپلیس ٹیکسٹ کو دوبارہ لکھ دیتا ہے مگر درج شدہ لمبائی کو ہاتھ نہیں لگاتا، اور ویلیو پڑھنے کے قابل نہیں رہتی۔

اس کے بجائے ایسا ٹول استعمال کریں جو سیریلائزیشن کو سمجھتا ہو۔ کمانڈ لائن پر وہ wp search-replace ہے۔ پہلے ڈیٹابیس کا بیک اپ لیں، پھر ڈرائی رن کریں، اور اس کے بعد اصل میں چلائیں۔

اصل میں ٹوٹتا کیا ہے

ایک PHP-سیریلائزڈ سٹرنگ ایسی دکھتی ہے:

s:18:"http://example.com"

یہ 18 اس کے بعد آنے والے ٹیکسٹ کی بائٹ لمبائی ہے۔ خود گن لیں — http://example.com بالکل ٹھیک 18 حروف ہے۔

اب تصور کریں کہ ایک تھیم سیٹنگ محفوظ ہے:

a:1:{s:4:"logo";s:18:"http://example.com";}

اب http:// کو https:// سے بدلنے کے لیے سادہ SQL ریپلیس چلائیں تو ملنا یہ چاہیے:

a:1:{s:4:"logo";s:19:"https://example.com";}

مگر ملتا یہ نہیں۔ ملتا یہ ہے:

a:1:{s:4:"logo";s:18:"https://example.com";}

سٹرنگ اب 19 بائٹ کی ہے مگر دعویٰ اب بھی 18 کا ہے۔ PHP درج شدہ لمبائی پڑھتا ہے، 18 بائٹ آگے بڑھتا ہے، جہاں بند ہونے والا کوٹ اور سیمی کولن ہونا چاہیے وہاں اسے نہیں ملتا، اور وہ ہار مان لیتا ہے۔ پورا ارے ان سیریلائز ہونے میں ناکام ہو جاتا ہے۔

یہ خرابی خاموشی سے کیوں ہوتی ہے

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

یعنی علامت کوئی ایرر پیج نہیں۔ علامت یہ ہے:

• سائیڈ بارز سے ویجٹس غائب ہو جاتے ہیں
• کسٹمائزر کی سیٹنگز تھیم ڈیفالٹس پر ری سیٹ ہو جاتی ہیں
• پیج بلڈر کا لے آؤٹ ڈیٹا خالی آتا ہے اور صفحہ خالی رینڈر ہوتا ہے
• پلگ اِن کی سیٹنگز اسکرینز ایسی لگتی ہیں جیسے ابھی نئی انسٹال ہوئی ہوں
• مینیو اپنی مقرر کردہ لوکیشنز کھو دیتے ہیں

ایڈمن میں کہیں کچھ غلط ہونے کا اشارہ نہیں ملتا۔ رو ابھی بھی ڈیٹابیس میں موجود ہے، اور اس میں بظاہر درست ٹیکسٹ ہی بھرا ہوا ہے۔ صرف لمبائی کا سابقہ ایک آدھ بائٹ سے غلط ہے۔ ان سیریلائزیشن ناکام ہونے پر PHP نوٹس ضرور دیتا ہے، مگر پروڈکشن سائٹ پر جہاں ڈسپلے ایررز بند ہوں، وہ کسی کو نظر نہیں آتا۔ WP_DEBUG کو WP_DEBUG_LOG کے ساتھ آن کرنا اور WP_DEBUG_DISPLAY کو false رکھنا ان نوٹسز کو ایک لاگ فائل میں ڈال دے گا جہاں آپ انہیں پڑھ سکتے ہیں۔

نقصان بھی برابر تقسیم نہیں ہوتا۔ سادہ اسکیلر ویلیوز — siteurl، home، عام پوسٹ کنٹینٹ، یا اپنے الگ کالم میں پڑا کوئی URL — بھونڈے ریپلیس سے بھی بالکل صحیح سلامت گزر جاتی ہیں۔ صرف سیریلائزڈ ویلیوز ٹوٹتی ہیں۔ یہی وجہ ہے کہ غلط ریپلیس اکثر پہلی نظر میں کامیاب لگتا ہے۔

کچھ بھی چھونے سے پہلے wp-config.php دیکھیں

اگر wp-config.php میں WP_HOME یا WP_SITEURL طے ہیں تو یہ کونسٹنٹس ڈیٹابیس میں موجود ہر چیز پر حاوی رہتے ہیں۔ wp_options بدلنے سے بظاہر کچھ بھی نہیں ہو گا۔ ڈیٹابیس کو قصوروار ٹھہرانے سے پہلے ایسی لائنیں تلاش کریں:

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

یا انہیں نئے URL پر اپ ڈیٹ کر دیں، یا ہٹا دیں اور معاملہ ڈیٹابیس کے حوالے کر دیں۔

پہلے بیک اپ، اور سنجیدگی سے

سیریلائزیشن کی خرابی ہمیشہ آسانی سے واپس نہیں ہوتی۔ جب ایک بار لمبائی کا سابقہ اور مواد آپس میں ٹکرا جائیں تو خراب ویلیو سے اصل ویلیو بحال نہیں کی جا سکتی — اصل سٹرنگ جانے بغیر یہ معلوم کرنا ممکن نہیں کہ درست لمبائی کیا ہونی چاہیے تھی۔ بیک اپ ہی واحد حقیقی اَن ڈُو ہے۔

wp db export backup-before-replace.sql

یا اگر WP-CLI دستیاب نہ ہو تو mysqldump کے ساتھ:

mysqldump -u USER -p DBNAME > backup-before-replace.sql

ہو سکے تو اسے سرور سے باہر رکھیں۔ ویب روٹ میں پڑا بیک اپ بحالی کا ذریعہ بھی ہے اور سیکیورٹی کا مسئلہ بھی۔

محفوظ کمانڈ

WP-CLI کی search-replace ہر ویلیو کو ان سیریلائز کرتی ہے، ڈی کوڈ شدہ ساخت میں چلتی ہے، اسی کے اندر تبدیلی کرتی ہے، اور درست لمبائیوں کے ساتھ دوبارہ سیریلائز کر دیتی ہے۔ پہلے ڈرائی رن:

wp search-replace 'http://example.com' 'https://example.com' --dry-run --all-tables --skip-columns=guid

رپورٹ پڑھیں۔ یہ بتاتی ہے کہ ہر ٹیبل اور کالم میں کتنی تبدیلیاں ہوں گی۔ اگر ٹیبل کی فہرست عجیب لگے، یا کسی انجان ٹیبل میں ہزاروں میچ نکل آئیں، تو رک جائیں اور اصل کمانڈ چلانے سے پہلے دیکھیں کہ ماجرا کیا ہے۔

پھر اسے چلائیں:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --skip-columns=guid --report-changed-only

فلیگز کے بارے میں کھری باتیں:

• --all-tables ان ٹیبلز کو بھی شامل کرتا ہے جو WordPress خود رجسٹر نہیں کرتا، اور پلگ اِن کا ڈیٹا اکثر وہیں ہوتا ہے۔ اس کے بغیر کچھ پلگ اِن ٹیبلز مکمل طور پر چھوٹ جاتی ہیں۔
• --skip-columns=guid اہم ہے۔ guid فیڈ ریڈرز کے لیے مستقل شناخت ہے، کوئی زندہ URL نہیں۔ اسے بدلنے سے فیڈ سبسکرائبرز کو آپ کا پورا آرکائیو نئی پوسٹس کی طرح دکھائی دے سکتا ہے۔
• تلاش کرتے وقت آخری سلیش نہ لگائیں اور پروٹوکول کی وہ صورتیں شامل نہ کریں جنہیں آپ چھونا نہیں چاہتے۔ صرف example.com بدلنے سے ای میل ایڈریسز اور پوسٹ ٹیکسٹ میں ہر ذکر بھی متاثر ہو گا۔

اگر کمانڈ لائن استعمال نہیں کر سکتے تو سیریلائزیشن سمجھنے والے مائیگریشن پلگ اِنز ایڈمن اسکرین سے یہی ڈی کوڈنگ کا کام کرتے ہیں۔ آپ کو وہ رویہ چاہیے جو صاف لکھا ہو کہ سیریلائزڈ ڈیٹا سنبھالتا ہے؛ اگر کوئی ٹول یہ نہیں کہتا، تو مان لیں کہ وہ نہیں کرتا۔

کون سی ٹیبلز اور کالم شامل ہیں

ٹیبل	کالم	سیریلائزڈ خطرہ
wp_options	option_value	زیادہ — ویجٹس، تھیم موڈز، ٹرانزیئنٹس، زیادہ تر پلگ اِن سیٹنگز
wp_postmeta	meta_value	زیادہ — پیج بلڈر لے آؤٹس، کسٹم فیلڈ ارے
wp_usermeta	meta_value	زیادہ — کیپیبلٹیز، اسکرین اور ڈیش بورڈ ترجیحات
wp_termmeta	meta_value	درمیانہ — پلگ اِنز پر منحصر
wp_posts	post_content, guid	کنٹینٹ کے لیے کم، مگر شارٹ کوڈ ایٹریبیوٹس اور بلاک مارک اپ میں URLs ہوتے ہیں
wp_comments	comment_content, comment_author_url	کم
wp_links	link_url, link_image	کم، اور اکثر غیر استعمال شدہ

ملٹی سائٹ پر wp_blogs، wp_site، wp_sitemeta، اور فی سائٹ wp_2_options، wp_3_options وغیرہ بھی شامل کریں۔ ملٹی سائٹ پر URL بدلنے کے کچھ اضافی اصول ہیں جو سرچ اینڈ ریپلیس سے آگے جاتے ہیں — اسے الگ کام سمجھیں۔

وہ صورتیں جو search-replace مکمل حل نہیں کرتی

حدود کے بارے میں کھل کر:

ڈیٹابیس میں محفوظ JSON۔ کچھ پیج بلڈرز لے آؤٹ ڈیٹا JSON میں محفوظ کرتے ہیں جس میں فارورڈ سلیش ایسکیپ ہوتے ہیں، تو آپ کا URL https://example.com کے بجائے https:\/\/example.com کی شکل میں پڑا ہوتا ہے۔ عام شکل کی تلاش اسے چھوڑ دے گی۔ ایسکیپ شدہ سٹرنگ پر دوسرا راؤنڈ چلانا پڑ سکتا ہے۔ پہلے کاپی پر آزمائیں۔

Base64 میں انکوڈ شدہ ویلیوز۔ اگر کوئی پلگ اِن سیٹنگز محفوظ کرنے سے پہلے انکوڈ کرتا ہے تو کوئی بھی ٹیکسٹ پر مبنی ریپلیس اس URL کو دیکھ ہی نہیں سکتا۔ ایسی سیٹنگز عموماً پلگ اِن کی اپنی اسکرین سے دوبارہ درج کرنی پڑتی ہیں۔

فائلوں میں لکھے ہوئے URLs۔ جو کچھ functions.php، چائلڈ تھیم ٹیمپلیٹ، یا کسی ہارڈ کوڈ شدہ اثاثے کے پاتھ میں لکھا ہے، وہ ڈیٹابیس میں نہیں ہے اور اسے کوئی ہاتھ نہیں لگائے گا۔ تھیم ڈائریکٹری الگ سے grep کریں۔

کیش شدہ اور جنریٹ شدہ آؤٹ پٹ۔ آبجیکٹ کیش، پیج کیش اور CDN کی کاپیاں درست ریپلیس کے بعد بھی پرانے URLs دیتی رہتی ہیں۔ انہیں فلش کریں، پھر دوبارہ دیکھیں، اس سے پہلے کہ آپ یہ نتیجہ نکالیں کہ ریپلیس ناکام رہا۔

اگر آپ پہلے ہی غلط کوئری چلا چکے ہیں

بیک اپ بحال کریں۔ جواب یہی ہے، اور اسے صاف کہہ دینا اس مرمتی طریقہ کار سے بہتر ہے جو زیادہ تر کام نہیں کرتا۔

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

کچھ بھی چلانے سے پہلے درست اسٹیٹمنٹس تیار کرنے کے لیے انہیں WordPress سرچ اینڈ ریپلیس SQL ٹول سے بنائیں — یہ دکھاتا ہے کہ کن کالمز کو سادہ SQL سے چھونا محفوظ ہے اور کن کے لیے سیریلائزیشن سمجھنے والا طریقہ ضروری ہے، تاکہ کسی کمانڈ پر عمل کرنے سے پہلے آپ کو یہ تقسیم صاف نظر آ جائے۔