हर WordPress साइट को फिर से बनाना बंद करें

सारांश

अधिकांश एजेंसियाँ हर WordPress साइट को एक खाली थीम से बनाती हैं, जबकि एक साझा नींव शेड्यूल से हफ्तों का समय काट सकती है। यह लेख तर्क देता है कि theme.json, ब्लॉक पैटर्न और डायनामिक ब्लॉक आपको संरचनात्मक परत को मानकीकृत करने की सुविधा देते हैं, साथ ही प्रत्येक क्लाइंट के विशिष्ट डिज़ाइन को संरक्षित रखते हैं। यह उन पाँच आपत्तियों को सीधे संबोधित करता है जो टीमों को बदलने से रोकती हैं: 'हमारे अलग-अलग क्लाइंट हैं', 'कस्टम ब्लॉक महंगे हैं', 'एडिटर भ्रामक है', 'हम अपने हुक और फ़िल्टर खो देंगे', और 'FSE प्रोडक्शन-रेडी नहीं है'। प्रत्येक आपत्ति को एक व्यावहारिक प्रति-तर्क और एक ठोस पैटर्न मिलता है जिसे आप चरणबद्ध रूप से अपना सकते हैं। लाभ एक दोहराने योग्य निर्माण प्रक्रिया है जो अभी भी बेस्पोक कार्य का सम्मान करती है जहाँ वह उपयुक्त है। चेतावनी: किसी एक-क्लिक रीसेट बटन का वादा नहीं किया गया है।

आपकी कितनी क्लाइंट साइटें कोड की एक पंक्ति भी साझा करती हैं? कॉपीराइट लाइन नहीं—असली कोड। यदि उत्तर 'शायद ही कुछ' है, तो आप पहले ही दर्द महसूस कर चुके हैं: वही हीरो सेक्शन नौवीं बार फिर से बनाया गया, वही टीम-ग्रिड मार्कअप एक प्रोजेक्ट से दूसरे में कॉपी किया गया, वही प्रीप्रोसेस ट्वीक्स आधे दर्जन थीम्स में क्रॉस-रेफरेंस किए गए। आपने बचाव भी सुना है: 'हर क्लाइंट की ज़रूरतें अलग होती हैं।' सच है। लेकिन हर कोई जो निष्कर्ष निकालता है—कि हर साइट को एक बेस्पोक नींव की आवश्यकता होती है—गलत है। WordPress इकोसिस्टम अब आपको डिज़ाइन को मानकीकृत किए बिना संरचनात्मक टुकड़ों को मानकीकृत करने का एक तरीका देता है: design tokens के लिए theme.json, दोहराए जाने वाले लेआउट के लिए ब्लॉक पैटर्न, और उन कुछ सुविधाओं के लिए डायनामिक ब्लॉक जिन्हें वास्तविक सर्वर-साइड लॉजिक की आवश्यकता होती है। यह लेख उन आपत्तियों के बारे में है जो एजेंसियों को वह कदम उठाने से रोकती हैं, और जब आप उनके खिलाफ़ पुश बैक करते हैं तो वास्तव में क्या काम करता है।

'लेकिन हर क्लाइंट अलग है' आपत्ति

अंतर्निहित सिद्धांत: नींव को मानकीकृत करें, सतह को नहीं। संरचना को साझा लाइब्रेरी में रखने का कारण ठीक यही है कि दृश्य परत को स्वतंत्र छोड़ा जाए। theme.json फ़ाइल कोई डिज़ाइन नहीं है—यह design tokens का एक सेट है। रंग, स्पेसिंग और टाइपोग्राफी मान हैं, मार्कअप नहीं। यह महत्वपूर्ण बदलाव है: आप मार्कअप साझा कर सकते हैं जबकि एक प्रति-साइट theme.json साइट को किसी भिन्न ब्रांड के लिए पूरी तरह से अलग दिखाता है।

दो क्लाइंट लें: एक कानूनी फर्म और एक आउटडोर रिटेलर। उनकी डिज़ाइन भाषाएँ बहुत अलग हैं। लेकिन दोनों को एक हीरो सेक्शन, एक टेस्टिमोनियल ग्रिड, एक कॉल-टू-एक्शन बैंड की आवश्यकता है। हर एक के लिए मार्कअप फिर से बनाने के बजाय, तीन ब्लॉक पैटर्न बनाए रखें और प्रत्येक क्लाइंट के theme.json को रंग, फ़ॉन्ट और स्पेसिंग परिभाषित करने दें। संरचना समान रहती है; design tokens इसे एक ब्रांड से दूसरे में बदल देते हैं। जब रिटेलर अगली वसंत में अपना रंग पैलेट बदलता है, तो आप उनकी साइट पर एक फ़ाइल संपादित करते हैं—छह टेम्पलेट्स में मार्कअप नहीं।

व्यावहारिक रूप से, इसका मतलब है कि आपकी टीम पैटर्न को कोड के रूप में बनाती है, उन्हें एक साझा प्लगइन में पंजीकृत करती है, और प्रत्येक क्लाइंट साइट पर theme.json को पेंट संभालने देती है। पैटर्न के क्लास नाम आपकी वास्तुकला बन जाते हैं; मान चर बन जाते हैं। आप आगे जाकर theme.json को पोस्ट प्रकार या प्लगइन आउटपुट के लिए कस्टम सेटिंग्स शामिल करने के लिए विस्तारित कर सकते हैं, हालाँकि किसी बिंदु पर आप साइट के बजाय एक कॉन्फ़िगरेशन इंटरफ़ेस बना रहे होते हैं—एक जाल जिसकी चर्चा theme.json को विस्तारित करने पर हमारी नज़र में की गई है। साझा परत को दुबला रखें: इसमें केवल वही होना चाहिए जो क्लाइंट्स के बीच दोहराया जाता है। जिस क्षण आप 'यदि किसी दिन किसी को यह चाहिए' के लिए एक सेटिंग जोड़ते हुए पाते हैं, आपने एक अमूर्तता बना ली है जिसे बनाए रखने में जितनी बचत होगी उससे अधिक लागत आएगी।

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

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

अब, वह चेतावनी जिस पर मैं बार-बार लौटता हूँ: अति-केंद्रीकरण न करें। एक theme.json जिसमें हर संभावित बारीकी के लिए सेटिंग हो, एक रखरखाव दलदल है। साझा पैटर्न ओपिनियनेटेड होने चाहिए, सर्वशक्तिमान नहीं। यदि किसी क्लाइंट को पूरी तरह से अलग लेआउट चाहिए—जैसे कि एक बड़े फीचर्ड ग्रिड के साथ मैगज़ीन होमपेज—तो वे आपकी मानक पैटर्न लाइब्रेरी में फिट नहीं हो सकते। यह ठीक है। मानकीकरण का मतलब है कि आप 80% समान परियोजनाओं पर जीतते हैं, यह नहीं कि आप हर साइट को उसी सांचे में ढालें।

'कस्टम ब्लॉक बजट उड़ा देते हैं' आपत्ति

यहाँ एक प्रति-सिद्धांत है जो उबाऊ लगता है लेकिन पैसे बचाता है: अधिकांश चीज़ें जिनके लिए आपको लगता है कि कस्टम ब्लॉक की आवश्यकता है, वास्तव में नहीं होती। कोर ब्लॉक और एक पैटर्न अधिकांश लेआउट को कवर कर सकते हैं। कस्टम ब्लॉक अंतिम उपाय है, पहला इरादा नहीं।

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

एक अधिक कपटी परिदृश्य: क्लाइंट 'केस स्टडी कैरोसेल' माँगता है। पहली प्रवृत्ति यह सोचने की होती है, 'मुझे एक कैरोसेल ब्लॉक चाहिए।' लेकिन क्या उन्हें कैरोसेल चाहिए? शायद उन्हें पोस्ट का एक क्षैतिज रूप से स्क्रॉल करने योग्य समूह चाहिए, जिसे कोर ब्लॉक 'group' ब्लॉक और कुछ CSS के साथ संभाल सकते हैं। या शायद उन्हें हाल के केस स्टडीज़ की एक डायनामिक सूची चाहिए, जो CPT को क्वेरी करने वाला एक डायनामिक ब्लॉक है। सवाल यह नहीं है कि 'क्लाइंट क्या सुविधा चाहता है?' बल्कि 'यह किस डेटा पर निर्भर करता है?' यदि डेटा स्थिर है और क्लाइंट द्वारा संपादित किया जा सकता है, तो एक पैटर्न पर्याप्त होगा। यदि डेटा डेटाबेस क्वेरी से आता है, तो एक डायनामिक ब्लॉक उचित है। यदि डेटा को API से वास्तविक समय में अपडेट करने की आवश्यकता है, तो आप इसके बजाय REST API एकीकरण देख रहे होंगे—यह एक अलग तरह के निर्माण में जाता है।

जब आप वास्तव में एक ब्लॉक बनाते हैं, तो block.json आपका मित्र है। यह विशेषताओं, स्क्रिप्ट्स और स्टाइल्स के लिए सत्य का एकमात्र स्रोत है, जो ब्लॉक को परियोजनाओं में पोर्टेबल बनाता है। यह आपको निर्भरताओं और अनुवादों को स्पष्ट रूप से घोषित करने की भी सुविधा देता है, जो कई क्लाइंट साइटों पर एक लाइब्रेरी वितरित करते समय आवश्यक है। लाइव डेटा पर निर्भर सामग्री के लिए, एक डायनामिक ब्लॉक सर्वर पर रेंडर होता है, इसलिए आपको प्रत्येक पेज व्यू पर JavaScript बंडल भेजने की आवश्यकता नहीं होती। और यदि आपका ब्लॉक विकसित होता है, तो आप deprecations को सुचारू रूप से संभाल सकते हैं ताकि मौजूदा सामग्री टूट न जाए—हमारी ब्लॉक deprecation गाइड इस सटीक पैटर्न पर चलती है।

कुछ भी बनाने से पहले, इस निर्णय को इस ग्रिड से गुज़ारें:

दृष्टिकोण	किसके लिए सर्वोत्तम	कब टालें
कोर ब्लॉक	एक बार की सामग्री, सरल पेज	लेआउट कई क्लाइंट्स में दोहराया जाता है और समृद्ध विकल्पों की आवश्यकता होती है
ब्लॉक पैटर्न	बिना लॉजिक के दोहराने योग्य लेआउट	लेआउट को शर्तों, डायनामिक डेटा या जटिल इंटरैक्शन की आवश्यकता होती है
कस्टम ब्लॉक	दोहराया गया, डेटा-संचालित, या अत्यधिक विशिष्ट व्यवहार	एकमात्र कारण एक बार का सेक्शन है जिसे एक क्लास के साथ संभाला जा सकता है

आप पहले दिन से ब्लॉक नामकरण के बारे में भी सोचना चाहेंगे। एक ब्लॉक नाम अनिवार्य रूप से आपकी सामग्री के साथ एक अनुबंध है। यदि आप इसे wagent/team-grid कहते हैं और बाद में इसका नाम बदलकर wagent/team-carousel करते हैं, तो आप मौजूदा सामग्री को तोड़ देंगे जब तक कि आप एक deprecation पथ प्रदान नहीं करते। सामान्य, उद्देश्य-आधारित नाम चुनें जो ब्लॉक के विकसित होने पर गलत विज्ञापन न बनें। यह नामकरण अनुशासन का एक स्वाद है जो हम सभी ने प्लगइन उपसर्गों से सीखा है, और यह ब्लॉक नामों पर उतना ही लागू होता है।

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

'क्लाइंट एडिटर तोड़ देंगे' आपत्ति

यह आपत्ति आधी सही है। ब्लॉक एडिटर स्वयं समस्या नहीं है; समस्या क्लाइंट्स को बहुत अधिक छूट देना है। theme.json यह नियंत्रित कर सकता है कि क्या संपादन योग्य है: टेम्पलेट एडिटर अक्षम करें, अनुमत ब्लॉक प्रतिबंधित करें, और डिफ़ॉल्ट स्टाइल सेट करें ताकि एक गलत जगह रखा गया कॉलम कम नुकसान करे। कुछ क्लाइंट फिर भी चीज़ें तोड़ने में सफल होंगे, लेकिन आप एक क्लिक में पेज को सहेजे गए पैटर्न पर वापस ला सकते हैं—कुछ ऐसा जो क्लासिक एडिटर नहीं दे सकता था।

मुझे एक परिदृश्य चित्रित करने दें। एक क्लाइंट कॉल करता है और कहता है, 'मैंने एक सेक्शन को स्थानांतरित किया और अब पूरा पेज गलत दिखता है।' क्लासिक थीम के साथ, आप लॉग इन करेंगे, CSS का निरीक्षण करेंगे, और शायद लेआउट को ठीक करने में एक घंटा बिताएँगे। ब्लॉक सेटअप के साथ, आप पेज खोल सकते हैं, सामग्री क्षेत्र का चयन कर सकते हैं, और इसे सहेजे गए पैटर्न पर रीसेट कर सकते हैं। पैटर्न आधार रेखा है; क्लाइंट के परिवर्तन ओवरले हैं। जब ओवरले गलत हो जाता है, तो आप उसे हटा देते हैं। यह केवल एक बेहतर वर्कफ़्लो नहीं है; यह एक मौलिक रूप से अधिक क्षमाशील एडिटर है।

अब सूक्ष्मता: अधिकांश क्लाइंट बिल्कुल भी अधिक संपादन नहीं करना चाहते। वे पाठ बदलना चाहते हैं, फ़ोटो बदलना चाहते हैं, और शायद एक सेक्शन को पुनः क्रमबद्ध करना चाहते हैं। ब्लॉक पैटर्न आपको पूरी साइट संरचना को उजागर किए बिना ठीक वही देता है। इस अर्थ में, एडिटर एक खिलौना नहीं है; यह एक व्यूफ़ाइंडर है। आपका काम यह अंशांकित करना है कि क्लाइंट क्या देख सकते हैं। इसका मतलब है कि आप 'Templates' सेटिंग्स अक्षम कर सकते हैं, ब्लॉक इन्सर्टर को एक क्यूरेटेड सूची तक सीमित कर सकते हैं, और यहाँ तक कि खाली पैटर्न को प्लेसहोल्डर कार्य के साथ पहले से भर सकते हैं। एडिटर एक वेब डिज़ाइन कैनवास के बजाय एक सामग्री प्रविष्टि फ़ॉर्म बन जाता है।

पहुँच पक्ष पर, ब्लॉक एडिटर का फ़ोकस प्रबंधन और कीबोर्ड समर्थन आम तौर पर क्लासिक एडिटर के टेम्पलेट फ़ील्ड से बेहतर होता है। लेकिन आपको अभी भी यह सुनिश्चित करने की आवश्यकता है कि पैटर्न में उचित शीर्षक पदानुक्रम और सुलभ नाम हों। चूँकि पैटर्न क्लाइंट्स के बीच साझा है, आप उन मुद्दों को केवल एक बार ठीक करते हैं, जो मानकीकरण का एक और छिपा हुआ लाभ है।

वास्तव में कठिन हिस्सा आंतरिक है। आपकी टीम के लिए, ब्लॉकों के साथ प्रोटोटाइप करना सीखने के लिए 'PHP में करें' की आदत को भूलना आवश्यक है। यह एक वास्तविक लागत है, लेकिन यह प्रति व्यक्ति एक बार की लागत है। यह दृष्टिकोण से बचने का कारण नहीं है; यह हर जगह रोल आउट करने से पहले एक पैटर्न लाइब्रेरी और एक क्षमाशील क्लाइंट के साथ शुरू करने का कारण है। 'मेरे क्लाइंट ब्लॉक संभाल नहीं सकते' की पुनरावृत्ति को इस तथ्य को छिपाने न दें कि आपने अभी तक उन्हें आधे रास्ते में मिलने के लिए एक ब्लॉक सेटअप कॉन्फ़िगर नहीं किया है।

'हमारे पास पहले से हुक और फ़िल्टर हैं' आपत्ति

यहाँ सिद्धांत यह है: आप हुक को त्याग नहीं रहे हैं; आप शीर्ष पर एक परत जोड़ रहे हैं। ब्लॉक प्रस्तुति की सीमा हैं; हुक अभी भी वही हैं जिनसे आप लॉजिक इंजेक्ट करते हैं। एक डायनामिक ब्लॉक का रेंडर कॉलबैक PHP में चलता है, जिसका अर्थ है कि आप उन्हीं फ़ंक्शन को कॉल कर सकते हैं और उन्हीं फ़िल्टर को लागू कर सकते हैं जिन पर आप पहले से भरोसा करते हैं।

एक प्लगइन की कल्पना करें जो आपको किसी भी पोस्ट में एक फ़िल्टर का उपयोग करके 'फ़ीचर्ड प्रोडक्ट' फ़ील्ड जोड़ने की सुविधा देता है। एक डायनामिक ब्लॉक के साथ, आप एक सर्वर-रेंडर ब्लॉक शामिल कर सकते हैं जो उस फ़िल्टर को चलाता है और आउटपुट को ब्लॉक के रैपर के अंदर प्रिंट करता है। क्लाइंट ब्लॉक सम्मिलित करता है; मौजूदा PHP लॉजिक भारी काम करता है। कुछ भी फेंका नहीं जाता। एक और ठोस उदाहरण के लिए, एक कस्टम ब्लॉक पर विचार करें जो हाल के प्रोजेक्ट पोस्ट की सूची दिखाता है। इसके रेंडर कॉलबैक में, आप get_posts() कॉल करते हैं, फिर लूप करते हैं और the_title() और the_permalink() लागू करते हैं—वही टेम्पलेट टैग जो आप वर्षों से उपयोग कर रहे हैं।

यह वह स्थान भी है जहाँ इस बारे में ईमानदार होना चाहिए कि क्या अनुवाद नहीं होता। कुछ चतुर पुराने थीम template-parts का उपयोग करते हैं जिनमें पेज संदर्भ के आधार पर तर्क लेने वाली जटिल शर्तें होती हैं। इसे एक ब्लॉक के रूप में फिर से बनाना गड़बड़ हो सकता है। लेकिन आपको इसे एक साथ फिर से बनाने की आवश्यकता नहीं है। वृद्धिशील पथ यह है कि PHP लॉजिक रखें, इसे एक डायनामिक ब्लॉक में लपेटें, और मार्कअप को ब्लॉक टेम्पलेट में ले जाएँ। आप अक्सर पाएंगे कि आपके मौजूदा फ़िल्टर पैटर्न नए आउटपुट को संभाल सकते हैं। और यदि लॉजिक टेम्पलेट पदानुक्रम से कसकर जुड़ा हुआ है (जैसे, 'खोज परिणामों पर, इसे अलग दिखाएं'), तो आप उन विशिष्ट दृश्यों के लिए क्लासिक टेम्पलेट का उपयोग कर सकते हैं जबकि नियमित पेजों के लिए ब्लॉक का उपयोग कर सकते हैं।

REST API एक अलग दरवाजा भी खोलता है: आप ऐसे ब्लॉक बना सकते हैं जो अन्य WordPress साइटों या तृतीय-पक्ष सेवाओं से डेटा खींचते हैं। एक डायनामिक ब्लॉक JSON लाने और उसे फ्रंट-एंड पर रेंडर करने के लिए wp_remote_get() कॉल कर सकता है। यह एजेंसी बिल्ड के लिए एक शक्तिशाली पैटर्न है जहाँ क्लाइंट एक अलग एकीकरण प्रबंधित किए बिना सोशल फ़ीड, उत्पाद सूची या आंतरिक डेटा दिखाना चाहते हैं। ट्रेडऑफ़ कैशिंग और त्रुटि प्रबंधन है—यदि रिमोट API धीमा है, तो आपका पेज धीमा है। API-आधारित ब्लॉक को महत्वपूर्ण above-the-fold सामग्री से बाहर रखें, या उचित लोडिंग स्थिति के साथ क्लाइंट-साइड रेंडरिंग का उपयोग करें।

सहेजने और रेंडरिंग के दौरान Actions और filters अभी भी चलते हैं; हुक वास्तुकला गायब नहीं होती जब आप ब्लॉक अपनाते हैं, यह केवल एक नए संदर्भ में चली जाती है। यदि आपको यह समझने में ताज़गी चाहिए कि actions और filters इस नए ब्लॉक दुनिया से कहाँ मिलते हैं, तो हमारा हुक डीप डाइव एक उपयोगी पुनश्चर्या है।

'FSE प्रोडक्शन-रेडी नहीं है' आपत्ति

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

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

किसी क्लाइंट को ब्लॉक थीम प्रस्तावित करने से पहले, एक त्वरित चेकलिस्ट देखें:

• क्या क्लाइंट के पास एक भारी कस्टमाइज़्ड थीम है जिसके लिए माइग्रेशन की आवश्यकता होगी?
• क्या अनिवार्य प्लगइन साइट एडिटर और REST API का समर्थन करते हैं?
• क्या होस्टिंग वातावरण उस फ़ाइल एक्सेस की अनुमति देता है जिसकी ब्लॉक थीम अपेक्षा करती है?
• क्या आपने पैटर्न डिज़ाइन के लिए समय अलग रखा है, न कि केवल ब्लॉक पंजीकरण?
• क्या क्लाइंट की टीम एडिटर परिवर्तनों को सहन करेगी, या उन्हें एक लॉक किया हुआ टेम्पलेट चाहिए?

यदि कोई उत्तर नहीं है, तो दायरे को समायोजित करें या एक हाइब्रिड दृष्टिकोण का उपयोग करें। यह एक समझौता नहीं है; यह इंजीनियरिंग निर्णय है। और यदि आप एक हाइब्रिड बना रहे हैं, तो ऊपर की हुक और फ़िल्टर कहानी याद रखें—आप अभी भी पुराने लॉजिक को डायनामिक ब्लॉक में लपेट सकते हैं जबकि theme.json वैश्विक रूप को संभालता है।

अपने theme.json का संस्करणन केवल एक सैद्धांतिक चिंता नहीं है। मैंने देखा है कि एक एजेंसी की कस्टम ब्लॉक लाइब्रेरी टूट गई जब क्लाइंट ने WordPress अपडेट किया और ब्लॉक की style फ़ाइल wp_register_style() के साथ बदले हुए हैंडल के तहत पंजीकृत थी। समाधान आसान था, लेकिन घबराहट वास्तविक थी। एक सरल परीक्षण प्रक्रिया—साइट की स्टेजिंग कॉपी पर अपडेट चलाएँ, प्रमुख पृष्ठों पर क्लिक करें, फिर रिलीज़ करें—अधिकांश ऐसे आश्चर्यों को हल कर देती है।

वह आपत्ति जो आपने स्वयं से नहीं की

यहाँ वह मेटा-आपत्ति है जो एजेंसियों को मानकीकरण से रोकती है: 'यह एक बड़ा बदलाव है, और क्लाइंट कार्य के दौरान इसे करने का समय नहीं है।' यह सच है—इसलिए इसे क्लाइंट कार्य के दौरान न करें। एक आंतरिक प्रोजेक्ट या एक छोटे क्लाइंट को चुनें और एक पैटर्न लाइब्रेरी बनाएं। theme.json का उपयोग design-token सिस्टम के रूप में करें। केवल तभी कस्टम ब्लॉक जोड़ें जब यह उचित हो। पुराने हुक को लपेटें जहाँ वे मदद करते हैं। पुनरावृत्ति करें।

पहले 30 दिनों के लिए एक मोटा रोडमैप यहाँ है:

1. अपने पिछले पाँच क्लाइंट बिल्ड का ऑडिट करें और सबसे अधिक दोहराए गए दस लेआउट टुकड़ों की सूची बनाएं।
2. उन दस टुकड़ों को CSS क्लासों के एक छोटे सेट के साथ ब्लॉक पैटर्न में बदलें।
3. एक साझा प्लगइन (या mu-plugin) बनाएं जो उन पैटर्न को पंजीकृत करे। यदि आपने इसके लिए प्लगइन संगठन के बारे में नहीं सोचा है, तो पहले मजबूत प्लगइन बनाने पर यह मार्गदर्शिका देखें।
4. एक theme.json बनाएं जो आपकी आधार रेखा डिज़ाइन से मेल खाता है; प्रोजेक्ट शुरू करते समय क्लाइंट-विशिष्ट मान जोड़ें।
5. एक छोटा आंतरिक प्रोजेक्ट या एक मित्रवत क्लाइंट चुनें और उसे स्टैक पर माइग्रेट करें।
6. एक ग्राहक की हीरो कहानी का दस्तावेजीकरण करें जिसने आपको कॉल किए बिना अपना होमपेज संपादित किया।

उस प्रयोग के अंत में, आपके पास दीवार पर लटकाने के लिए 'ब्लॉक-फर्स्ट' बैज नहीं होगा। आपके पास एक टीम होगी जो टाइमलाइन के लिए माफ़ी माँगे बिना साझा आधार रेखा से एक नई क्लाइंट साइट शुरू कर सकती है। आप क्लाइंट के 42वें कस्टम ब्लॉक के अनुरोध को ना कहने की बेहतर स्थिति में भी होंगे—क्योंकि आप जानते हैं कि कोर ब्लॉक वास्तव में क्या कर सकते हैं, या क्योंकि आप दिखा सकते हैं कि एक डायनामिक ब्लॉक वास्तव में तेज़ क्यों होगा।

क्या आप अभी भी कुछ बेस्पोक साइट बनाएंगे? हाँ। कुछ क्लाइंट्स को हमेशा एक कस्टम टेम्पलेट, एक बेस्पोक पेज, या एक मालिकाना एकीकरण की आवश्यकता होगी जिसे साझा मॉडल में मजबूर करना उचित नहीं है। लक्ष्य बेस्पोक कार्य को समाप्त करना नहीं है—यह इसे डिफ़ॉल्ट के बजाय अपवाद बनाना है।

पुनरावृत्ति उबाऊ भागों से आती है: एक ठोस theme.json स्कीमा, एक स्पष्ट पैटर्न लाइब्रेरी, और साझा परत को दुबला रखने का अनुशासन। यह वह चमकदार संस्करण नहीं है जो आप वेबिनार में सुनते हैं। यह वह है जो सोमवार सुबह के खाली-थीम के अवसाद को हराता है।