गुटेनबर्ग ब्लॉक डिप्रीकेशन: सामग्री को तोड़े बिना अपडेट करें

सारांश

गुटेनबर्ग ब्लॉक को अपडेट करने से अक्सर पुराने संस्करण का उपयोग करने वाले मौजूदा पोस्ट टूट जाते हैं। यह लेख आपको दिखाता है कि block.json में deprecated प्रॉपर्टी का उपयोग करके पिछड़ी संगतता कैसे बनाए रखें। आप वर्तमान ब्लॉक मार्कअप को कैप्चर करने, एक या अधिक डिप्रीकेटेड संस्करणों को परिभाषित करने और विशेषताओं को सही ढंग से मैप करने के सटीक चरण सीखेंगे। हम स्थिर और गतिशील दोनों ब्लॉकों को व्यावहारिक उदाहरणों के साथ कवर करेंगे। लेख इस धारणा को भी चुनौती देता है कि डिप्रीकेशन हमेशा सबसे अच्छा दृष्टिकोण है, और चर्चा करता है कि कब एक स्वच्छ ब्रेक बेहतर हो सकता है। अंत तक, आप अपने उपयोगकर्ताओं की सामग्री को तोड़े बिना आत्मविश्वास से अपने ब्लॉक अपडेट कर पाएंगे।

ब्रेकिंग चेंज परिदृश्य

आपने छह महीने पहले एक कस्टम प्रशंसापत्र ब्लॉक लॉन्च किया था। यह एक उद्धरण और लेखक के नाम के साथ एक साधारण <div> आउटपुट करता है। अब आपके क्लाइंट को एक नया डिज़ाइन चाहिए: लेखक उद्धरण के ऊपर दिखाई देना चाहिए, एक अलग CSS क्लास के साथ। आप ब्लॉक के save फ़ंक्शन और render_callback को अपडेट करते हैं। आप एक नई पोस्ट पर परीक्षण करते हैं—यह बहुत अच्छा लगता है। फिर आप एक पुरानी पोस्ट पर जाते हैं जो ब्लॉक का उपयोग करती है। आपदा: उद्धरण पाठ गायब है, लेखक गलत जगह पर है, और स्टाइलिंग गड़बड़ है। आपने अभी-अभी ब्लॉक का उपयोग करने वाले हर पेज को तोड़ दिया है।

यह गुटेनबर्ग ब्लॉक विकास में क्लासिक "ब्रेकिंग चेंज" समस्या है। ब्लॉक मूल रूप से मार्कअप के साथ संयुक्त डेटा संरचनाएं हैं। जब आप मार्कअप बदलते हैं, तो संपादक स्वचालित रूप से पुरानी सामग्री को नई संरचना में मैप नहीं कर सकता। परिणाम या तो एक सत्यापन त्रुटि है (ब्लॉक अमान्य हो जाता है) या—इससे भी बदतर—मूक भ्रष्टाचार जहां ब्लॉक गलत तरीके से रेंडर होता है।

ब्लॉक डिप्रीकेशन क्या है?

ब्लॉक डिप्रीकेशन गुटेनबर्ग का संस्करण परिवर्तनों को संभालने के लिए अंतर्निहित तंत्र है। अपने ब्लॉक के block.json में एक deprecated ऐरे परिभाषित करके, आप संपादक को बताते हैं: "यदि आप एक ऐसा ब्लॉक पाते हैं जो इन पुराने संस्करणों में से एक से मेल खाता है, तो इसे वर्तमान संस्करण में बदल दें।" प्रत्येक डिप्रीकेटेड एंट्री पिछले attributes, supports, और save फ़ंक्शन (या render_callback) निर्दिष्ट करती है। जब संपादक एक पुराना ब्लॉक लोड करता है, तो वह डिप्रीकेटेड ऐरे के माध्यम से क्रम में चलता है और पहले मिलने वाले परिवर्तन को लागू करता है।

यह सुविधा अक्सर कम उपयोग की जाती है क्योंकि डेवलपर्स मानते हैं कि उन्हें कभी भी ब्लॉक के मार्कअप को बदलने की आवश्यकता नहीं होगी। लेकिन वास्तविक दुनिया की परियोजनाओं में, आवश्यकताएं विकसित होती हैं। यदि आप डिप्रीकेशन छोड़ते हैं, तो आप या तो उपयोगकर्ताओं को ब्लॉक को हटाने और पुनः सम्मिलित करने के लिए मजबूर करते हैं (खराब अनुभव) या ब्लॉक के दो अलग-अलग संस्करण बनाए रखते हैं (गड़बड़)। आधिकारिक वर्डप्रेस डेवलपर हैंडबुक इसे ब्लॉक एडिटर हैंडबुक में कवर करता है, लेकिन व्यावहारिक वॉकथ्रू की कमी है।

चरण 1: वर्तमान स्थिति को कैप्चर करें

कोई भी बदलाव करने से पहले, सटीक save आउटपुट (या गतिशील ब्लॉक के लिए render_callback) और आपके ब्लॉक वर्तमान में उपयोग कर रहे attributes को रिकॉर्ड करें। इसे एक स्नैपशॉट लेने के रूप में सोचें। स्थिर ब्लॉक के लिए, save फ़ंक्शन द्वारा लौटाए गए JSX को सहेजें। गतिशील ब्लॉक के लिए, render_callback द्वारा उत्पन्न PHP मार्कअप को सहेजें।

अपने प्लगइन में deprecated.js (या इसी तरह) नामक एक नई फ़ाइल बनाएं और पुराने save फ़ंक्शन को वहां स्टोर करें। वैकल्पिक रूप से, डिप्रीकेटेड संस्करणों को सीधे ब्लॉक की मुख्य जावास्क्रिप्ट फ़ाइल में रखें। कुंजी इस कोड को बिल्कुल वैसे ही संरक्षित करना है जैसे यह ब्लॉक की पहली तैनाती के समय था।

चरण 2: अपने डिप्रीकेटेड संस्करणों को परिभाषित करें

अपने block.json में, एक deprecated ऐरे जोड़ें। प्रत्येक एंट्री एक ऑब्जेक्ट है जिसमें शामिल हो सकता है:

• attributes (ऑब्जेक्ट): पिछली विशेषता परिभाषाएं।
• supports (ऑब्जेक्ट): कोई भी पिछला समर्थन सेटिंग जो बदल गया।
• save (फ़ंक्शन या स्ट्रिंग): पिछला सेव फ़ंक्शन। केवल जावास्क्रिप्ट ब्लॉक के लिए, आप पुराने फ़ंक्शन को आयात करेंगे। PHP-रेंडर किए गए गतिशील ब्लॉक के लिए, आप इसके बजाय migrate और render_callback का उपयोग कर सकते हैं।
• migrate (फ़ंक्शन): एक फ़ंक्शन जो पुरानी विशेषताओं को नई में मैप करता है (वैकल्पिक)।

उदाहरण:

"deprecated": [
  {
    "attributes": {
      "quote": { "type": "string", "source": "html", "selector": ".quote" },
      "author": { "type": "string", "source": "html", "selector": ".author" }
    },
    "supports": {},
    "save": "() => <div className=\"testimonial-legacy\"><p className=\"quote\">{attributes.quote}</p><p className=\"author\">{attributes.author}</p></div>"
  }
]

नोट: block.json में save फ़ंक्शन आमतौर पर जावास्क्रिप्ट में परिभाषित किया जाता है। यदि आप एक बाहरी स्क्रिप्ट का उपयोग कर रहे हैं, तो आपको इसे एनक्यू करना होगा और फ़ंक्शन नाम का संदर्भ देना होगा। वैकल्पिक रूप से, आप फ़ंक्शन को एक स्ट्रिंग के रूप में इनलाइन कर सकते हैं (हालांकि जटिल ब्लॉक के लिए इसकी अनुशंसा नहीं की जाती है)।

चरण 3: विशेषताओं को मैप करें

अक्सर, आप न केवल मार्कअप बल्कि विशेषता नाम या स्रोत भी बदलते हैं। उदाहरण के लिए, आप लेखक को एक सादे स्ट्रिंग के रूप में संग्रहीत करने से एक रिच टेक्स्ट फ़ील्ड में स्विच कर सकते हैं। ऐसे मामलों में, पुरानी विशेषताओं को नई में बदलने के लिए migrate प्रॉपर्टी का उपयोग करें।

migrate: (attributes) => {
  return {
    quote: attributes.quote,
    author: { content: attributes.author, level: 2 }
  };
}

यदि आप migrate फ़ंक्शन प्रदान नहीं करते हैं, तो संपादक केवल पुरानी विशेषताओं को सीधे नए ब्लॉक में पास करेगा। यदि विशेषता नाम बदल गए हैं तो इससे त्रुटियां हो सकती हैं।

चरण 4: वास्तविक सामग्री के साथ परीक्षण करें

डिप्रीकेटेड संस्करण को परिभाषित करने के बाद, अच्छी तरह से परीक्षण करें। एक नई पोस्ट बनाएं, पुराने ब्लॉक को सम्मिलित करें (आप किसी मौजूदा पोस्ट से सीरियलाइज़्ड ब्लॉक कोड चिपकाकर अनुकरण कर सकते हैं), और सत्यापित करें कि यह बिना सत्यापन त्रुटियों के नए संस्करण में परिवर्तित होता है। परिवर्तित ब्लॉक को संपादित और सहेजने का भी परीक्षण करें। यदि आपके पास कई डिप्रीकेटेड संस्करण हैं तो दोहराएं।

डायनामिक ब्लॉक के लिए, प्रक्रिया समान है लेकिन एक मोड़ के साथ: एक डायनामिक ब्लॉक के लिए save फ़ंक्शन आमतौर पर null लौटाता है (ब्लॉक PHP के माध्यम से रेंडर होता है)। डिप्रीकेटेड एंट्री में, आप या तो save को पिछले स्थिर मार्कअप पर सेट कर सकते हैं जो डायनामिक रेंडरिंग पर स्विच करने से पहले उपयोग किया गया था, या PHP में एक render_callback का उपयोग कर सकते हैं जो पुरानी और नई दोनों विशेषता संरचनाओं को संभालता है। यह अधिक जटिल है लेकिन संभव है।

चेतावनियां और ट्रेड-ऑफ

डिप्रीकेशन शक्तिशाली है, लेकिन इसकी कमियां हैं। प्रत्येक डिप्रीकेटेड संस्करण आपके प्लगइन में कोड जोड़ता है। समय के साथ, आप पांच या छह विरासत संस्करणों की एक श्रृंखला के साथ समाप्त हो सकते हैं जो शायद ही कभी उपयोग किए जाते हैं लेकिन बनाए रखा जाना चाहिए। वर्डप्रेस कोर टीम कम से कम दो संस्करण पीछे रखने की सिफारिश करती है, लेकिन उससे परे, यदि प्रभावित पोस्ट की संख्या कम है तो आप एक स्वच्छ ब्रेक पर विचार कर सकते हैं।

एक और बारीकी: डिप्रीकेटेड एंट्री का क्रम मायने रखता है। संपादक ऐरे के माध्यम से इंडेक्स 0 से ऊपर की ओर पुनरावृति करता है और पहले मिलान का उपयोग करता है। यदि दो डिप्रीकेटेड संस्करण समान हैं, तो गलत लागू हो सकता है। हमेशा सबसे हाल के डिप्रीकेटेड संस्करण को पहले सूचीबद्ध करें (जो वर्तमान संस्करण से ठीक पहले आता है)।

अंत में, डिप्रीकेशन उस सामग्री को संभाल नहीं करता है जिसे साइट-व्यापी शैली परिवर्तन (जैसे, theme.json के माध्यम से) का उपयोग करके संपादित किया गया था। यदि आपके ब्लॉक की उपस्थिति वैश्विक शैलियों पर निर्भर करती है जो तब से बदल गई हैं, तो डिप्रीकेशन उसके लिए समायोजित नहीं होगा। आपको एक माइग्रेशन स्क्रिप्ट जोड़ने की आवश्यकता हो सकती है जो सेव पर या प्लगइन अपडेट हुक के माध्यम से चलती है।

जब डिप्रीकेशन उत्तर नहीं है

अधिकांश ट्यूटोरियल डिप्रीकेशन को अनिवार्य बताते हैं। वास्तव में, ऐसी स्थितियां हैं जहां एक स्वच्छ ब्रेक बेहतर है। यदि आपका ब्लॉक नया है और केवल कुछ पोस्ट में उपयोग किया जाता है, तो उन कुछ उदाहरणों को मैन्युअल रूप से अपडेट करना डिप्रीकेशन कोड लिखने और परीक्षण करने से तेज हो सकता है। इसी तरह, यदि ब्लॉक का अंतर्निहित डेटा मॉडल मौलिक रूप से अलग है (उदाहरण के लिए, आप दो ब्लॉक को एक में मर्ज कर रहे हैं), तो डिप्रीकेशन पर्याप्त लचीला नहीं हो सकता है। उस स्थिति में, एक बार का माइग्रेशन स्क्रिप्ट लिखें जो प्लगइन अपडेट होने पर चलती है, पुराने ब्लॉक को नए प्रारूप में परिवर्तित करती है।

एक और विपरीत बिंदु: डिप्रीकेशन का उपयोग अच्छे डिज़ाइन के विकल्प के रूप में नहीं किया जाना चाहिए। यदि आप बार-बार बदलाव की उम्मीद करते हैं, तो अपने ब्लॉक को शुरू से वर्जनिंग को ध्यान में रखकर डिज़ाइन करें—उदाहरण के लिए, एक version विशेषता संग्रहीत करके और सशर्त रेंडरिंग का उपयोग करके। यह दृष्टिकोण, बियॉन्ड बेसिक ब्लॉक्स में चर्चा की गई है, डिप्रीकेशन से हल्का है लेकिन दूरदर्शिता की आवश्यकता है।

निष्कर्ष

ब्लॉक डिप्रीकेशन किसी भी गंभीर गुटेनबर्ग डेवलपर के लिए एक आवश्यक उपकरण है। यह आपको उपयोगकर्ताओं की सामग्री को तोड़े बिना अपने ब्लॉक को विकसित करने की अनुमति देता है। मुख्य कदम हैं: वर्तमान स्थिति को कैप्चर करें, block.json में डिप्रीकेटेड संस्करण को परिभाषित करें, यदि आवश्यक हो तो विशेषताओं को मैप करें, और वास्तविक सामग्री के साथ परीक्षण करें। लेकिन याद रखें कि डिप्रीकेशन रखरखाव लागत के साथ आता है। कभी-कभी एक स्वच्छ ब्रेक या एक वर्जनित ब्लॉक डिज़ाइन अधिक व्यावहारिक होता है। डिप्रीकेशन का रणनीतिक रूप से उपयोग करें, स्वचालित रूप से नहीं, और आपके ब्लॉक कई अपडेट के माध्यम से मजबूत रहेंगे।

रखरखाव योग्य प्लगइन बनाने पर व्यापक परिप्रेक्ष्य के लिए, बिल्डिंग रोबस्ट वर्डप्रेस प्लगइन्स देखें। और यदि आप ब्लॉक विकास में नए हैं, तो बियॉन्ड बेसिक ब्लॉक्स आपको शुरू करने में मदद करेगा।