تلاش و تبدیلی SQL

serialized ڈیٹا کو خراب کیے بغیر اپنی سائٹ کا URL بدلیں

آپ کے براؤزر میں چلتا ہے۔ کچھ بھی اپ لوڈ نہیں ہوتا۔

تبدیلی

پرانا URL نیا URL ٹیبل prefixwp-config.php چیک کریں۔ یہ ہمیشہ wp_ نہیں ہوتا — اور ملٹی سائٹ پر تو یقیناً نہیں ہوتا۔

کچھ بھی چلانے سے پہلے یہ پڑھ لیں

WordPress بہت سے آپشنز کو PHP-serialized اسٹرنگز کے طور پر محفوظ کرتا ہے، اور ایک serialized اسٹرنگ اپنی بائٹ لمبائی خود ریکارڈ کرتی ہے — s:19:"http://old-site.com"۔ ایک سادہ SQL ریپلیس متن تو بدل دیتا ہے لیکن لمبائی نہیں، اس لیے PHP اس رَو کو مزید unserialize نہیں کر سکتا۔ یہ کوئی error نہیں دیتا۔ ویلیو بس خاموشی سے خالی ہو جاتی ہے۔

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

یہی وجہ ہے کہ نیچے دی گئی کوئریز جان بوجھ کر wp_options کو ہاتھ نہیں لگاتیں۔

آپ کیا منتقل کر رہے ہیں؟

پوسٹ کنٹینٹ اور excerptspost_content اور post_excerpt سادہ متن ہیں۔ محفوظ۔ GUID کالم بھی دوبارہ لکھیںاسے ٹک نہ کریں جب تک آپ کو معلوم نہ ہو کہ اس کی ضرورت کیوں ہے۔ GUID ایک مستقل منفرد شناخت کنندہ ہے، URL نہیں — اسے تبدیل کرنے سے ہر feed reader ہر پرانی پوسٹ کو بالکل نئی سمجھتا ہے۔ پوسٹ میٹا (serialized ہو سکتا ہے — خطرناک)postmeta میں اکثر serialized ڈیٹا ہوتا ہے۔ اسے ٹک کرنے پر کوئری آپ کو ایک نمایاں وارننگ کے ساتھ دکھائی جاتی ہے۔

search-replace.sql

پہلے ڈیٹابیس کا بیک اپ لیں۔ 'لینے پر غور کریں' نہیں — لیں۔ UPDATE کو واپس کرنے (اَن ڈو) کا کوئی طریقہ نہیں۔

تلاش و تبدیلی SQL کے بارے میں

WordPress ڈیٹابیس پر ایک سادہ SQL find-and-replace ہر اس serialized آپشن کو خراب کر دیتا ہے جسے یہ چھوتا ہے، کیونکہ محفوظ شدہ string کی لمبائی اب میل نہیں کھاتی۔ یہ وہ queries بناتا ہے جو محفوظ ہیں، اور بالکل واضح کرتا ہے کہ کون سی محفوظ نہیں۔

متعلقہ

دیگر ٹولز جن کی آپ کو ضرورت ہو سکتی ہے

wp-config.php جنریٹر

2014 کی کسی بلاگ پوسٹ سے کاپی پیسٹ کیے بغیر ایک درست wp-config.php بنائیں

عمومی سوالات

سوالات

کیا میں SQL find and replace سے اپنی WordPress سائٹ کا URL بدل سکتا ہوں؟

محفوظ طریقے سے نہیں، اور یہ WordPress میں سب سے زیادہ شیئر کیا گیا برا مشورہ ہے۔ بہت سے options، PHP-serialized strings کے طور پر محفوظ ہوتے ہیں جو اپنی byte length خود ریکارڈ کرتے ہیں۔ ایک سادہ SQL replace متن بدلتا ہے مگر length نہیں، لہٰذا PHP خاموشی سے رَو کو unserialize کرنے میں ناکام رہتا ہے اور اقدار محض غائب ہو جاتی ہے — ویجٹ سیٹنگز، theme mods اور پلگ ان config کو ساتھ لے کر۔

مجھے اس کے بجائے کیا استعمال کرنا چاہیے؟

WP-CLI: پہلے 'wp search-replace old new --all-tables --dry-run'، پھر --dry-run کے بغیر۔ یہ serialization کو سمجھتا ہے اور length prefixes کو درست طور پر دوبارہ لکھتا ہے۔ اگر آپ کے پاس CLI رسائی نہیں، تو Better Search Replace پلگ ان ایڈمن سے وہی کام کرتا ہے۔

کیا مجھے GUID کالم اپڈیٹ کرنا چاہیے؟

نہیں۔ GUID کسی پوسٹ کا ایک مستقل منفرد شناخت کنندہ ہے، لنک نہیں، اور فیڈ ریڈرز اسی سے چلتے ہیں۔ اسے دوبارہ لکھنا ہر سبسکرائبر کو ہر پرانی پوسٹ بالکل نئی دکھاتا ہے۔ WordPress دستاویزات واضح طور پر کہتی ہیں کہ اسے مت بدلیں۔