गुटेनबर्ग सीपीटी द्वारा घोषित संपादक समर्थन का सम्मान करता है और यदि वह समर्थित नहीं है तो लोड नहीं होगा।

यदि इसका मतलब है कि गुटेनबर्ग बिल्कुल लोड नहीं होता है और इसके बजाय क्लासिक संपादक का उपयोग किया जाता है, तो यह हमें एक खंडित WP व्यवस्थापक की ओर ले जाता है जो गुटेनबर्ग और क्लासिक वातावरण के बीच विभाजित होता है। यह वर्डप्रेस के लिए कई मायनों में खराब होगा।

• नए उपयोगकर्ताओं को उन प्रमुख और सूक्ष्म तरीकों को सीखना होगा जिनमें दो प्रकार के इंटरफेस भिन्न होते हैं। गुटेनबर्ग और क्लासिक संपादकों में पोस्ट को प्रकाशित करने या टेक्स्ट व्यू में बदलने जैसी सरल क्रिया अलग तरह से काम करती है।

• मौजूदा डेवलपर्स को दोनों वातावरणों में अपने विषयों और प्लगइन्स की कार्यक्षमता बनाए रखने के लिए मजबूर किया जाएगा। हम संक्रमण काल ​​की बात नहीं कर रहे हैं; हम अनिश्चित काल के लिए बात कर रहे हैं। किसी भी प्रकार की पोस्ट को विस्तारित करने के लिए बने प्लगइन्स सबसे अधिक प्रभावित होंगे। यदि वे डेवलपर अपने मेटा बॉक्स को ब्लॉक में परिवर्तित कर देते हैं, तो उन्हें अभी भी पुराने मेटा बॉक्स को बनाए रखना होगा यदि कोई गैर-गुटेनबर्ग पोस्ट प्रकार में अपने प्लगइन का उपयोग करता है।

• वर्डप्रेस विकास में प्रवेश करने वाले नए प्लगइन डेवलपर्स को दो अलग-अलग तरीकों से प्लगइन्स बनाना सीखना होगा। यह मानते हुए कि वे गुटेनबर्ग ब्लॉकों को स्वीकार करते हैं, उनकी प्लगइन कार्यक्षमता क्लासिक संपादक का उपयोग करके पोस्ट प्रकारों में भी उपलब्ध नहीं हो सकती है।

जितना मेरा मानना ​​​​है कि हमें मेटा बॉक्स काम करना चाहिए, बस गुटेनबर्ग को बंद करना लंबी अवधि में सबसे अच्छा समाधान नहीं है।

यदि इसका मतलब है कि गुटेनबर्ग बिल्कुल लोड नहीं होता है और इसके बजाय क्लासिक संपादक का उपयोग किया जाता है, तो यह हमें एक खंडित WP व्यवस्थापक की ओर ले जाता है जो गुटेनबर्ग और क्लासिक वातावरण के बीच विभाजित होता है।

उन मामलों में जहां एक सीपीटी संपादक को बिल्कुल भी सक्षम नहीं करना चाहता, यह आगे बढ़ने का सबसे अच्छा रास्ता लगता है। यह एक अलग अनुभव के लिए अनुकूलित, बस एक अलग व्यवस्थापक दृश्य है। (उदाहरण के लिए, वू से "आदेश" दृश्य।) यह किसी को भी गुटेनबर्ग संदर्भ में उन्हें प्रस्तुत करने का प्रयास करने में मदद नहीं करेगा।

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

लेकिन गुटेनबर्ग के दायरे में कमी के कारण, यह केवल संपादक के प्रकार को सक्षम या अक्षम करने के बारे में नहीं है। चूंकि गुटेनबर्ग अब संपूर्ण संपादन इंटरफ़ेस निर्धारित करता है, इसलिए संपादक प्रकार से जुड़े दुष्प्रभावों की एक पूरी सूची है जिसे मैंने ऊपर सूचीबद्ध किया है।

हमें हमेशा एक "प्रबंधन" इंटरफ़ेस और एक "संपादन" इंटरफ़ेस की आवश्यकता होगी।

ठीक यही भूमिकाएँ आज संपादक और मेटा बॉक्स पूरी करते हैं। वे अलग-थलग अनुभव नहीं हैं। वे साथ साथ काम करते हैं।

तो शायद स्कोप रेंगना को संबोधित किया जाना चाहिए, और गुटेनबर्ग को wp_editor() आबादी वाले क्षेत्र में सीमित किया जाना चाहिए। यह निश्चित रूप से कई संगतता मुद्दों को हल करेगा।

लक्ष्य में बदलाव

स्कोप रेंगना को संबोधित करना मेरी प्राथमिकता है और हम में से कई लोग पिछले कई महीनों से कॉल कर रहे हैं। ऐसा करने से हम व्यवस्थापक अनुभव को विभाजित किए बिना संपादक को बेहतर बना सकेंगे।

प्रति पोस्ट प्रकार गुटेनबर्ग को सक्षम करना

प्रति पोस्ट प्रकार गुटेनबर्ग को अक्षम करने की क्षमता के संबंध में, मैं इस बात पर जोर देना चाहता हूं कि समस्या से बचना समाधान पर पहुंचने जैसा नहीं है। प्रति पोस्ट प्रकार गुटेनबर्ग को टॉगल करने से कुछ प्लगइन्स के लिए मेटा बॉक्स की असंगति से बचा जा सकता है, लेकिन यह लंबे समय तक वर्डप्रेस परिदृश्य को नुकसान पहुंचाता है।

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

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

जब हम दो संपादकों के साथ आगे बढ़ते हैं और UI में विलक्षणता की ओर कोई रास्ता नहीं होता है, तो ये कुछ ऐसे प्रश्न हैं जो परिदृश्य को भ्रमित करते हैं।

show_in_rest

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

कैसे गुटेनबर्ग कभी भी wp_editor() मापदंडों के दायरे से बाहर हो गया, मुझे अभी भी चकित करता है। यदि गुटेनबर्ग "संपादक" को wp_editor() पर रोक दिया जाएगा तो प्रति पोस्ट प्रकार "विकल्प के रूप में सक्षम करना" एक वास्तविकता बन जाता है और भविष्य में और अधिक प्रबंधनीय और विस्तार योग्य हो जाता है। मैंने अभी भी एक तर्कसंगत स्पष्टीकरण नहीं देखा है कि गुटेनबर्ग स्कोप रेंगना को वापस क्यों नहीं बढ़ाया जा सकता है और केवल wp_editor() के भीतर समाहित किया जा सकता है।

गुटेनबर्ग को कस्टम पोस्ट प्रकारों के लिए सक्षम करने का कोई मतलब नहीं है जो संपादक का उपयोग नहीं करते हैं और जो सीधे फ्रंटएंड पर प्रदर्शित नहीं होते हैं।

मैंने विभिन्न वेबसाइटें देखी हैं जहां सीपीटी का उपयोग न केवल वास्तविक पोस्ट प्रकारों के लिए किया जाता है, बल्कि विभिन्न सेटिंग्स और तत्वों के लिए व्यवस्थापक इंटरफेस बनाने की एक विधि के रूप में भी किया जाता है।

उदाहरण के लिए, जिस लेखक साइट पर मैंने काम किया है, उसमें "किताबें" और "शॉप लिंक्स" के लिए सीपीटी हैं। पुस्तक सूची पृष्ठों के संपादक के रूप में गुटेनबर्ग का होना बिल्कुल समझ में आता है। लेकिन "शॉप लिंक्स" का अपना कोई पोस्ट या पेज नहीं होता है, लेकिन प्रत्येक "बुक" पेज पर ऑनलाइन बुकस्टोर्स के लिंक के लिए तर्क की आपूर्ति के लिए उपयोग किया जाता है। पुस्तकें पृष्ठ टेम्प्लेट उत्पाद पृष्ठों के लिए शॉप लिंक प्रदर्शित करता है जो क्षेत्र (जैसे यूके, यूएस) और प्रारूप (जैसे ईबुक, प्रिंट) से मेल खाते हैं, प्रत्येक ऑनलाइन स्टोर की URL संरचना में पोस्ट मेटा फ़ील्ड में संग्रहीत ISBN को सम्मिलित करते हुए - स्क्रीनशॉट देखें।

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

गुटेनबर्ग को कस्टम पोस्ट प्रकारों के लिए सक्षम करने का कोई मतलब नहीं है जो संपादक का उपयोग नहीं करते हैं और जो सीधे फ्रंटएंड पर प्रदर्शित नहीं होते हैं।

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

उदाहरण के लिए, कल्पना करें कि आप एक प्लगइन डेवलपर हैं और आप चाहते हैं कि आपका "शॉप लिंक सेटिंग्स" मेटा बॉक्स एक पोस्ट प्रकार में उपलब्ध हो जो गुटेनबर्ग का उपयोग करता है और दूसरा पोस्ट प्रकार जो नहीं करता है। जब आप हजारों उपयोगकर्ताओं को प्लगइन वितरित कर रहे हैं, जो किसी भी पोस्ट प्रकार के साथ काम करने की उम्मीद करते हैं, तो आपके पास चुनने की विलासिता नहीं है। तभी https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341867663 में उल्लिखित प्रश्न चलन में आते हैं।

यह दोहराने लायक है कि अपने स्वयं के पोस्ट प्रकार के भीतर अलग किए गए मेटा बॉक्स गुटेनबर्ग से कम से कम प्रभावित होते हैं, इसलिए हमें यह विचार करना होगा कि यह प्लगइन कार्यक्षमता को कैसे प्रभावित करता है जो पोस्ट प्रकारों में कार्य करता है।

हां, मैं देख सकता हूं कि गुटेनबर्ग और गैर-गुटेनबर्ग इंटरफेस दोनों का समर्थन करने वाले प्लगइन्स एक प्रमुख चल रहे मुद्दे होंगे

मुझे लगता है कि सवाल यह हो जाता है कि गुटेनबर्ग को सीपीटी को कैसे संभालना चाहिए जो संपादक का समर्थन नहीं करते हैं - गुटेनबर्ग उन संदर्भों में कैसे कार्य करता है जहां ब्लॉक से एक पृष्ठ बनाने का कोई मतलब नहीं है, जहां यह सिर्फ मेटा संचालित है?

... गुटेनबर्ग को सीपीटी को कैसे संभालना चाहिए जो संपादक का समर्थन नहीं करते हैं - गुटेनबर्ग उन संदर्भों में कैसे कार्य करता है जहां ब्लॉक से एक पृष्ठ बनाने का कोई मतलब नहीं है, जहां यह सिर्फ मेटा संचालित है?

यदि गुटेनबर्ग को वापस स्केल करना था और केवल संपादक को प्रतिस्थापित करना था जैसे कि मैंने https://github.com/WordPress/gutenberg/issues/3304#issuecomment -341474018 में उल्लेख किया है, तो गुटेनबर्ग को सक्षम या अक्षम करना बहुत सरल हो जाता है।

• यदि editor सक्षम है, तो ब्लॉक संपादक मौजूद है और उपयोग किए गए हुक के आधार पर मेटा बॉक्स इसके ऊपर या नीचे दिखाई दे सकते हैं।
• यदि editor अक्षम है, तो ब्लॉक संपादक अनुपस्थित है और मेटा बॉक्स पोस्ट प्रकार के लिए प्राथमिक इंटरफ़ेस बनने के लिए ऊपर की ओर स्लाइड करते हैं।

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

मुझे लगता है कि "स्कोप रेंगना" का उपयोग करने के लिए एक अजीब शब्द है, किकऑफ पोस्ट और परियोजना को प्राप्त आशीर्वाद दिया कि समग्र रूप से संपादन अनुभव को कैसे बेहतर बनाया जाए । हम पर कुछ भी नहीं आया, यह हमेशा योजना थी, और यही कारण है कि फोकस के लिए कोई निर्धारित अवधि नहीं है।

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

प्रवाह पर पुनर्विचार किए बिना मौजूदा संपादक में ब्लॉक जोड़ने से जटिलता और बढ़ जाती जहां पहले से ही जटिलता थी ।

जनादेश को देखते हुए - शॉर्टकोड, कस्टम एचटीएमएल, विजेट और अधिक को बदलने के लिए ब्लॉक को शामिल करने के लिए पोस्ट ऑथरिंग पर पुनर्विचार करने के लिए - मैं एक डिजाइनर के रूप में अपनी जिम्मेदारी को पूरे लेखन, संपादन और प्रकाशन प्रवाह को समग्र रूप से नहीं देख रहा हूं।

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

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

वर्तमान संपादन स्क्रीन में गुटेनबर्ग के एक घटक , केवल संपादक कैनवास को

मुझे लगता है कि सवाल यह हो जाता है कि गुटेनबर्ग को सीपीटी को कैसे संभालना चाहिए जो संपादक का समर्थन नहीं करते हैं - गुटेनबर्ग उन संदर्भों में कैसे कार्य करता है जहां ब्लॉक से एक पृष्ठ बनाने का कोई मतलब नहीं है, जहां यह सिर्फ मेटा संचालित है?

@CalebWoodbridge यह पहले से ही कैसे काम करता है। देखें: https://github.com/WordPress/gutenberg/blob/master/lib/register.php#L290

मैं दूसरा कहूंगा कि 'स्कोप रेंगना' शब्द का प्रयोग सही नहीं है। यह एक ऐसा शब्द है जो निश्चित रूप से उस परियोजना पर लागू नहीं होता है जो गुटेनबर्ग के काम करने के लिए है।

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

गुटेनबर्ग के डिजाइनरों के साथ काम करने का अवसर पाकर मैं सम्मानित महसूस कर रहा हूं। यह एक दैनिक आनंद है और कुछ ऐसा जो हमें हमेशा वर्डप्रेस में नहीं मिलता है। ज्यादातर समय एक डिजाइनर के रूप में आप एक अकेले व्यक्ति होते हैं, एक साथ काम करना अविश्वसनीय रहा है।

जब हम डिज़ाइन दृष्टिकोण को देखते हैं तो अनुभव महत्वपूर्ण होता है। @jasmussen ने मूल दृष्टि में @matias के साथ एक संपूर्ण अनुभव की नींव रखी। दूसरे डिज़ाइन लीड के रूप में, यह कुछ ऐसा है जिसे मैं महत्व देता हूं और संरक्षित करना चाहता हूं।

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

गुटेनबर्ग ने हमें पैच हटाने के लिए जगह दी है, यह देखने के लिए कि हमारे पास क्या है और फिर से निर्माण करें। यह हमें अनुकूलन और उससे आगे जाने के लिए एक मजबूत दृश्य भाषा की शुरुआत के परिणामस्वरूप दिया गया है। वास्तव में एक दृश्य भाषा है जो अगले 10 वर्षों में वर्डप्रेस को आगे ले जाती है। हां, हमें बहुत आगे की सोचनी होगी।

मैं फ्रैंकेंडिजाइन्स के खिलाफ चेतावनी देने के लिए एक बिंदु लेना चाहता हूं। दुनिया में हर एक डिज़ाइनर के पास किसी न किसी ने सुझाव दिया है कि वे 'बस यहाँ x या y वहाँ रखें'। यह डिजाइनर को डिजाइन करने की अनुमति नहीं दे रहा है। यदि हम डिजाइनरों को डिजाइन नहीं करने देते हैं तो एक परियोजना के रूप में हम नीचे की ओर बढ़ रहे हैं। यह उस तरह की प्रक्रिया है जो कुंद होने के लिए, डिजाइनरों में आग को मार देती है। चलो आग जारी रखें।

यह एक व्यक्तिगत नोट है, जो गुटेनबर्ग से आगे जाता है। मैं भावुक हूं कि हम एक ऐसा स्थान बनाते हैं जहां डिजाइनर पनप सकते हैं और विकसित हो सकते हैं - हम हमेशा एक परियोजना के रूप में नहीं होते हैं। आइए गुटेनबर्ग के साथ दिखाएं कि हम ऐसा करते हैं। जुनून महान है, लेकिन डिजाइन विज़न का सम्मान करें जैसे हम वर्डप्रेस में तकनीकी दृष्टि से करते हैं। आइए डिजाइनरों को उतना ही सुनें जितना हम नवीनतम जेएस ढांचे के बारे में बात करने वालों को सुनते हैं।

@jasmussen द्वारा बोल्ड किए जाने के बारे में, अच्छा डिज़ाइन बोल्ड है। यह हमेशा से रहा है। इसे तलाशने और सोचने के लिए भी जगह चाहिए, गुटेनबर्ग इसके लिए अविश्वसनीय रहे हैं। हमारे पास (हमारे पास अभी भी) एक जगह है जहां हम उन विचारों का पता लगा सकते हैं जो पहले हमें लगता था कि एक परियोजना से निपटने के लिए बहुत अधिक थे। पुनरावृति, प्रयोग और प्रयास करने की स्वतंत्रता दी गई है। इसने कुछ अविश्वसनीय डिज़ाइन तैयार किए हैं, आइए इसे न भूलें।

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

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

इस तरह के बयानों को इस http://matiasventura.com/post/gutenberg-or-the-ship-of-theseus/ जैसे सार्वजनिक बयानों के साथ मिलाने की कोशिश करने से उपयोगकर्ताओं के लिए यह महसूस करना बहुत मुश्किल हो जाता है कि वे काम के बारे में ईमानदार संचार प्राप्त कर रहे हैं। किया जा। वर्डप्रेस का उपयोग लाखों लोग लाखों तरीकों से करते हैं, और यह स्पष्ट रूप से स्पष्ट किया गया है कि मेटाबॉक्स समर्थन या पोस्ट स्टोरेज प्रारूप जैसे तकनीकी पहलुओं के संबंध में, एक वृद्धिशील दृष्टिकोण की आवश्यकता है, जितना संभव हो उतना कम टूटना। इस निर्णय ने कार्यान्वयन के कई हिस्सों को जटिल बना दिया है, और ऐसे निर्णयों को मजबूर कर दिया है जो उप-इष्टतम हैं लेकिन कई मायनों में बेहतर समर्थित हैं।

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

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

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

यह अच्छा है कि आपने मीडिया को एक ऐसे क्षेत्र के रूप में बदलने का उल्लेख किया है जिस पर फिर से काम करने की आवश्यकता है ... जेएस ढांचे को पूरी तरह से अपनाने के लिए यह वर्डप्रेस का पहला खंड था, और यह काफी हद तक डेवलपर्स के लिए एक बड़ा कदम था। मीडिया लाइब्रेरी में अनुकूलन की कमी इस बात का संकेत नहीं है कि यह सही है, बल्कि इसमें विचारशील डिजाइन का अभाव है जो भविष्य और वर्तमान उपयोग-मामलों को ध्यान में रखता है। मैंने कई बार मीडिया इंटरफ़ेस को संशोधित करने का प्रयास किया है, केवल यह पता लगाने के लिए कि किसी ने, किसी बिंदु पर निर्णय लिया है कि प्रमुख घटकों को बैकबोन टेम्प्लेट में हार्ड-कोड किया जाना चाहिए। मैं सचमुच कल इन मामलों में से एक में भाग गया! (जैसा कि आप यहां सातवें पैराग्राफ में देख सकते हैं: https://gschoppe.com/wordpress/disable-attachment-pages/)

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

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

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

@gschoppe , उत्तर देने के लिए समय निकालने के लिए धन्यवाद।

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

विकास को एक मानक और डिजाइन को दूसरे मानक पर रखना उचित नहीं है।

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

यह अच्छा है कि आपने मीडिया को एक ऐसे क्षेत्र के रूप में बदलने का उल्लेख किया है जिस पर फिर से काम करने की आवश्यकता है ...

मैं एक मीडिया को डिजाइनरों और डेवलपर्स के साथ जमीनी स्तर पर ध्यान केंद्रित करते हुए देखना पसंद करूंगा, ऐसा नहीं है।

लेकिन साथ ही, अगर वर्डप्रेस इस संक्रमण के दौरान डेवलपर्स और पेशेवर उपयोगकर्ताओं के अपने विशाल समुदाय के लिए पर्याप्त समर्थन प्रदान करने में विफल रहता है, तो यह बहुत जल्द मर जाएगा।

यह दिलचस्प है कि आप यह कहते हैं क्योंकि कोई भी कार्यक्षमता नहीं ले रहा है। गुटेनबर्ग के किसी डिजाइन सुझाव ने ऐसा नहीं किया है। किसी भी तरह से, सभी मौजूदा कार्यक्षमताएं पूरी की जा सकती हैं, भले ही वह क्लासिक संपादक प्लगइन का उपयोग कर रहा हो।

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

यदि गुटेनबर्ग के लिए दीर्घकालिक योजना प्लगइन क्षेत्र थी, तो मैं कहूंगा कि बिना सीमा के प्रयोग करें। लेकिन अगर यह एक ऐसा प्लगइन नहीं है जिसे लोगों को ऑप्ट आउट करने के बजाय ऑप्ट इन करना पड़ता है, तो इसे वास्तविक रूप से मूल और इसके साथ लाए गए सभी सामानों से निपटना होगा।

मेरी टिप्पणी का उद्देश्य यह नहीं है कि डिजाइन को अधिक सुना जाए

दुनिया में हर एक डिज़ाइनर के पास किसी न किसी ने सुझाव दिया है कि वे 'बस यहाँ x या y वहाँ रखें'। यह डिजाइनर को डिजाइन करने की अनुमति नहीं दे रहा है। यदि हम डिजाइनरों को डिजाइन नहीं करने देते हैं तो एक परियोजना के रूप में हम नीचे की ओर बढ़ रहे हैं। यह उस तरह की प्रक्रिया है जो कुंद होने के लिए, डिजाइनरों में आग को मार देती है। चलो आग जारी रखें।

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

कुंद होने के लिए, एक्सेसिबिलिटी के नुकसान के बिना, एक डिज़ाइन बाधा के बिना मेटाबॉक्स के लिए पूर्ण समर्थन है या नहीं? मुझे एक स्पष्ट उत्तर चाहिए, जैसा कि हजारों अन्य लोग करेंगे।

गुटेनबर्ग के किसी डिजाइन सुझाव ने ऐसा नहीं किया है। किसी भी तरह से, सभी मौजूदा कार्यक्षमताएं पूरी की जा सकती हैं, भले ही वह क्लासिक संपादक प्लगइन का उपयोग कर रहा हो।

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

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

वर्तमान में, wp_editor() फ़ंक्शन (जो गैर-संपादन पृष्ठों पर संपादन अनुभव की एक पूर्ण-विशेषीकृत प्रतिलिपि को लागू करने का वर्तमान सर्वोत्तम-प्रथा है) गुटेनबर्ग इंटरफ़ेस प्रदान नहीं करता है, जिसका अर्थ है कि मैं नहीं कर सकता गैर-पोस्ट पृष्ठों पर कस्टम संपादन अनुभव बनाएं... उपयोगकर्ताओं को एक विभाजित UX देने के अलावा, वहां आगे का मेरा मार्ग क्या है?

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

मानक वर्कफ़्लो के लिए फ़ीचर हटाना पश्चगामी संगतता नहीं है। सुविधाओं को हटाना उन 1% उपयोगकर्ताओं के लिए अंतिम उपाय है, जिन्हें प्रथम श्रेणी के अनुभवों के रूप में समायोजित नहीं किया जा सकता है। इस मामले में, मेरे द्वारा दिए गए उदाहरणों में से कोई भी 1% मुद्दे नहीं हैं।

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

फिर भी, आईफ्रेम के साथ काम करने के लिए आरडब्ल्यूडी को ठीक से प्राप्त करने के लिए मुझे भारी मात्रा में काम करना होगा, और सबसे अधिक, विश्वसनीय और रखरखाव योग्य, टर्न-अबाउट बहुत कम प्रयास था और इस प्रकार बेहतर तरीका था।

इसे सारांशित करने के लिए, हालांकि iframes पहली नज़र में एक आसान तरीके की तरह दिखते हैं, वे एक बहुत ही खराब डिज़ाइन विकल्प हैं, न कि केवल (बहुत सारे) एक्सेसिबिलिटी मुद्दों के कारण।

बस मेरा .02 सेंट,
घन, w0lf।

इस मुद्दे को दिखाने के लिए @mtias को धन्यवाद।
नीचे मैं अपने विचार पोस्ट कर रहा हूं कि कैसे गुटेनबर्ग वर्डप्रेस प्लगइन डेवलपर्स के लिए दरवाजे खोल सकता है।

किसी भी मौजूदा ब्लॉक के लिए अनुकूलन योग्य सीएसएस वर्ग

जरूरत है: प्रत्येक ब्लॉक रैपर के लिए सीएसएस वर्ग और इसे अनुकूलित करने के लिए पूर्ण पहुंच। यह बहुत अच्छा होगा यदि गुटेनबर्ग को तीसरे पक्ष के डेवलपर्स से भी शीर्ष तत्व पर सीएसएस वर्ग की आवश्यकता है।

उद्देश्य: इस तरह हम उन्नत स्टाइल के लिए कस्टम क्लासेस को ब्लॉक में जोड़ सकते हैं। हम एनिमेशन या अन्य उन्नत ब्लॉक गुण जोड़ने के लिए कक्षाओं का भी उपयोग कर सकते हैं।

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

किसी भी मौजूदा ब्लॉक के लिए अनुकूलन योग्य डेटा विशेषताएँ

आवश्यक: किसी भी ब्लॉक रैपर के लिए अनुकूलित डेटा विशेषताओं को जोड़ने की संभावना।

उद्देश्य: ऊपर वर्णित कस्टम सीएसएस कक्षाओं के लिए क्लीनर और अधिक लचीला विकल्प। डेटा विशेषताओं के साथ, हम पृष्ठ पर किसी भी तत्व को स्टाइल कर सकते हैं। स्टाइल के अलावा, JS के लिए अतिरिक्त मेटाडेटा को संग्रहीत करने के लिए कस्टम डेटा विशेषताओं का उपयोग किया जा सकता है।

उदाहरण उपयोग:

• प्रतिक्रियाशील ब्लॉक : केवल मोबाइल/डेस्कटॉप पर दिखाए जाने वाले ब्लॉक को चिह्नित करें
• सशर्त ब्लॉक : जेएस <div data-condition="if-adblock"... , <div data-condition="if-from-facebook"... साथ दिखाए जाने/छिपाने के लिए एक ब्लॉक को चिह्नित करें
• ब्लॉक एनीमेशन : एनिमेटेड होने के लिए एक ब्लॉक को चिह्नित करें <div data-animation="on-load animation-style-3"...
• ब्लॉक डिजाइन : <div data-skin="dark"...