WordPress दर्जनों डेटाबेस टेबल में पूरे (absolute) URL सहेजता है, इसलिए डोमेन बदलने या SSL पर जाने के बाद पुराने पते पोस्ट, options और प्लगइन सेटिंग्स में बिखरे रह जाते हैं: सर्च और रिप्लेस इन्हें सुरक्षित रूप से साफ़ करने का तरीका है। यह गाइड KPanel में ऐसा करने के दो समर्थित तरीके बताती है, यह भी बताती है कि एक आम तीसरा तरीका डेटा को क्यों खराब कर देता है, और नतीजे की जांच कैसे करें।
आपको इसकी ज़रूरत कब होती है
- SSL सक्षम करने के बाद
http://सेhttps://पर जाते समय। - डोमेन बदलते समय, उदाहरण के लिए
old-brand.co.nzसेnew-brand.co.nzपर। - स्टेजिंग को प्रोडक्शन पर पुश करने के बाद, जब स्टेजिंग होस्टनेम अब भी डेटाबेस में मौजूद हो।
- किसी पुराने एसेट होस्ट को हटाते समय और हर इमेज URL को एक साथ नई जगह की ओर करते समय।
- कई पोस्ट में फैली किसी एक जैसी गलती को ठीक करते समय, जैसे कोई पुराना फ़ोन नंबर या बंद हो चुके उत्पाद का नाम।
सर्च और रिप्लेस एक साथ हर टेबल की पंक्तियों को फिर से लिखता है और किसी एक पंक्ति के लिए कोई undo नहीं है। शुरू करने से पहले बैकअप लें, हर बार, भले ही बदलाव मामूली लगे। जब आप नीचे बताए गए बिल्ट-इन टूल इस्तेमाल करते हैं तो KPanel अपने आप एक बैकअप बनाता है, लेकिन अगर आप कमांड खुद चला रहे हैं तो बैकअप की ज़िम्मेदारी आपकी है। बैकअप लेना देखें।
आप सीधे SQL REPLACE क्यों नहीं चला सकते
WordPress डेटाबेस के काम में यह सबसे ज़्यादा नुकसान पहुँचाने वाली गलती है, इसलिए कोई तरीका चुनने से पहले इसे समझना ज़रूरी है।
WordPress प्लगइन सेटिंग्स, थीम options और विजेट डेटा को PHP serialised स्ट्रिंग के रूप में सहेजता है। एक serialised स्ट्रिंग अपने अंदर की हर वैल्यू की लंबाई दर्ज करती है, इस तरह:
a:1:{s:3:"url";s:26:"http://old-domain.co.nz/x";}
वह s:26 बताता है कि URL 26 अक्षर लंबा है। सादे SQL REPLACE() से http:// को https:// से बदलें, तो टेक्स्ट 27 अक्षर का हो जाता है जबकि सहेजी गई लंबाई अब भी 26 बताती है। तब PHP पूरे option को unserialise करने से मना कर देता है, और सेटिंग बिना किसी सूचना के खाली हो जाती है। थीम customiser सेटिंग्स गायब हो जाती हैं, स्लाइडरों की स्लाइड चली जाती हैं, प्लगइन लाइसेंस अपना रजिस्ट्रेशन खो देते हैं।
KPanel जो WP-CLI search-replace चलाता है, वह हर वैल्यू को unserialise करता है, उसके अंदर बदलाव करता है, और सही लंबाई के साथ उसे फिर से serialise करता है। इसी वजह से यहाँ केवल इसी तरीके के बारे में बताया गया है।
किसी WordPress डेटाबेस पर कभी भी UPDATE wp_options SET option_value = REPLACE(...) या phpMyAdmin में उसके बराबर कुछ भी न चलाएं। ऐसा लगता है कि यह काम कर गया, यह प्रभावित पंक्तियों की संख्या भी बताता है, और चुपचाप हर उस serialised सेटिंग को नष्ट कर देता है जिसे इसने छुआ। बैकअप रीस्टोर करने के अलावा इसकी कोई मरम्मत नहीं है।
तरीका 1: Search & Replace कार्ड
लगभग हर किसी के लिए यही सही विकल्प है। यह हर WordPress प्लान पर उपलब्ध है।
- KPanel में साइन इन करें और बाएं साइडबार में वेबसाइटें पर क्लिक करें।
- साइट पर क्लिक करें।
- WordPress टैब खोलें, फिर Quick Actions सेक्शन खोलें।
- Search & Replace कार्ड ढूंढें और Configure पर क्लिक करें।
- Find (old value) में मौजूदा टेक्स्ट दर्ज करें।
- Replace with में नया टेक्स्ट दर्ज करें।
- Dry run (preview only, no changes) को टिक किया हुआ रहने दें और Preview पर क्लिक करें।
Dry run बताता है कि कितने बदलाव किए जाएंगे और इस संख्या को टेबल और कॉलम के अनुसार बांटकर दिखाता है, ताकि आप लागू करने से पहले ठीक-ठीक देख सकें कि बदलाव कहाँ होगा।
जब प्रीव्यू सही दिखे:
- Dry run का टिक हटाएं।
- Run पर क्लिक करें।
- डायलॉग में पुष्टि करें।
बदलाव शुरू होने से पहले अपने आप एक पूरा बैकअप लिया जाता है, और यह प्रक्रिया प्लगइन द्वारा बनाई गई टेबल सहित सभी टेबल को कवर करती है।
जितनी हो सके उतनी खास स्ट्रिंग खोजें। old-domain.co.nz को बदलने से mail.old-domain.co.nz और staging.old-domain.co.nz भी फिर से लिखे जाते हैं, जो शायद ही कभी आप चाहते हैं। स्कीम शामिल करने से, जैसे https://old-domain.co.nz, मिलान सटीक रहता है।
तरीका 2: कंसोल से WP-CLI
कंसोल आपको वही इंजन देता है, लेकिन फ़्लैग पर ज़्यादा नियंत्रण के साथ। यह उन सेक्शनों में से एक है जो मैनेज्ड प्लान पर दिखाई देते हैं; दूसरे प्लान पर टैब की पट्टी में इसकी जगह +8 on Managed लिंक दिखता है।
साइट खोलें, फिर WordPress, फिर Console खोलें। प्रॉम्प्ट पहले से wp से शुरू होता है, इसलिए कमांड का केवल बाकी हिस्सा टाइप करें।
पहले प्रीव्यू करें:
search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables --dry-run
फिर इसे असल में चलाएं:
search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables
कंसोल आपके लिए बैकअप नहीं लेता। अपने आप होने वाला पहले का बैकअप तभी होता है जब आप तरीका 1 वाला Search & Replace कार्ड इस्तेमाल करते हैं। अगर आप कमांड यहाँ चलाते हैं, तो पहले साइट के बैकअप पेज से खुद बैकअप लें।
उपयोगी फ़्लैग:
| फ़्लैग | यह क्या करता है |
|---|---|
--all-tables | केवल मुख्य WordPress टेबल ही नहीं, प्लगइन द्वारा बनाई गई कस्टम टेबल भी शामिल करता है |
--dry-run | बताता है कि क्या बदलेगा और कुछ भी नहीं लिखता |
--precise | बदलाव के लिए SQL के बजाय PHP का उपयोग करता है। धीमा है, लेकिन जटिल serialised संरचनाओं को संभाल लेता है |
--skip-columns=guid | पोस्ट GUID को नहीं छूता (नीचे देखें) |
--report-changed-only | आउटपुट को केवल उन टेबल तक सीमित करता है जो वास्तव में बदलीं |
GUID के बारे में एक नोट
हर WordPress पोस्ट में एक guid कॉलम होता है। URL जैसा दिखने के बावजूद यह एक पहचानकर्ता है, लिंक नहीं, और फ़ीड रीडर इसका उपयोग यह जानने के लिए करते हैं कि उन्होंने कोई आइटम पहले देखा है या नहीं। इसे फिर से लिखने से आपकी फ़ीड की हर पोस्ट नई बनकर फिर से दिख सकती है।
GUID तब फिर से लिखें जब आप डोमेन स्थायी रूप से बदल रहे हों और नए सिरे से शुरुआत कर रहे हों। जब आप उसी डोमेन पर केवल HTTP से HTTPS पर जा रहे हों, तब --skip-columns=guid से उन्हें छोड़ दें।
डोमेन बदलना: इसके बजाय Site URL कार्ड का उपयोग करें
अगर पूरा मकसद साइट को नए डोमेन पर ले जाना है, तो सर्च और रिप्लेस से शुरुआत न करें। उसी Quick Actions सेक्शन में मौजूद Change Site URL कार्ड siteurl और home options को अपडेट करता है और एक ही प्रक्रिया में, सही क्रम में, सभी टेबल में बदलाव चलाता है। इसे उल्टे क्रम में करने से WordPress अपना एडमिन भी लोड नहीं कर पाता।
बदलाव के बाद
काम पूरा मानने से पहले इस सूची को पूरा करें।
- कैश फ़्लश करें। Quick Actions सेक्शन में Flush Cache चलाएं। अगर साइट फ़ुल पेज कैश का उपयोग करती है, तो उसे WordPress, फिर कैशिंग से purge करें।
- रीराइट नियम फ़्लश करें। उसी सेक्शन में Flush Rewrites चलाएं, या wp-admin में Settings, फिर Permalinks खोलें और कुछ भी बदले बिना Save Changes पर क्लिक करें।
- अगर साइट CDN पर है तो CDN को purge करें, प्रदर्शन, फिर Kapsule CDN से। Kapsule CDN कैश को purge करना देखें।
- साइट को प्राइवेट विंडो में लोड करें ताकि आपके ब्राउज़र का कैश आपको गुमराह न कर सके।
- पैडलॉक जांचें। SSL पर जाने के बाद पैडलॉक का न होना या चेतावनी वाला पैडलॉक बताता है कि कुछ URL छूट गए: मिश्रित सामग्री चेतावनियों को ठीक करना।
- बारीक पेजों पर क्लिक करके देखें। होम पेज के स्लाइडर, हेडर लोगो, पेज बिल्डर से बना कोई भी पेज, और स्टोर का चेकआउट। इन्हीं में वे URL होते हैं जो serialised options में रहते हैं।
- किसी भी कैशिंग प्लगइन को उसकी अपनी सेटिंग्स स्क्रीन से साफ़ करें।
समस्या निवारण
Dry run शून्य बदलाव दिखाता है। स्ट्रिंग डेटाबेस में ठीक उसी रूप में नहीं है। आखिर में स्लैश, www. उपसर्ग, या स्कीम की जांच करें। यह पुष्टि करने के लिए कि वह डेटाबेस में है भी या नहीं, पहले केवल होस्टनेम खोजकर देखें।
डोमेन बदलने के बाद इमेज टूट गई हैं। मीडिया URL wp_posts और wp_postmeta में रहते हैं और --all-tables से पकड़ में आ जाते हैं, लेकिन कोई CDN या इमेज ऑप्टिमाइज़ेशन प्लगइन अपनी खुद की बदली हुई प्रतियाँ कैश कर सकता है। CDN और प्लगइन का कैश purge करें, फिर दोबारा लोड करें।
बदलाव के बाद सेटिंग्स गायब हो गईं। यह serialisation वाली समस्या है, और इसका मतलब है कि बदलाव यहाँ बताए गए टूल के बजाय सीधे SQL से किया गया था। प्रक्रिया से पहले लिया गया बैकअप रीस्टोर करें: बैकअप से अपनी साइट रीस्टोर करना।
स्टेजिंग URL बार-बार लौट आते हैं। कोई चीज़ उन्हें फिर से भर रही है, आमतौर पर कोई शेड्यूल किया गया पुश या कैश किया गया option। स्टेजिंग का उपयोग: पुश और पुल करना में वर्कफ़्लो देखें और पक्का करें कि पुश करते समय Rewrite URLs टिक किया हुआ हो।