सर्च और रिप्लेस SQL

सीरियलाइज़्ड डेटा को खराब किए बिना अपना साइट URL बदलें

आपके browser में चलता है. कुछ भी upload नहीं होता.

बदलाव

पुराना URL नया URL Table prefixwp-config.php जाँचें। यह हमेशा wp_ नहीं होता — और multisite पर तो निश्चित ही नहीं होता।

कुछ भी चलाने से पहले यह पढ़ें

WordPress कई विकल्पों को PHP-serialized स्ट्रिंग के रूप में संग्रहीत करता है, और एक serialized स्ट्रिंग अपनी बाइट लंबाई ख़ुद दर्ज करती है — s:19:"http://old-site.com"। एक सादा SQL रिप्लेस टेक्स्ट तो बदल देता है पर लंबाई नहीं, इसलिए PHP उस row को फिर unserialize नहीं कर पाता। इसमें कोई एरर नहीं आता। मान बस चुपचाप ख़ाली हो जाता है।

आप क्या खोते हैं: widget का configuration, theme mods, और ज़्यादातर प्लगइन settings। आमतौर पर यह आपको कई दिनों बाद तक पता ही नहीं चलता, और तब तक वह बैकअप भी जा चुका होता है जिससे आप रिस्टोर करते।

यही वजह है कि नीचे दी गई क्वेरीज़ जानबूझकर wp_options को नहीं छूतीं।

आप क्या move कर रहे हैं?

पोस्ट कंटेंट और अंशpost_content और post_excerpt प्लेन टेक्स्ट हैं। सुरक्षित। GUID कॉलम भी दोबारा लिखेंइसे तब तक टिक न करें जब तक आप न जानते हों कि आपको इसकी ज़रूरत क्यों है। GUID एक स्थायी विशिष्ट पहचानकर्ता है, URL नहीं — इसे बदलने से हर feed reader हर पुरानी पोस्ट को बिल्कुल नई मान लेता है। पोस्ट मेटा (serialized हो सकता है — जोखिमभरा)postmeta में अक्सर serialized डेटा होता है। इसे टिक करने पर आपको क्वेरी के साथ एक ज़ोरदार चेतावनी दिखती है।

search-replace.sql

पहले डेटाबेस का बैकअप लें। 'लेने के बारे में सोचें' नहीं — बैकअप लें ही। UPDATE के लिए कोई अनडू नहीं होता।

सर्च और रिप्लेस SQL के बारे में

WordPress डेटाबेस पर बिना सोचे-समझे किया गया SQL फ़ाइंड-एंड-रिप्लेस हर उस सीरियलाइज़्ड ऑप्शन को खराब कर देता है जिसे वह छूता है, क्योंकि स्टोर की गई स्ट्रिंग की लंबाई अब मेल नहीं खाती। यह वे क्वेरी जनरेट करता है जो सुरक्षित हैं, और ठीक-ठीक समझाता है कि कौन-सी नहीं हैं।

मिलते-जुलते

दूसरे tools जिनकी आपको ज़रूरत पड़ सकती है

wp-config.php जनरेटर

2014 की किसी ब्लॉग पोस्ट से कॉपी-पेस्ट किए बिना एक सही wp-config.php बनाएँ

सामान्य प्रश्न

सवाल

क्या मैं SQL find and replace से अपनी WordPress site URL बदल सकता हूँ?

सुरक्षित तरीके से नहीं, और यह WordPress में सबसे ज़्यादा शेयर की जाने वाली ग़लत सलाह है. कई options PHP-serialized strings के रूप में स्टोर होते हैं जो अपनी byte length खुद record करते हैं. एक सादा SQL replace text बदल देता है पर length नहीं, इसलिए PHP उस row को unserialize करने में चुपचाप fail हो जाता है और value बस गायब हो जाती है — अपने साथ widget settings, theme mods और plugin config ले जाकर.

मुझे इसके बजाय क्या इस्तेमाल करना चाहिए?

WP-CLI: पहले 'wp search-replace old new --all-tables --dry-run', फिर --dry-run के बिना. यह serialization को समझता है और length prefixes को सही से rewrite करता है. अगर आपके पास CLI access नहीं है, तो Better Search Replace plugin admin से वही काम करता है.

क्या मुझे GUID column update करना चाहिए?

नहीं. GUID किसी post के लिए एक स्थायी unique identifier है, कोई link नहीं, और feed readers इसी के आधार पर काम करते हैं. इसे rewrite करने से हर subscriber को हर पुरानी post एकदम नई दिखने लगती है. WordPress documentation साफ़ कहती है कि इसे न बदलें.