Gutenberg: क्या मेटा बॉक्स के लिए एक व्यवहार्य दीर्घकालिक समाधान है?

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

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

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

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

उपरोक्त सभी ने कहा, मुझे लगता है कि भविष्य में मेटाबॉक्स का क्या उपयोग किया जाएगा, यह देखना महत्वपूर्ण है। ऐसे कौन से मामले हैं (यदि कोई हैं) जिन्हें ब्लॉक में नहीं बदला जाएगा? क्या सभी मेटाबॉक्स को मोबाइल पर काम करना पड़ता है? वहाँ भी एक वैकल्पिक इंटरफ़ेस है कि हम पता लगाया नहीं है? मुझे यकीन है वहाँ है। अभी, यह उन संभावनाओं को देखने और सड़क पर उतरने के बारे में है जो अभी और भविष्य की स्थिति के लिए काम करता है।

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

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

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

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

सम्मानपूर्वक, ऐसा हर बार होता है जब मेटा बॉक्स का मुद्दा सामने आता है। कृपया, बातचीत को भविष्य के मेटा ब्लॉक्स पर स्थानांतरित करने के बजाय, इस चर्चा को मौजूदा मेटा बॉक्स के सामने आने वाले मुद्दों के इर्द-गिर्द फैलाने में मददगार होगा। एक बार फिर:

क्या इन मुद्दों को मेटा बॉक्स को उत्पन्न करने वाले विषय या प्लगइन के संशोधन की आवश्यकता के बिना संबोधित किया जा सकता है?

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

नमस्ते केविन,

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

क्या मेटा बॉक्स से एक कंटेंट विंडो लॉन्च करना संभव है जो आईफ्रेम से परे फैली हुई है?

क्या आप एक मोडल लाइटबॉक्स की तरह हैं जो पूरे पृष्ठ को लेना चाहिए?

क्या आप एक मोडल लाइटबॉक्स की तरह हैं जो पूरे पृष्ठ को लेना चाहिए?

यह एक उदाहरण होगा, लेकिन मैं किसी भी परिदृश्य का अधिक उल्लेख कर रहा हूं, जहां सामग्री को प्रकट करने की आवश्यकता है जो कि iffame की सीमा के भीतर नहीं है।

उदाहरण के लिए, क्या मैं साइडबार में एक बटन पर क्लिक कर सकता हूं जो पेज के केंद्र में एक सामग्री बॉक्स को ट्रिगर करता है? यदि वह सामग्री बॉक्स iframe के अंदर है, तो यह साइडबार में iframe के आयामों के बाहर दिखाई नहीं देगा।

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

प्लगइन / थीम परिसंपत्तियों के संबंध में iFrame कार्यान्वयन कितना नकारात्मक है, यह जानकर, मुझे लगता है कि इस परियोजना को विराम देना चाहिए। यहाँ असली जवाब वर्डप्रेस शिपिंग है फील्ड्स एपीआई https://github.com/sc0ttkclark/wordpress-fields-api - इसके बिना, अगर हम बिल्कुल भी प्रदर्शन की परवाह करते हैं तो गुटेनबर्ग के साथ मेटाबॉक्स को प्रभावी ढंग से लागू करना असंभव है।

यदि हम वास्तव में "तैयार" होने तक गुटेनबर्ग को शिपिंग नहीं कर रहे हैं, तो मैं कहता हूं कि हमें फील्ड्स एपीआई पर समान ध्यान देना चाहिए ताकि मेटबॉक्सेज सही तरीके से और सीमलेस रूप से गुटेनबर्ग में प्रतिक्रिया के साथ काम करें।

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

हाँ, निश्चित रूप से ऐसा करते समय मुझे एक चिंता थी। आइफ्रेम के बीच क्रॉस संचार बहुत अच्छा नहीं लगता है। अन्य विकल्प भी हैं।

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

यह ध्यान देने योग्य हो सकता है कि हाल ही के कोर कस्टमाइज़र देव नोट पोस्ट में _improvement_ के रूप में एक iframe का उपयोग करने से हटाने पर ध्यान आकर्षित किया गया था। यह एक समाधान के रूप में एक iframe को लागू करने के लिए एक कदम पीछे की तरह लगता है।

हाय मठो,

यदि हम वास्तव में "तैयार" होने तक गुटेनबर्ग को शिपिंग नहीं कर रहे हैं, तो मैं कहता हूं कि हमें फील्ड्स एपीआई पर समान ध्यान देना चाहिए ताकि मेटबॉक्सेज सही तरीके से और सीमलेस रूप से गुटेनबर्ग में प्रतिक्रिया के साथ काम करें।

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

... हर संभव उपयोग के मामले को समायोजित करना संभव नहीं है, मुझे लगता है कि उपयोगकर्ताओं के विशाल, विशाल बहुमत के लिए एक अच्छा अनुभव बनाने और मामलों का उपयोग करने के लिए एक बेहतर लक्ष्य है।

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

मैं इस अवधारणा के साथ मजबूत समझौते में हूं, जो कि योआस्ट द्वारा लगाई गई है, जो मुझे ऐसा लगता है कि यह संपादक के घटक पर ध्यान केंद्रित करने के लिए परियोजना के दायरे को वापस लेने के दौरान पहले से किए गए बहुत से काम को बनाए रखेगा।

स्रोत: https://yoast.com/gutenberg-alternative-approach/

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

बस यह देखते हुए कि यह अवधारणा मौजूदा मेटाबॉक्स को तोड़ती है, क्योंकि इसके साथ संवाद करने के लिए कोई केंद्रीय टिनीएमसीई उदाहरण नहीं है। 80% मेटाबोक्स का समर्थन करने के बजाय, यह 90% (मैंने इन नंबरों को बनाया) का समर्थन करेगा।

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

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

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

अब सबसे अच्छा संभव संपादक का निर्माण करते हैं।

जब हमें लगता है कि गुटेनबर्ग की आदर्श दृष्टि जहाज के लिए तैयार है, तो हमारे पास अपग्रेड पथ रणनीतियों पर चर्चा करने का समय होगा ...

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

यदि आदर्श साइटों को मौजूदा साइटों के साथ संगत नहीं बनाया जा सकता है, तो आदर्श संपादक को विकसित करने में हजारों घंटे क्यों समर्पित करें?

केवल स्पष्ट करने के लिए,

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

बाहर निकलने वाली वेबसाइटों के साथ 100% संगत होना असंभव है

अब जब यह स्पष्ट हो गया है, तो आइए हम उस संपादक का निर्माण करें जो हमें लगता है कि वर्डप्रेस के भविष्य के लिए सबसे अच्छा है।

क्या सभी मेटाबॉक्स को मोबाइल पर काम करना पड़ता है?

हां, वे क्यों नहीं करेंगे?

ऐसे कौन से मामले हैं (यदि कोई हैं) जिन्हें ब्लॉक में नहीं बदला जाएगा?

ब्लॉग पोस्ट के लिए, मुझे समझ में आया कि क्यों ब्लॉक फॉर एवरीथिंग कुछ समझ में आता है, लेकिन यह मेटाडेटा के लिए सामान्य उपयोग के मामले की अनदेखी कर सकता है: डेटा जो अनदेखी है। जैसे, मैं एक पोस्ट में एनालिटिक्स डेटा को जोड़ने के लिए UI को बेनकाब करने के लिए एक मेटाबॉक्स का उपयोग कर सकता हूं।

कस्टम पोस्ट प्रकार जैसी चीजों के लिए, जो केवल मेटा बॉक्स से बनी हो सकती हैं, मुझे नए UI की समझ बनाने में परेशानी होती है। क्योंकि वर्डप्रेस में डेटा के लिए एक व्यापक CRUD एपीआई का अभाव है, बहुत सारे डेवलपर स्टैंड-इन के रूप में WP_Query और उसके संबंधित API के सुइट का उपयोग करते हैं, और वे विशिष्ट डेटा जोड़ने के लिए UI को अलग करने के लिए CPT एडिट स्क्रीन पर मेटा बॉक्स का उपयोग करते हैं या संघों। जंगली सामग्री में कस्टम पोस्ट प्रकार के कई (बहुसंख्यक) "सामग्री" के पारंपरिक उपयोग पर जोर देते हैं या उपेक्षा करते हैं - इसलिए ब्लॉग पोस्ट के लिए, हां, सामग्री सामने और केंद्र है, लेकिन कई सीएमएस उपयोग के मामलों के लिए, WYSIWYG नहीं बनाता है बहुत सारी समझदारी।

इस वर्तमान पुनरावृत्ति में, मेटा बॉक्स समर्थन एक ऐड-ऑन है, जब कई लोगों की वास्तविकता में, मेटा बॉक्स यूआई, एपीआई हैं, जो तंत्र वे अपने सीएमएस को बनाने के लिए उपयोग करते हैं। <iframe> s गुलाल हैं।

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

मैं इस उदाहरण के साथ समाप्त हो जाऊंगा: अगर मेरे "पुराने" मेटा बॉक्स में से एक मीडिया के लिए यूआई को ट्रिगर करता है, तो यह कैसे काम करेगा, इस "नए" परिदृश्य में, आइफ्रेम के भीतर से, बिना किसी (एक क्लाइंट के बिना मैं अब काम नहीं करता हूं) ) कोड को फिर से लिखना?

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

कृपया समझें कि हम में से कई के लिए हमारे पास दर्जनों साइटें हैं जो वर्डप्रेस 5.0 में अपडेट होने पर तुरंत टूट जाएंगी - एक ऐसा उत्पाद जो ऐतिहासिक रूप से लोगों को सिखाया गया है कि इसे अपग्रेड करना सुरक्षित है क्योंकि इसकी मैनीक्योर बैकवर्ड संगतता के बारे में है। यहां जो चर्चा की जा रही है वह मामूली (जैसे स्टाइल) ब्रेक नहीं है, लेकिन एक संभावित शो स्टॉपर जो हजारों (या अधिक) के एडमिन-साइड को तुरंत अनुपयोगी बना देगा। वह डरावना सामान है। एक उद्योग के रूप में हमने लोगों को वर्डप्रेस की ठोस-ठोस विश्वसनीयता पर बेचा है।

जैसे @staylor ने हमारी वेबसाइटों के अधिकांश भाग (मिड-टू-हाई-एंड कॉम्प्लेक्सिटी कॉरपोरेट साइट्स) पर मेटाबोक्स _are_ UI का उल्लेख किया। संपादक (यदि इसका उपयोग किया जाता है) केवल इसका एक हिस्सा है।

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

मुझे लगता है कि यह दूर करने के लिए एक गलती हो सकती है। खासकर जब से कई संगठनों को तैयार करने के लिए कम से कम 1-2 तिमाहियों की आवश्यकता होती है।

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

बाहर निकलने वाली वेबसाइटों के साथ 100% संगत होना असंभव है

यदि आप निश्चित रूप से जाने और चीजों को तोड़ने की तुलना में संगत नहीं हैं। पहले रिलीज WP ++ या WPNG पर कॉल करें। पहले से घोषित करना बेहतर है कि चीजें सबसे अधिक टूटेंगी और लोगों को इसके लिए तैयार करने देंगी। वर्तमान "धोखे" के रूप में अगर चीजें हमेशा की तरह काम करेंगी तो हर किसी के लिए बुरा होगा।

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

ऐसे बहुत से कारण हैं कि लोग केवल अंतिम उपाय के रूप में आइफ्रेम का उपयोग करते हैं।

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

मेरा उत्पादक सुझाव, मेटा बॉक्स को तैयार घोषित नहीं करना है

जैसा कि ऊपर @karmatosed द्वारा बताया गया है: "यह थोड़ा सोचने के लिए अच्छा है कि गुटेनबर्ग में

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

गुटेनबर्ग वास्तविकता के भीतर काम करने के लिए इस साइट को फिर से तैयार करने में एक लंबा समय लगेगा और पर्याप्त संसाधनों की आवश्यकता होगी, इसलिए जब तक मेटाबॉक्स को इस तरह से संभाला नहीं जाता है कि क्या पहले से मौजूद है, इसके साथ निकटता से मेल खाता है, यह साइट स्वामी संभवतः WP के पूर्व-गूटेनबर्ग संस्करण में वापस रहेगा और रहेंगे अनिश्चित समय के लिए वहाँ है।

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

इस मार्ग को जितना संभव हो उतना सहज रूप से आगे बढ़ाना नितांत आवश्यक है।

माना

यह चीजों को तोड़ देगा, और यह ठीक है (वर्डप्रेस की हर रिलीज के बारे में वापस संगतता तोड़ रहे हैं), लेकिन उन्हें न्यूनतम, प्रलेखित और संचारित किए जाने की आवश्यकता है।

माना

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

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

मैं _get_ कि यह सब एक प्रयोग है, मुझे लगता है कि @kevinwhoffman भी करता है। मैं इस मुद्दे को इस प्रयोग के एक बेहतर विचार के रूप में देखता हूं और इसे उसी रूप में लिया जाना चाहिए। क्या यह प्रयोग अंतिम समाधान के रूप में पर्याप्त होगा? नहीं, तो अगला प्रयोग क्या है?

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

tldr; क्या हम गुटेनबर्ग के साथ टूटने की उम्मीद करते हैं? हाँ! लेकिन हमें अभी भी _what_ के बारे में चयनात्मक होना चाहिए, हम टूटते हैं, और कितनी दूर तक टूटना _initial_ गुटेनबर्ग के पुनरावृत्ति में जाता है।

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

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

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

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

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

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

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

@ARonjorbin अच्छी तरह से, ऐसा लगता है कि यहाँ एक संचार समस्या है जैसे https://make.wordpress.org/core/2017/10/24/whats-new-in-gutenberg-24th-october/ में स्पष्ट रूप से कहा गया था

इस रिलीज़ में लंबे समय से प्रतीक्षित मेटा-बॉक्स समर्थन (परीक्षण की आवश्यकता है!) शामिल हैं।

यह एक "विचार" नहीं है यह एक "प्रयोग" नहीं है, यह सिर्फ एक चीज है जो हर सॉफ्टवेयर की तरह अभी भी कीड़े शामिल हो सकता है। अगर मैं इसे उस पोस्ट में "एक प्रयोग" कहा जाता तो मैंने इसका परीक्षण नहीं किया होता।

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

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

उन iframes के साथ एक नया मुद्दा जोड़ सकते हैं। जब उपयोगकर्ता सत्र निकल जाता है तो WP लॉगिन स्क्रीन गुटेनबर्ग के ऊपर और आइफ्रेम के अंदर दो बार दिखाई जाती है।

बस डेवलपर्स को इसके बारे में पता होना चाहिए।

अधिक मैं इस सब का पालन करता हूं और मुझे विश्वास है कि केवल संभव तरीका होगा जैसे Microsoft ने किया था।

विंडोज एक्सपी = गुटेनबर्ग के बिना वर्डप्रेस
विंडोज 10 = गुटेनबर्ग के साथ वर्डप्रेस।

उन 2 को अन्य के पैकेज के साथ मिश्रित और अद्यतन नहीं किया जा सकता है।

जुमला और द्रुपाल ने किया था। क्यों नहीं। ऐसा कुछ नहीं जो मैं बिल्कुल पसंद करूं, लेकिन विकल्प क्या है।

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

एक विभाजन व्यवस्थापन सबसे बुरे परिणामों में से एक होगा जो गुटेनबर्ग से बाहर आ सकता है। मैंने उन कारणों को रेखांकित किया है जिनके कारण https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341752490 है।

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

केविन हॉफमैन:

मैं इस अवधारणा के साथ मजबूत समझौते में हूं, जो कि योआस्ट द्वारा लगाई गई है, जो मुझे ऐसा लगता है कि यह संपादक के घटक पर ध्यान केंद्रित करने के लिए परियोजना के दायरे को वापस लेने के दौरान पहले से किए गए बहुत से काम को बनाए रखेगा। स्रोत: https://yoast.com/gutenberg-alternative-approach/

मुझे विश्वास है कि Yoast द्वारा प्रस्तावित पथ वर्डप्रेस कोर के लिए एक महान सुधार होगा। सामग्री बनाने के लिए एक नया संपादक, जो बहुत सारे उपयोगकर्ता वर्तमान में सुधार के रूप में ग्रहण करेंगे। वर्डप्रेस के लिए एक छोटा कदम, लेकिन उपयोगकर्ता के लिए एक महान सुधार।

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

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

कृपया, खुले विचारों वाले बनें, और कुछ सवालों के जवाब देकर शुरू करें:

गुटेनबर्ग के लिए क्या लक्ष्य है?

यह नहीं है, और यह कभी नहीं था, गुटेनबर्ग के लिए मुख्य लक्ष्य वर्डप्रेस कोर के भविष्य का मार्ग प्रशस्त कर रहा है। तकनीकी रूप से, REST API, क्लाइंट-साइड UI और कोर कॉन्सेप्ट्स को एकजुट करके: विजेट्स, शॉर्टकोड, ब्लॉक, कंटेंट मेटाबॉक्सेस को एक यूनीक कॉन्सेप्ट "A ब्लॉक" के तहत इस्तेमाल किया जाता है और इन सवालों के जवाब देकर समझदारी का अनुभव करते हैं: बिल्डिंग वेबसाइट्स को कैसे सरल बनाया जा सकता है (कस्टमाइज़ेशन सोचें) और WordPress में प्रकाशन सामग्री (विचार संपादक)।

गुटेनबर्ग संपादक के लिए क्या लक्ष्य है?

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

Metaboxes के बारे में क्या, वे वर्डप्रेस के लिए महत्वपूर्ण हैं?

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

शॉर्टकोड, टाइनीएमसीई बटन और मेटाबॉक्स के बीच अंतर क्या है?

मुख्य अंतर यह है कि "मेटाबोक्स" का कोई "उद्देश्य" नहीं है, यह सिर्फ एक तरीका है जिसमें संपादक पृष्ठ को निरंतरता के बिना विस्तारित किया जा सकता है जबकि शॉर्टकोड और टाइनीमेसी बटन में एक है।

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

क्या यह "उद्देश्य" की कमी एक मुद्दा है, या एक फायदा है?

कुंआ! इसे एक "समर्थक" के रूप में देखा जा सकता है, क्योंकि एक प्लगइन वे कुछ भी कर सकते हैं जो संपादक के साथ चाहते हैं, जैसे कि:

• किसी भी बटन, textarea, इनपुट, div, कुछ भी की जगह। DOM तक पूर्ण पहुँच
• TinyMCE के वैश्विक उदाहरण सहित किसी भी वैश्विक जावास्क्रिप्ट चर का उपयोग करना

लचीले सही! लेकिन वर्डप्रेस अपडेट के बारे में क्या। संपादक की स्क्रीन पर कोई भी अपडेट। कोई भी TinyMCE अपडेट, कोई भी वर्ग परिवर्तन, कोई भी नया div , किसी भी बटन को हटा दिया गया / ले जाया गया, कोई भी परिवर्तन प्लगइन्स के साथ संगतता को तोड़ रहा है क्योंकि कोर वर्डप्रेस डेवलपर के रूप में, आपको नहीं पता कि कौन से प्लग इन मेटाबॉक्स के लिए उपयोग कर रहे हैं।

क्या हम यह निष्कर्ष निकाल सकते हैं कि वर्डप्रेस की लंबी अवधि के लिए, मेटाबॉक्स अपने विकास को बंद कर रहे हैं (गुटेनबर्ग की परवाह किए बिना)?

हाँ वे हैं। और इंटरनेट इतिहास ने कई बार साबित किया कि एक तकनीक जो विकसित नहीं होती है वह मर जाती है। (कृपया इस पर प्रतिक्रिया न दें with यदि आपको यह उत्तर पसंद नहीं है, तो यह एक तथ्य है और एक राय नहीं है)

ठीक है, लेकिन तब हम वर्डप्रेस को कैसे आगे बढ़ा सकते हैं यदि हम मेटाबॉक्स के साथ फंस गए हैं?

यह एक अच्छा सवाल है और जवाब देने से पहले, हमें वर्डप्रेस प्लग-इन में मेटाबॉक्स के वर्तमान उपयोग को समझने की आवश्यकता है

वर्तमान प्लगइन्स Metaboxes का उपयोग किस लिए करते हैं?

मैं कहूंगा कि "मेटाबेस" प्लगइन्स की दो श्रेणियां हैं:

• सामग्री के रूप में मेटाबोक्स (अक्सर पोस्ट मेटा में संग्रहीत लेकिन हमेशा नहीं)
• संपादक के अनुभव में वृद्धि के रूप में मेटाबॉक्सिस (एसईओ, वर्तनी जांच, ...)

ठीक है, यह जानते हुए कि हम कैसे आगे बढ़ सकते हैं?

हमें तीन चीजें चाहिए:

• गुटेनबर्ग (या वर्डप्रेस के किसी भी अपडेट) के दौरान इन प्लगइन्स को बनाने या अपग्रेड करने का तरीका प्रदान करें।
• इन प्लगइन्स का उपयोग करने वाले लोगों के लिए सर्वोत्तम संभव उन्नयन पथ प्रदान करें। इसमें शामिल हैं: देखें कि क्या ये प्लगइन्स अभी भी आने वाले एवोल्यूशन के साथ काम कर सकते हैं और ब्रेक्जिट को कैसे कम कर सकते हैं।

ठीक है, लेकिन आपने यह नहीं कहा कि संपादक पृष्ठ का कोई भी परिवर्तन प्लगइन्स को तोड़ देगा (केवल सामग्री क्षेत्र को बदलने सहित)?

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

मैं इसे व्यक्तिगत रूप से अच्छा अपग्रेड पथ नहीं कहूंगा, यह अपग्रेड भी नहीं है, कुछ भी बेहतर है?

यह अपग्रेड पथ (गुटेनबर्ग को अक्षम करना) एक आवश्यकता है लेकिन हां, हम बेहतर कर सकते हैं। यदि आप Metaboxes का उपयोग करके प्लगइन्स पर एक नज़र डालते हैं, तो उनमें से 90% सामग्री क्षेत्र के साथ कोई इंटरैक्शन नहीं करते हैं, इस प्रकार, यदि हम केवल सामग्री क्षेत्र (yoast दृष्टिकोण) को प्रतिस्थापित करते हैं, तो हम केवल 10% प्लगइन्स को तोड़ेंगे।

इसलिए, बिना टूट-फूट के एकमात्र तरीका गुटेनबर्ग को अक्षम कर रहा है।

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

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

क्या यह आइफ्रेम समाधान हर किसी के बारे में बात कर रहा है?

हाँ यही है। हम iframes में मेटा बॉक्स दिखाते हैं, जिसमें इसकी कमियां (लिंक, मोडल, एसेट लोड करना) हैं, लेकिन साथ ही यह पूरे गुटेनबर्ग एक्सपीरियंस का आनंद लेते हुए 80% प्लगइन्स को काम करने की अनुमति देता है। यह समाधान अभी उतरा है और हम अभी भी इसके साथ प्रयोग कर रहे हैं। क्या निश्चित है, यह है कि सभी मेटाबॉक्स को काम करने और संपादक में बदलाव करने का कोई तरीका नहीं है।

मैं देख रहा हूँ, क्या आप उन्नयन की संभावनाओं को फिर से ला सकते हैं?

ज़रूर।

1- गुटेनबर्ग को अक्षम करें: 100% प्लगइन्स को न तोड़ें
2- गुटेनबर्ग केवल सामग्री क्षेत्र की जगह लेता है: 90% प्लगइन्स काम करते हैं, यूएक्स पीड़ित हैं
3- गुटेनबर्ग पूरी स्क्रीन को बदल देता है: 80% प्लगइन्स काम करते हैं, यूएक्स बेहतर है
4- संगत प्लगइन्स के साथ गुटेनबर्ग: सर्वोत्तम संभव यूएक्स

तो हमें क्या करने की आवश्यकता है?

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

मैं दूसरे विकल्प पर विकल्प कैसे चुन सकता हूं?

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

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

हम सभी एक ही नाव पर हैं, हम वर्डप्रेस के लिए सर्वश्रेष्ठ चाहते हैं।

बहुत गहन व्याख्या, Riad। उन्हें लिखने के लिए समय देने के लिए धन्यवाद। मुझे एक a और clear के साथ उस सीमा को स्पष्ट करने में मदद करने दें। आशा है कि इससे सहायता मिलेगी।

मेटाबॉक्स के संबंध में, मैं कोर में फील्ड्स एपीआई के लिए विलुप्त हो जाएगा। हमारे प्लगइन्स को फिर से लिखना होगा ताकि सभी गड़बड़ कस्टम मेटाबोक्स समाधानों से छुटकारा मिल सके।

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

हम मानव हैं। समीकरण के दूसरी तरफ होने की कोशिश करें, इस चीज का निर्माण करें और यह सभी प्रतिक्रिया प्राप्त करें। आईटी "व्यक्तिगत हमलों" के करीब महसूस कर सकता है, दिमाग खारिज करने की प्रतिक्रिया करता है, हमें नहीं करना चाहिए।

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

आप यहाँ और वहाँ क्या पढ़ते हैं, इसके विपरीत, ध्यान हमेशा पूरे पृष्ठ को नया स्वरूप देने के बारे में रहा है, गुटेनबर्ग संपादक पृष्ठ के लिए पहला मॉकअप दूसरे या तीसरे साप्ताहिक गुटेनबर्ग बैठक में दिखाया गया है ...

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

मैंने अपने पूर्व-अल्फा चरणों के बाद से गुटेनबर्ग का बारीकी से परीक्षण और परीक्षण करने के अपने अनुभव के आधार पर यह मुद्दा बनाया। यह चल रहे मेटा बॉक्स चुनौतियों से संबंधित सिर्फ नवीनतम मुद्दा है, लेकिन महत्वपूर्ण बात यह है कि यह पहली बार गुटेनबर्ग के मेटा बॉक्स कार्यान्वयन के ठोस परीक्षण पर आधारित है।

मुख्य अंतर यह है कि "मेटाबोक्स" का कोई "उद्देश्य" नहीं है, यह सिर्फ एक तरीका है जिसमें संपादक पृष्ठ को निरंतरता के बिना विस्तारित किया जा सकता है जबकि शॉर्टकोड और टाइनीमेसी बटन में एक है।

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

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

संपादक की स्क्रीन पर कोई भी अपडेट। किसी भी TinyMCE अपडेट, किसी भी वर्ग परिवर्तन, किसी भी नए डिव, किसी भी बटन को हटा दिया / ले जाया गया, कोई भी परिवर्तन प्लगइन्स के साथ संगतता को तोड़ रहा है क्योंकि कोर वर्डप्रेस डेवलपर के रूप में, आपको नहीं पता कि कौन से प्लगइन्स मेटाबॉक्स के लिए उपयोग कर रहे हैं।

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

हम iframes में मेटा बॉक्स दिखाते हैं, जिसमें इसकी कमियां (लिंक, मोडल, एसेट लोड करना) हैं, लेकिन साथ ही यह पूरे गुटेनबर्ग एक्सपीरियंस का आनंद लेते हुए 80% प्लगइन्स को काम करने की अनुमति देता है।

यदि आपके पास इन 80% / 90% संख्याओं के लिए कोई सबूत है जो लगातार संदर्भित किए जा रहे हैं, तो कृपया इसे साझा करें। अन्यथा इस परिमाण का निर्णय करने के लिए समुदाय से पूछते समय कृपया काल्पनिक आंकड़ों का उपयोग न करें।

कृपया रुकें और पुनर्मूल्यांकन करें, बाद में नहीं

इस चर्चा के बाद और मैंने जो सोचा वह इस बात का सबूत था कि iframes एक व्यवहार्य दीर्घकालिक समाधान नहीं है, मैं https://github.com/WordPress/gutenberg/issues/3165#issuecomment -341478059 पर आया हूं जो तीसरा जोड़ना चाहता है आइफ्रेम ।

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

एक डेवलपर के रूप में बोलते हुए, जो 1 दिन से गुटेनबर्ग संपादक को देख रहा है और चर्चा कर रहा है, मुझे यह कहते हुए खेद है कि रियाद के तर्क में कुछ बड़े छेद हैं।

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

Metaboxes विरासत कोड नहीं हैं, क्योंकि वर्तमान में कोई व्यवहार्य प्रतिस्थापन नहीं है।

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

यह एक एकल उदाहरण है, लेकिन मेटाबॉक्स के अनुभव को कम करना एक स्वीकार्य समाधान नहीं है, जब तक कि गुटेनबर्ग समानता से परे नहीं है। WP 5.0 से ऐसा नहीं होगा

यहां गुटेनबर्ग के लिए "एकीकृत व्यवस्थापक" योजना का एक रोडमैप है जो वास्तव में काम करेगा:

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

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

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

गुटेनबर्ग एक अवधारणा कार की तरह है। अब वापस स्केल करें, और संपादक (नहीं संपादक पृष्ठ) के लिए एक पुनरावृत्ति सुधार जहाज। फिर, अगले एक या दो वर्षों में, आप प्रोजेक्ट को 100% व्यवस्थापक कवरेज की ओर ले जा सकते हैं।

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

आज तक ऐसा महसूस होता है कि जब मेरी दुनिया मेटा बॉक्स वर्डप्रेस के लिए एक _major_ विक्रय बिंदु रही है, क्योंकि कस्टम पोस्ट प्रकार आसानी से व्यापक उपयोग के लिए आसानी से उपलब्ध हो गया है। मुझे खुशी है कि यह चर्चा हो रही है।

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

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

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

बस मेरे दो सेंट, यहाँ परिणाम देखने के लिए आगे देख रहे हैं।

गुटेनबर्ग के साथ काम करने वाले प्लगइन्स की संख्या हमारे परीक्षणों के अनुसार 80%, 90% या 0% हो सकती है, इससे क्या बचा जाना चाहिए कि हजारों और हजारों साइट मालिकों को अपने आप से यह पता लगाना होगा कि उनका कॉन्फ़िगरेशन शायद काम करेगा या नहीं काम करेगा गुटेनबर्ग के साथ। यह समय (= पैसा) की भारी बर्बादी होगी, बहुत भ्रम पैदा करेगा और बहुत सारे भरोसे को मार देगा।

मैं प्लगइन्स / थीमों को संगत के रूप में चिह्नित करना चाहता हूं / Gutenberg के साथ संगत नहीं (या 'प्रासंगिक नहीं'), ताकि साइट के मालिकों को संभावित समस्याओं के बारे में सूचित किया जा सके, इससे पहले कि वे अपनी साइटों पर सक्रिय हो जाएं और तदनुसार कार्य कर सकें। डेटा न केवल प्लगइन मालिकों से, बल्कि बीटा परीक्षण समय (वास्तविक बीटा ...) के दौरान सामुदायिक परीक्षणों से भी आ सकता है, और यह समय-सीमा लंबी होनी चाहिए, न कि केवल कुछ सप्ताह।) और उससे आगे।

मुझे पता है कि यह कभी भी पूर्ण या 100% सटीक नहीं होगा, लेकिन सबसे प्रमुख प्लगइन्स के लिए यह योग्य होना चाहिए।

पुनश्च।
अपनी खुद की परियोजनाओं के लिए (एक ग्राहक के लिए एक इंट्रानेट माइक्रोसाइट्स प्लेटफॉर्म> 30.000 कर्मचारी, और छोटे व्यवसाय / गैर लाभ साइटों का एक समूह) हमने गुटेनबर्ग को तब तक निष्क्रिय करने का फैसला किया जब तक कि यह जंगली में कम से कम एक वर्ष सफलतापूर्वक न हो।

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

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

क्या मैं समझता हूँ कि एक बार में 0 से 100 तक पाने की इच्छा है। क्यों एक पुनरावृत्ति रिलीज यहाँ नहीं लिया जा रहा है? दो विकल्प 'ब्रेक नथिंग' या 'ब्रेक एवरीथिंग' क्यों हैं?

Metaboxes यही कारण है कि वर्डप्रेस जितना शक्तिशाली है उतना ही शक्तिशाली भी है। इसका उद्देश्य एडिट स्क्रीन का विस्तार करना है।

मुझे लगता है कि यह बहुत अच्छा है कि गुटेनबर्ग पूरे स्क्रीन को ओवरहाल करना चाहते हैं, लेकिन मुझे नहीं लगता कि यह एक बार में करना यथार्थवादी है, खासकर अगर इसका मतलब है कि वर्डप्रेस के सबसे महत्वपूर्ण घटकों में से एक का इलाज करना है (जहां तक ​​कि कस्टम विकास..जब तक। एक तरफ) के रूप में वर्डप्रेस की सफलता का एक बहुत बड़ा हिस्सा है।

2- गुटेनबर्ग केवल सामग्री क्षेत्र की जगह लेता है: 90% प्लगइन्स काम करते हैं, यूएक्स पीड़ित हैं

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

4- संगत प्लगइन्स के साथ गुटेनबर्ग: सर्वोत्तम संभव यूएक्स

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

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

मुझे वास्तव में यकीन नहीं है कि इसका क्या मतलब है। आप इस धारणा के साथ गुटेनबर्ग का निर्माण करना चाहते हैं कि सभी प्लगइन्स इसके साथ काम करते हैं, और विकल्प 2 और 3 को पेडल करने के लिए उस समाधान का उपयोग करें? पहले 2 की ओर भवन और फिर 3 की ओर चलना, क्या ऐसा नहीं है कि हमें 4 मिलने वाला है?

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

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

.. एक साधारण डेवलपर के रूप में मेरा धैर्य जिसने पूरे वर्ष वर्डप्रेस के लिए आगे के सर्वोत्तम संभव तरीके के बारे में सोचकर बिताया है, एक संपूर्ण (कोर और समुदाय) एक सीमा के करीब है।

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

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

मैं स्वीकार करता हूं कि कभी-कभी हम (कम से कम मैं) अपनी टिप्पणियों में बर्खास्त हो सकते हैं और मैं इसके लिए माफी मांगता हूं।

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

मुझे यह लिखने में दुःख होता है लेकिन मैं एक मिलियन वर्षों में किसी को भी वर्डप्रेस के साथ एक बड़ी परियोजना शुरू करने का सुझाव नहीं दूंगा।

2- गुटेनबर्ग केवल सामग्री क्षेत्र की जगह लेता है: 90% प्लगइन्स काम करते हैं, यूएक्स पीड़ित हैं

@youknowriad , आप कैसे कह सकते हैं कि यूएक्स गुटेनबर्ग बनाम

(१) अपना माउस खोलना।
(2) यदि आप मैक पर हैं, तो कमांड + f5 दबाएँ, और VoiceOver का उपयोग करके कुछ भी उत्पादक प्राप्त करने का प्रयास करें।
(3) यदि आप एक पीसी पर हैं, तो एनव्हिडिए डाउनलोड करें, इसे इंस्टॉल करें, अपने माउस को अनप्लग करें, और उसी टेस्ट को करें। उन परिस्थितियों में गुटेनबर्ग के साथ कुछ उत्पादक करने की कोशिश करें।

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

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

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

1. खुला स्त्रोत। मुझे लगता है कि यह दर्शक सहमत हो सकता है कि यह कितना शक्तिशाली और लाभप्रद है।
2. उपयोग में आसानी। WordPress ने गैर-डेवलपर्स के लिए सामग्री बनाना और अपडेट करना आश्चर्यजनक रूप से आसान बना दिया। व्यक्तियों और व्यवसायों के लिए वेबसाइट बनाने के मेरे शुरुआती वर्षों में यह बहुत बड़ा था।
3. सामग्री को परिभाषित करना। कस्टम पोस्ट प्रकार, कस्टम टैक्सोनॉमी और कस्टम मेटा बॉक्स। जब इन तक पहुंचने वाली हर चीज एक विलक्षणता तक पहुंच गई, तो मुझे नहीं लगता कि जब मैं कह रहा हूं कि यह तब पहुंच रहा है जब वर्डप्रेस व्यापारिक समुदाय के लिए "बिक्री योग्य" था और केवल ब्लॉग सॉफ्टवेयर से अधिक था। (वर्डकैम्प फीनिक्स 2012 - सीएमबी। जस्टिन टडलॉक के पोस्ट प्रकार, करोनॉमी और मेटो बॉक्स को परिभाषित करने पर शानदार लेखन।)

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

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

@jchristopher इसे बहुत अच्छी तरह से कहते हैं:

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

@jnicol और @aurooba शानदार अंक बनाते हैं और अच्छे प्रश्न पूछते हैं। ऐसा क्यों दिखाई देता है जैसे कि एक पुनरावृत्ति रोडमैप के बजाय यह सब या कुछ भी नहीं है? योस्ट का विकल्प जितना देखा गया है उससे कहीं अधिक समझदार है और मुझे लगता है कि "iframe प्रयोग" उस बिंदु को साबित करता है। पहुँच समस्याओं के समाधान के लिए, @amandarush , धन्यवाद। मैं हर किसी को चुनौती देता हूं कि वह गुटेनबर्ग के साथ काम करने की कोशिश करे जिस तरह से वह उल्लिखित है। यह कुछ दृष्टिकोण बदल सकता है।

@ARonjorbin ने पहले कहा था, जब कोई वर्डप्रेस को अपनाता है, तो वे वर्डप्रेस (संस्करण-संख्या-यहाँ) को नहीं अपना रहे हैं, वे वर्डप्रेस को समग्र रूप से अपना रहे हैं।

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

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

एक साधारण डेवलपर के रूप में मेरा धैर्य जिसने पूरे साल वर्डप्रेस के लिए आगे के सर्वोत्तम संभव तरीके के बारे में सोचकर बिताया है (कोर और समुदाय) एक सीमा के करीब है।

मैं कुंद होने जा रहा हूँ, यहाँ:

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

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

वैकल्पिक रूप से (और यह बेहतर होगा), इन विचारों को लें। सच में विचार करें कि लोग क्या कह रहे हैं। हमारी चिंताओं को उन लोगों के रूप में समझें जो व्यवसाय चलाते हैं जो वर्डप्रेस का उपयोग करते हैं और समझते हैं कि हम न केवल अपने लिए, बल्कि हमारे ग्राहकों के लिए चिंतित हैं।

मैं 2008 की शुरुआत से WP का उपयोग कर रहा हूं, और मैं एक नई सुविधा या निर्णय के बारे में नहीं सोच सकता हूं जिसने उस समय में सभी के रूप में उतना ही विभाजन बनाया है, जितना कि वर्तमान स्वरूप में, गुटेनबर्ग की शुरुआत के रूप में।

हालांकि वर्डप्रेस उपयोगकर्ताओं के उद्देश्य से है, लेकिन यह एक उपकरण है, और यदि वे अपने लक्ष्यों को प्राप्त करने में मदद करने के लिए WP पेशेवरों के पास नहीं हैं, तो उपयोगकर्ता बस उस टूल का उपयोग करने में सक्षम नहीं होंगे।

मैं ताज़े इंस्टॉल के उपयोगकर्ताओं को पूरा करने के लिए (क्या? ~ प्रति वर्ष वेब वृद्धि का 1%?) के संदर्भों को देख रहा हूं, लेकिन यह मौजूदा उपयोगकर्ता नाम (~ 28%) की लागत पर लगता है। जिसमें से अधिकांश में एक प्लगइन चलने की संभावना है जिसमें कम से कम एक मेटा बॉक्स हो। यह किसी भी पैमाने पर खराब व्यापारिक समझ की तरह लगता है।

मुझे विचारधारा मिलती है: एक सर्वश्रेष्ठ केस एडिटर बनाएं, फिर नए से पुरानी बात करने के लिए एडेप्टर पैटर्न का उपयोग करें। मुसीबत यह है, PHP और JS अलग-अलग प्रौद्योगिकियां हैं, और HTML iframes की भूमि में उस मुद्दे को पारित करना व्यवहार्य नहीं है, जो पहले दिए गए सभी कारणों से है।

यह पहला पास था, यह एक प्रयोग था, लेकिन यह प्रयास सफल नहीं है। जितनी जल्दी स्वीकार किया जाता है, उतनी जल्दी हम अगले सुझाव पर आगे बढ़ सकते हैं।

जब कोई मेटा बॉक्स के मामले की बात आती है तो कोई भी उपयुक्त समाधान नहीं करता है, जो सभी पक्षों को संतुष्ट करता है।

इसका मतलब है कि एक पक्ष को relent करने की आवश्यकता है - और चाहे वह 10-50 प्रो-गूटेनबर्ग डेवलपर्स हो, या सैकड़ों / हजारों डेवलपर्स जो _scared_ हैं या उन परिवर्तनों का प्रभाव उनके लिए होगा, अकेले अपने उपयोगकर्ताओं को दें, हम देखेंगे।

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

मूल प्रश्न पर वापस जाने के लिए - क्या मेटा बॉक्स के लिए दीर्घकालिक समाधान है? कई डेवलपर्स (और चलो भूल नहीं करते, वे उपयोगकर्ता भी हैं) ने समझाया है कि उत्तर क्यों नहीं है।

हम यहाँ काफी हद तक रचनात्मक चर्चा कर रहे हैं। याद है:

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

मुझे हर किसी को याद दिलाना है कि गुटेनबर्ग में मेटाबॉक्सेस एक @ बीई-वेबसाइड कदम था और इसे स्वतंत्र रूप से हर किसी से थोड़ी मदद के साथ, कहीं से भी बाहर निकलने का परिणाम था। अगर यह @ BE-Webdesign के लिए नहीं होता, तो गुटेनबर्ग में कोई मेटाबॉक्स नहीं होता। यहां छोड़ी गई 47 टिप्पणियों में से, केवल 2 लोगों ने वास्तव में समीक्षा और यूएक्स उद्देश्यों के लिए मेटाबॉक्स कोड को छुआ।

हालांकि यहाँ मूलभूत समस्या यह है कि सुरक्षित रूप से असुरक्षित कोड के निर्माण के बिना पेज पर मेटाबॉक्स को सुरक्षित रूप से कैसे लाया जा सकता है, जिससे हैकी कल्ज का एक ट्रेडऑफ हो सकता है या गेटा हो सकता है।

• पहले पुनरावृत्ति में एक गोच शामिल था, WP दिखा रहा है कि यह edit.php पृष्ठ पर था, और इस तरह मेटाबॉक्सेस उत्पन्न करता है। प्रारंभिक रिपोर्टों ने संकेत दिया कि इसमें संगतता की समस्याएं थीं और यह सुपर हैकी था, और एक व्यवहार्य समाधान नहीं था। ऐसा इसलिए है क्योंकि बहुत से प्लगइन्स केवल मेटाबॉक्स को पंजीकृत करते हैं यदि कुछ परिस्थितियों को पूरा किया जाता है और उन्हें प्रस्तुत करने के लिए पता करने के लिए WP पर भरोसा नहीं है
• दूसरा पुनरावृत्ति जो मिला है, आइफ्रेम का उपयोग करता है, इसलिए मेटाबॉक्स क्लासिक संपादक में दिखाई दे रहे हैं, भले ही सब कुछ के साथ लेकिन मेटाबॉक्स हटा दिया गया। यह थोड़ा कठिन है, लेकिन इसमें मेटाबोक्स काम कर रहे हैं, मुद्दों के साथ
• वहाँ भी एक समाधान है जहाँ हम HTML कोड लाते हैं और फिर इसे एक घटक में थोक में डालते हैं, जो सुपर स्पष्ट समाधान होने के बावजूद एक सुरक्षा तबाही होगी। इसलिए ऐसा क्यों नहीं किया गया।

मेरा सुझाव है:

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

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

• हम iframe बकवास से बचें
• मेटाबॉक्सेस काम करते हैं जैसे उन्होंने हमेशा किया है जहां तक ​​पंजीकरण का संबंध है
• मौजूदा JS अपेक्षा के अनुरूप काम करता है, और PHP अंत में चीजों को काम करने के लिए कोई हैक आवश्यक नहीं है

इसके अलावा, योस्ट डिजाइन बहुत सुंदर है, लेकिन ब्लॉक मेटा कहां जाता है?

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

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

मुझे हर किसी को याद दिलाना है कि गुटेनबर्ग में मेटाबॉक्सेस एक @ बीई-वेबसाइड कदम था और इसे स्वतंत्र रूप से हर किसी से थोड़ी मदद के साथ, कहीं से भी बाहर निकलने का परिणाम था। अगर यह @ BE-Webdesign के लिए नहीं होता, तो गुटेनबर्ग में कोई मेटाबॉक्स नहीं होता।

हालांकि प्रशंसा और प्रशंसा अच्छा है 😄, मुझे निश्चित रूप से मदद मिली थी, और यह काफी हद तक कई लोगों की टीम का प्रयास है।

मेरा सुझाव है:

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

हां, यह सबसे अधिक संभावना है कि अगली पुनरावृत्ति, और मुझे लगता है कि यह एक महान सुझाव है और साथ ही एक रचनात्मक विचार भी है। 100% निश्चित नहीं है कि यह सफाई से अभी तक कैसे किया जाए, लेकिन यह पूरी तरह से iframes का उपयोग नहीं करने के लिए संभव है, और इसमें वही सुधारित UX है जो गुटेनबर्ग पहले से ही प्रदान कर रहा है। मेटा बॉक्स के अनुभव को बेहतर बनाने के लिए अपडेट आते रहेंगे, जिसमें संभवत: iframes को खत्म करना शामिल होगा। Iframe पद्धति ने यह देखने के तरीके के रूप में कार्य किया है कि मेटा बॉक्स समर्थन कैसे लागू किया जा सकता है, अब बेहतर सुधार किए जाएंगे। जब चीजों को पहली बार कई महीनों पहले मेटा बॉक्स के साथ खोजा जा रहा था (एक नया विषय नहीं), तो गुटबर्ग की स्थिति के कारण, iframe दृष्टिकोण के साथ आगे बढ़ना समझ में आता था, अब यह विलय हो गया है और कई अन्य टुकड़े स्थानांतरित हो गए हैं लगभग, iframes का उपयोग संभवतः तकनीकी दृष्टिकोण से आवश्यक नहीं है। अधिक परिश्रम करना होगा।

@ BE-Webdesign आपके प्रयासों और यहाँ इनपुट के लिए धन्यवाद। चलिए इसे बंद करते हैं और एक नया मुद्दा शुरू करते हैं जब वह दृष्टिकोण चर्चा के लिए तैयार होता है।

कृपया रुकें और पुनर्मूल्यांकन करें, बाद में नहीं

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

चर्चा के लिए सभी को धन्यवाद। मुझे खुशी है कि विषय के मुद्दे के अंत में refocused बातचीत: _ iframe व्यवहार्य में मेटा-बॉक्स के लिए वर्तमान दृष्टिकोण? उत्तर नहीं होने के साथ। Iframes एक कार्यान्वयन विवरण है जो मुझे लगता है कि हम अपेक्षाकृत आसान छोड़ सकते हैं। तो चलिए उस पर ध्यान केंद्रित करते हैं।

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

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

@mtias मैं वास्तव में आपकी समझदार टिप्पणी की सराहना

दुर्भाग्य से यह पूरी तरह से इस बात पर है कि इस धागे में @youknowriad क्या संचार कर रहा है, और जब से आप दोनों Automattic में काम करते हैं, मैं आपसे उत्पाद दिशा के बारे में बात करने का आग्रह करता हूं, क्योंकि अभी हमें मिश्रित संकेत मिल रहे हैं।

दुर्भाग्य से, आपने प्रस्तावित Yoast स्केच को संबोधित नहीं किया, जो हमें मौजूदा मेटाबॉक्सेस के साथ संगत होने के दौरान गुटेनबर्ग के सभी लचीलेपन को देगा। कोई यह क्यों नहीं स्वीकार कर सकता है कि आप इस दृष्टिकोण पर विचार क्यों नहीं कर रहे हैं?

दुर्भाग्य से जो @youknowriad इस धागे में संचार कर रहा है के साथ पूरी तरह से बाधाओं पर है

मुझे लगता है कि आपने अभी जो कुछ कहा, उसे गलत समझा, मैं सिर्फ तथ्यों की गणना कर रहा था और मैं @mtias के विचारों को 100% साझा करता

@mtias

कुछ लोगों ने जिसे व्यावहारिक दृष्टिकोण के रूप में कहा है, वह इस दिशा से शुरू की गई डिजाइन दिशा के अनुरूप नहीं है - पूर्ण साइट अनुकूलन की ओर बढ़ रहा है

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

उस मध्यस्थ परिवर्तन को सुचारू रूप से करने के बाद, आप post_edit स्क्रीन पर डायरेक्ट DOM जेनरेशन / मैनिपुलेशन को अपदस्थ करना बहुत आसान बना देंगे, क्योंकि तब तक, मानक, इन-प्रैक्टिस समाधान में अब इस तरह के हेरफेर शामिल नहीं होंगे। मुझे विश्वास नहीं है कि कोई भी कह रहा है "प्रत्यक्ष डोम हेरफेर को हमेशा के लिए प्राथमिक अनुभव होने की आवश्यकता है"। वे कह रहे हैं "यह अब प्राथमिक समाधान है"।

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

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

यह परियोजना के लक्ष्यों के साथ विश्वासघात नहीं कर रहा है, केवल हजारों एजेंसियों और डेवलपर्स के लिए परिवर्तन को अधिक प्रबंधनीय बनाने के लिए रिलीज़ शेड्यूल को संबोधित कर रहा है।

@youknowriad मुझे जो कुछ मैं कह रहा हूँ, उसका समर्थन करने के लिए आपने जो लिखा है, उसके कुछ स्निपेट पोस्ट करें:

REST API, क्लाइंट-साइड UI और यूनिफ़ॉर्म कोर अवधारणाओं को एकीकृत करके: एक अद्वितीय अवधारणा "A ब्लॉक" के तहत विजेट, शॉर्टकोड, ब्लॉक, सामग्री मेटाबेस

किसी ने भी "कंटेंट मेटाबॉक्सेस" को ब्लॉकों में बदलने के लिए नहीं कहा, और जब तक गुटेनबर्ग ने इसका प्रारंभिक संस्करण नहीं भेजा, तब तक इसका संचार नहीं हुआ। वास्तव में, यह वही है जो तर्क के बारे में है। मैं यह नहीं दोहराऊंगा कि दूसरों ने क्या बेहतर कहा है, बस मेटाबोक्स बहुत बार पृष्ठ सामग्री नहीं है।

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

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

शॉर्टकोड, टाइनीएमसीई बटन और मेटाबॉक्स के बीच अंतर क्या है?
मुख्य अंतर यह है कि "मेटाबोक्स" का कोई "उद्देश्य" नहीं है, यह सिर्फ एक तरीका है जिसमें संपादक पृष्ठ को निरंतरता के बिना विस्तारित किया जा सकता है जबकि शॉर्टकोड और टाइनीमेसी बटन में एक है।

यह एक विशाल ग़लतफ़हमी है, जिसे आटोमैटिक के भीतर भौहें उठानी चाहिए। (और मुझे आशा है कि @mtias और @m सुन रहे हैं)। यह केवल सच नहीं है और मैं वास्तव में इस कथन के बाद आपके निर्णय पर सवाल उठाता हूं।

क्या हम यह निष्कर्ष निकाल सकते हैं कि वर्डप्रेस की लंबी अवधि के लिए, मेटाबॉक्स अपने विकास (गुटेनबर्ग की परवाह किए बिना) को बंद कर रहे हैं?
हाँ वे हैं।

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

मैं @mtias पर भी सवाल

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

@mtias ,

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

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

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

वहाँ लोग हैं, जो डिफ़ॉल्ट गुटेनबर्ग अनुभव से लाभ उठा सकते हैं अभी।

पूर्ण रूप से। लेकिन वहाँ भी एक बहुत अधिक संख्या है जो अभी डिफ़ॉल्ट गुटेनबर्ग के साथ एक हानिकारक अनुभव होगा।

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

@khromov , इस परियोजना के डिजाइन लीड के रूप में, जैसे

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

@khromov

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

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

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

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

मुद्दा यह नहीं है कि मेटाबेस को ब्लॉक प्रतिमान के अंदर फिर से बनाया नहीं जा सकता है, वास्तव में, गैर-फ्रंट-एंड ब्लॉक जिन्हें प्रोग्रामेटिक रूप से पोस्ट प्रकार में जोड़ा जाता है, जगह में लॉक किया जाता है, और पोस्ट-मेटा के बजाय स्टोर पोस्ट-कॉन्टेंट के लिए स्लेट किया जाता है। वर्डप्रेस 5.0 रिलीज़ (मुझे गलत होने पर सही करें)।

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

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

यह वर्तमान स्थिति डेवलपर्स के लिए भी समस्या का कारण बनती है। उदाहरण के लिए, यदि आप फ़ील्ड के लिए Piklist के साथ Visual Composer का उपयोग करते हैं, तो Piklist आपके कई व्यवस्थापक शैलियों को ओवरराइड कर देगा, जिससे VC को नेविगेट करना बहुत मुश्किल हो जाएगा।

या यदि आप WooCommerce का उपयोग किसी भी प्लगइन के साथ कर रहे हैं जो Select2 लाइब्रेरी के नए संस्करण को जोड़ते हैं, तो एक या दूसरा आपके व्यवस्थापक इंटरफ़ेस को तोड़ देगा, एक महत्वपूर्ण JS त्रुटि के साथ।

एक ही बात हो सकती है अगर दो अलग-अलग प्लगइन्स CMB2 ढांचे के विभिन्न संस्करणों पर भरोसा करते हैं।

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

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

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

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

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

दुर्भाग्य से यह पूरी तरह से इस बात पर है कि इस धागे में @youknowriad क्या संचार कर रहा है, और जब से आप दोनों Automattic में काम करते हैं, मैं आपसे उत्पाद दिशा के बारे में बात करने का आग्रह करता हूं, क्योंकि अभी हमें मिश्रित संकेत मिल रहे हैं।

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

यह स्पष्ट है कि आटोमैटिक से जुड़ी गुटेनबर्ग टीम एक इंच भी नहीं हिल रही है और सभी आलोचनाओं को खारिज कर रही है।

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

मैं स्पष्ट बताना चाहूंगा, लेकिन

Automattic वर्डप्रेस को "रिलीज़" या "बिल्ड" नहीं करता है, और Gutenberg एक ऑटोमैटिक उत्पाद नहीं है

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

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

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

@karmatosed

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

इसके बावजूद, मेरे पास @youknowriad के साथ एक निजी चैट

@tomjn

मैं आदरपूर्वक असहमत हूं। महत्वपूर्ण निर्णय आटोमैटिशियनों द्वारा किए जाते हैं, और

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

कोई यह क्यों नहीं स्वीकार कर सकता है कि आप इस दृष्टिकोण पर विचार क्यों नहीं कर रहे हैं?

@khromov हम पहले से ही था, और संपादक चैट में कुछ अन्य स्थानों पर, आदि विशेष रूप से यह मुद्दा iframe कार्यान्वयन के बारे में था।

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

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

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

एक समय में एक कदम आगे बढ़ना, किसी भी तरह से, परियोजना के लक्ष्यों से समझौता नहीं करता है।

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

पूर्ण रूप से। लेकिन वहाँ भी एक बहुत अधिक संख्या है जो अभी डिफ़ॉल्ट गुटेनबर्ग के साथ एक हानिकारक अनुभव होगा।

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

@gschoppe मुझे पता है कि हमारे पास अतीत में असहमति का हमारा उचित हिस्सा था, लेकिन मैं यहां आपकी टिप्पणियों की सराहना करता हूं और विभिन्न बिंदुओं के माध्यम से भी भाग लेने की इच्छा। आप ब्लॉक के महत्वपूर्ण कारक के बारे में कुछ अच्छे बिंदु बनाते हैं। हो सकता है कि एक दिन हम WC सम्मेलन में मिलेंगे और हम थेरस विरोधाभास के जहाज पर एक मजेदार दार्शनिक चर्चा पर लग सकते हैं। कौन जाने। 😉

आटोमैटिक से आपको शिकायत नहीं करनी चाहिए कि हम आपके काम का सम्मान नहीं कर सकते हैं, और हम आपको बहुत जोर दे रहे हैं।
7000 के लिए नहीं - 10.000 € प्रो महीने का वेतन जो आपको मिलता है। बेवकूफ। ऐसा नहीं है जब लोग WP Trac पर डेवलपर्स स्वयंसेवकों से शिकायत करते हैं।
अगर गुटेनबर्ग आपको सिरदर्द देता है तो अपने बॉस से बात करें। उसने आपको असंभव कार्य करने के लिए दिया।

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

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

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

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

@StaggerLeee कृपया इस परियोजना में सभी के लिए सम्मानजनक

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

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

आटोमैटिक से आपको शिकायत नहीं करनी चाहिए कि हम आपके काम का सम्मान नहीं कर सकते हैं, और हम आपको बहुत जोर दे रहे हैं।
7000 के लिए नहीं - 10.000 € प्रो महीने का वेतन जो आपको मिलता है। बेवकूफ। ऐसा नहीं है जब लोग WP Trac पर डेवलपर्स स्वयंसेवकों से शिकायत करते हैं।
अगर गुटेनबर्ग आपको सिरदर्द देता है तो अपने बॉस से बात करें। उसने आपको असंभव कार्य करने के लिए दिया।

@StaggerLeee मेरी इच्छा है कि मुझे भुगतान किया गया था कि ज्यादा संकेत Autom लेकिन आटोमैटिक Google नहीं है, और मैं WP दुनिया में कहीं और कमा सकता हूं। यहां मेरी खुद की उपस्थिति विशुद्ध रूप से मेरी खुद की पीठ से दूर है, मुझे यहां रहने के लिए भुगतान नहीं किया जाता है, और न ही इस पर काम करने वाले अन्य लोग हैं। मुझे वास्तव में कोड समीक्षा करने और एंटरप्राइज़ क्लाइंट लॉन्च करने में मदद मिली है!

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

Iframes से संबंधित लोगों के लिए , मैं यहाँ इस Pull अनुरोध (https://github.com/WordPress/gutenberg/pull/3345) को देखने का सुझाव देता हूं, जो iframes को पूर्ववत करने और पहले किए गए मेरे सुझाव को लागू करने का प्रयास कर रहा है।

मेटाबॉक्सिस कार्यान्वयन के अगले पुनरावृत्तियों के रूप में, संगतता मुद्दों का परीक्षण और पहचान करना अच्छा होगा, ए 8 सी की ओर सड़े हुए फल फेंकना अच्छा लग सकता है लेकिन यह मदद नहीं करता है।