Gutenberg: ब्लॉक जोड़ें: अनुभाग

मुझे सचमुच यह विचार पसंद है! मुझे यह भी पसंद है कि इसकी पृष्ठभूमि सेटिंग है।

अच्छा! क्या होगा अगर ब्लॉक ने तीन 'उन्नत' सेटिंग्स की अनुमति दी:

• .child_class, .child_class_1 बच्चों पर क्रमबद्ध किए जाने वाले वर्ग-नाम को परिभाषित करें
• वैकल्पिक प्रथम चाइल्ड क्लास .child_class, .child_class_1, .child_class_first
• एक वैकल्पिक अंतिम चाइल्ड क्लास .child_class, .child_class_n, .child_class_last

:nth-child चयनकर्ता अंतिम दो के लिए क्षतिपूर्ति करने में सक्षम हो सकते हैं, लेकिन मुझे लगता है कि सभी बच्चों के लिए एक वर्ग जोड़ना कुछ संदर्भों में उपयोगी हो सकता है।

इस विचार से प्यार करो। अगर बैकग्राउंड और टेक्स्ट कलर्स में बदलाव किया जा सकता है, तो इससे लिंक कलर्स को भी जोड़ा जा सकता है।

उत्कृष्ट विचार। यह वास्तव में गुटेनबर्ग संपादक के लिए बहुत अधिक मूल्य जोड़ देगा।

सिर्फ कॉलम कॉलम से बहुत बेहतर है, जिसमें बहुत सारे मुद्दे हैं। ठंडा!

यह पहली चीज है जिसे मैंने बनाया था जब मैंने देखा कि घोंसला बनाना उपलब्ध था। मेरा संस्करण समान है सिवाय इसके कि मैंने कल्पना की थी कि आप इसमें कॉलम ब्लॉक जोड़ देंगे।

क्या आपके पास इसके लिए कोड उपलब्ध है?

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

जब तक आप कॉलम ब्लॉक के अंदर कॉलम ब्लॉक नहीं डाल सकते put

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

एक खंड ब्लॉक जो नंगे आवरण की तरह काम करता है, मुझे लगता है कि सबसे अधिक लचीला होगा। (के रूप में स्तंभ ब्लॉक घोंसला करने में सक्षम हो जाएगा!)

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

हाँ, मुझे लगता है कि @jvisick जैसे बहु-स्तंभ अनुभाग उपरोक्त उदाहरण असामान्य नहीं हैं। पृष्ठभूमि / पाठ विकल्पों के साथ एक कंटेनर जो ब्लॉक को घोंसला देता है वह सबसे लचीला दृष्टिकोण होगा। चूँकि अब हमारे पास एक कार्यशील स्तंभ ब्लॉक है, इसलिए हम कॉलम विकल्प को इसमें से निकालने पर भी विचार कर सकते हैं।

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

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

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

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

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

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

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

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

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

# 6461 देखें।

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

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

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

# 6461 में कुछ चर्चा के बाद, मैंने फैसला किया है कि मेरा रो ब्लॉक + कॉलम ब्लॉक विचार जाने का सही तरीका नहीं है। # 5351 (टिप्पणी) में एक के समान एक लेआउट ब्लॉक शायद कम भ्रमित और कहीं अधिक लचीला होगा। जो भी हो, निश्चित रूप से एक खंड खंड होना चाहिए, और मुझे लगता है कि वर्डप्रेस 5.0 रिलीज से पहले इसे निश्चित रूप से जोड़ा जाना चाहिए।

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

2 अलग चौड़ाई सेटिंग्स होने के बजाय सेक्शन ब्लॉक्स को नेस्ट करने के लिए, मुझे लगता है कि यह काम कर सकता है। मेरे पास सबसे बड़ी चिंता अतिरिक्त ब्लॉकिंग की मात्रा को लेकर होगी जो कि सेक्शन ब्लॉक्स को जोड़कर होगी, जो पैडिंग विकल्प में ले जाती है।

मुझे लगता है कि यह जरूरी है कि सेक्शन ब्लॉक में पैडिंग की मात्रा को अनुकूलित करने की क्षमता हो या कम से कम डिफॉल्ट पैडिंग को हटाने की क्षमता हो। निश्चित रूप से, यह सवाल उठाता है कि जब आप किसी अन्य ब्लॉक में नेस्टेड होते हैं तो आप सेक्शन ब्लॉक का चयन कैसे करेंगे। मुझे लगता है कि इस मुद्दे को # 6471 और try/alternate-hover-approach शाखा में काम किया जा रहा है जैसे सुधारों द्वारा हल किया जाएगा।

: +1:

हमें वास्तव में एक सामान्य पंक्ति / कंटेनर ब्लॉक की आवश्यकता है, विशेष रूप से चौड़ाई सेटिंग्स के साथ।

आदर्श रूप से मुझे लगता है कि "पृष्ठभूमि का रंग" और "पाठ का रंग" जैसी अन्य सेटिंग्स को प्रत्येक ब्लॉक पर कुछ "अतिरिक्त" सेटिंग्स टैब के तहत रहना चाहिए (कई अन्य सामान्य रूप से लागू सीएसएस सेटिंग्स के अलावा)।

जहाँ तक जवाबदेही की बात है, मुझे लगता है कि हमें "उत्तरदायी" ब्लॉक को

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

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

@tmdesigned यह वेबपृष्ठ की शैली, स्वरूपण और लेआउट पर सुविधा-पूर्ण और सहज ज्ञान युक्त WYSYWIG नियंत्रण पर समाप्त होता है। क्या यह गुटेनबर्ग का लक्ष्य नहीं है?

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

अंत में विचार यह है कि हम अब जो काम कर रहे हैं, उसमें सीएसएस को कम करना है, चाहे वह हैकेसी सीएसएस को लिखना हो, या फिर दोहराए जाने वाले सामग्री कार्यों को करना हो।

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

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

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

यदि आप चाहें, तो आप ऐसा करने के लिए पढ़ सकते

मैंने एक एपीआई के लिए आपका सुझाव पढ़ा और यह महत्वपूर्ण नहीं है कि मैं एक जोड़ा हुक के बारे में क्या कह रहा हूं ताकि कुंजी मूल्य जोड़े को जोड़ा जा सके।

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

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

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

@tmdesigned मैं आपकी प्रतिक्रिया की सराहना

लक्ष्य सीएसएस कक्षाओं की मात्रा को कम करने या कम करने का नहीं है।

लक्ष्य विशेष रूप से, एक यूआई में या कम से कम एक एपीआई में उपयोगकर्ता-परिभाषित ब्लॉक स्टाइलिंग सेटिंग्स को एकीकृत करने के लिए है।

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

उनके पास बिल्कुल वही कक्षाएं होंगी जो वे अब करते हैं और उनके पास ठीक वही लेआउट होगा जो वे अब करते हैं।

परंतु

जिस समय ब्लॉक डेवलपर को पता चलता है कि उनके पास CSS संपत्ति (ies) है जिसे उपयोगकर्ता द्वारा कॉन्फ़िगर

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

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

इस धागे पर इतना शोर पैदा करने के लिए क्षमा करें। हमें संभवतः संबंधित मुद्दे पर और चर्चा करनी चाहिए।

नोट संपादित करें:

मैं अमूर्तता के बारे में बात करना भूल गया।

जिस मिनट में उपयोगकर्ता को एक ही ब्लॉक में दो बार सटीक एक ही शैली को लागू करने की आवश्यकता होती है वह सटीक क्षण होता है कि उपयोगकर्ता द्वारा परिभाषित शैली सेटिंग्स को सीएसएस कक्षाओं (उस ब्लॉक के लिए) को छोड़ दिया

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

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

एफडब्ल्यूआईडब्ल्यू, मुझे लगता है कि उत्पन्न कक्षाओं का आपका विचार आउटपुट है, ताकि यह अभी भी ओवरराइड-सक्षम डब्ल्यू / उपयोग करने के लिए महत्वपूर्ण हो!

@rchipka @tmdesigned मुझे पता है कि यह दो सप्ताह पहले खत्म हो गया था, लेकिन क्या आप किसी अन्य मुद्दे में उन विवरणों में से कुछ को हैशिंग में दिलचस्पी लेंगे? मुझे लगता है कि इस कॉनवो पर अधिक नज़र रखना फायदेमंद होगा।

पिछली बातचीत के आधार पर इस ब्लॉक पर एक और नज़र डालें।

मेरे विचारों को साझा करने का सबसे आसान तरीका एक प्रोटोटाइप के माध्यम से है: https://wp.invisionapp.com/share/PQJPPAX4JZW

कुछ नोट:

• एक त्वरित सर्वेक्षण के आधार पर: https://wordpress.slack.com/archives/C02QB2JS7/p152728319900034343 मैंने नाम बदलकर _Section_ से _Container_ कर दिया है।
• मैंने कॉलम सेटिंग्स को हटा दिया है, क्योंकि यह उचित है कि लोग @jvisick द्वारा सचित्र एक विशेष खंड के भीतर कॉलम-मैच को मिलाना चाहेंगे।
• बैकग्राउंड कलर के अलावा, मैंने बैकग्राउंड इमेज सपोर्ट जोड़ा है। सेटिंग्स कोर के मौजूदा बैकग्राउंड इमेज फीचर पर आधारित हैं।
• क्या हम लोगों को एक कंटेनर ब्लॉक में एक कंटेनर ब्लॉक घोंसला बनाने देना चाहिए?

@melchoyce बहुत अच्छा लग रहा है!

एक अच्छी विशेषता जिसे मैं देखना चाहूंगा, निरीक्षक में <aside> , <div> , और <section> बीच ब्लॉक का HTML तत्व स्विच करने के लिए एक चयन है।

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

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

घोंसले के कंटेनरों में सक्षम होने के लिए @melchoyce +1।

@SuperGeniusZeb HTML तत्व को बदलने में सक्षम होने के कारण मेरे दिमाग के पीछे भी है। शायद अर्थ तत्व विकल्पों के लिए एक गिरावट?

@jvisick हाँ, यही मैं सोच रहा था। बीवर बिल्डर और एलीमेंटर दोनों की सेटिंग उनकी पंक्तियों / अनुभागों जैसी होती है।

@melchoyce मुझे लगता है कि कंटेनरों को असीम रूप से

जेनरिक कंटेनर ब्लॉक में नेस्टिंग सीमाएं जोड़ने का कोई कारण नहीं है।

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

@chriskmnds अच्छी बात है। मुझे लगता है कि कंटेनर टैग सेट करने के लिए यह गलत जगह है।

कंटेनर ब्लॉक शब्दार्थ अर्थ के बिना एक सामान्य कंटेनर के रूप में कार्य करना चाहिए।

सिमेंटिक अर्थ (भविष्य) ब्लॉक टेम्प्लेट की कार्यक्षमता द्वारा प्रदान किया जाना चाहिए, ताकि <aside> सामग्री टेम्पलेट का एक हिस्सा हो सके और <section> एक और।

इस तरह, उपयोगकर्ता कंटेनरों में सामग्री को व्यवस्थित कर सकते हैं, हालांकि वे चाहते हैं (किसी भी गहराई स्तर पर), अर्थ अर्थ को प्रभावित किए बिना।

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

सिमेंटिक अर्थ (भविष्य) ब्लॉक टेम्प्लेट कार्यक्षमता द्वारा प्रदान किया जाना चाहिए, ताकि <aside> सामग्री टेम्पलेट का एक हिस्सा हो सके और <section> एक और।

यह निश्चित रूप से अच्छा होगा।

मैं आधार यूएक्स को सरल रखने के लिए किए गए बिंदुओं से असहमत नहीं हूं, लेकिन फिर मैं पूछूंगा कि आप <section> , <nav> , <header> , आदि को कैसे जोड़ रहे हैं? एक सामान्य कंटेनर ब्लॉक, जो मूल रूप से एक आवरण तत्व है, एक प्राकृतिक विकल्प की तरह लगता है। इनमें से प्रत्येक मामले के लिए एक डुप्लिकेट ब्लॉक की तुलना में पसंद किया जा सकता है। डिफ़ॉल्ट <div> और उपयोगकर्ता को कभी भी सेटिंग को स्पर्श करने की आवश्यकता नहीं होती है।

क्या होगा यदि HTML तत्वों के विकल्प संरेखित / पूर्ण सेटिंग्स के समान कार्य करते हैं जहां विषय या प्लगइन से समर्थित तत्वों की एक सरणी सेट की जा सकती है?

@jvisick आदर्श रूप से, इन रैपिंग तत्वों को एक पृष्ठ / पोस्ट के "ब्लॉक लेआउट टेम्पलेट" के साथ बनाया जाएगा।

ब्लॉक लेआउट टेम्प्लेट का उपयोग करके, आप डिफॉल्ट कंटेनर ब्लॉक्स का एक समूह सेट कर सकते हैं और कंटेनर ब्लॉक के उत्पन्न टैग नाम के लिए सेटिंग (कोड में) प्रदान करें।

@rchipka मैं देखता हूं कि आप लेआउट टेम्प्लेट का उपयोग करके कहां से आ रहे हैं जो उपयोगकर्ताओं को सामग्री प्रबंधित करने के लिए पूर्वनिर्धारित क्षेत्र देते हैं। मैं इसे गुटेनबर्ग के उपयोग के एक परिप्रेक्ष्य से पेज बनाने वाले के रूप में परिभाषित कर रहा हूं जो उन पृष्ठों के लिए है जो परिभाषित नहीं हैं और जिसमें यह निर्धारित करने में सक्षम है कि संपादक से किस प्रकार का HTML तत्व उपयोग किया जाता है। मुझे लगता है कि दोनों परिदृश्य महत्वपूर्ण हैं।

उस ने कहा, मैं @melchoyce से सहमत

अनुभाग अनिवार्य रूप से 1-स्तंभ हैं .. अच्छी तरह से, कॉलम।

मैं 3.0.0 कॉलम (बीटा) ब्लॉक को देख रहा हूँ, इसके स्लाइडर पर 1-कॉलम की अनुमति नहीं देता।

यह सुनिश्चित नहीं है कि डब्ल्यू / केवल कॉलम को चारों ओर से चिपकाने और इन कार्यान्वयनों को संयोजित करने के लिए बेहतर होगा। नकारात्मक पक्ष क्या है?

एक चीज जो जोड़ना अच्छा होगा वह है टॉगल कि क्या कंटेनर (खंड) पूरी चौड़ाई या सम्‍मिलित होना चाहिए। यदि यह निहित है तो इसे थीम में content_width सेट (# 5650) का सम्मान करना चाहिए, अन्यथा, इसकी पूरी चौड़ाई होनी चाहिए। मुझे लगता है कि पेज बिल्डरों के बहुमत में यह सुविधा है।

हाँ, यह मेरे पिछले मज़ाक में क्विक टूलबार में शामिल है।

@melchoyce ध्यान रखें कि ऐसी परिस्थितियां होंगी जहां अनुभाग / कंटेनर ब्लॉक स्वयं पूर्ण-चौड़ाई होना चाहिए, लेकिन अनुभाग / कंटेनर ब्लॉक के अंदर की सामग्री नहीं होनी चाहिए। यह कैसे संभाला जाएगा?

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

@melchoyce यह मानते हुए कि मैं आपको सही तरीके से समझता हूं, इसका मतलब है कि कंटेनर ब्लॉक पर चौड़ाई नियंत्रण केवल कंटेनर की पृष्ठभूमि को प्रभावित करेगा, और सामग्री कभी नहीं? यह समझ आता है। स्पष्टीकरण देने के लिए धन्यवाद। : +1:

हाँ, मैं यही सोच रहा हूँ!

निश्चित नहीं है कि अगर इस पर चर्चा की गई थी, लेकिन एक अनुभाग "अनुभाग" HTML तत्व हो सकता है और एक "लेख", "div", या कुछ और भी हो सकता है, है ना? यह चयन के रूप में अच्छा होगा
यह भी "पंक्ति" ब्लॉक को अनावश्यक बना सकता है, मुझे लगता है

इसे एक प्लगइन में लागू किया गया

var el = wp.element.createElement,
    registerBlockType = wp.blocks.registerBlockType,
    InnerBlocks = wp.editor.InnerBlocks;

registerBlockType( 'nbrummerstedt/section', {
    title: 'Section',
    icon: 'universal-access-alt',
    category: 'layout',
    attributes: {},
    edit: function( props ) {   
        return el( 'section', {className: props.className},
            el( InnerBlocks )
        );
    },
    save: function( props ) {
        return el( 'section', {className: props.className }, 
            el( InnerBlocks.Content )
        );
    }
} );

@eddr इस पर चर्चा की गई: https://github.com/WordPress/gutenberg/issues/4900#issuecomment -392925877

मुझे अभी भी लगता है कि HTML टैग का उपयोग करने के लिए एक ड्रॉपडाउन एक अच्छा विचार है। यह अति-समान ब्लॉकों का एक पूरा गुच्छा बनाने के बिना <aside> और <section> जैसे अर्थ HTML तत्वों को एकीकृत करने का सबसे आसान तरीका लगता है।

@nbrummerstedt अच्छा प्रारंभिक बुनियादी कार्यान्वयन है, लेकिन ब्लॉक को अब कंटेनर ब्लॉक कहा जाता है और इसे तत्व के रूप में <div> उपयोग करना चाहिए, हालांकि आदर्श रूप में (जैसा कि ऊपर और पिछली टिप्पणियों में बताया गया है), आप HTML को बदलने में सक्षम होंगे तत्व <div> से <section> , <aside> , और शायद <article> ।

यहां आपके कार्यान्वयन का एक संशोधित संस्करण है:

( ( blocks, editor, element ) => {
    const el = element.createElement,
        { registerBlockType } = blocks,
        { InnerBlocks } = editor;

    registerBlockType( 'nbrummerstedt/container', {
        title: 'Container',
        icon: 'universal-access-alt',
        category: 'layout',
        attributes: {},
        edit: ( props ) => {    
            return el( 'div', {className: props.className},
                el( InnerBlocks )
            );
        },
        save: ( props ) => {
            return el( 'div', {className: props.className }, 
                el( InnerBlocks.Content )
            );
        }
    } );
} )( window.wp.blocks, window.wp.editor, window.wp.element );

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

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

https://oxygenbuilder.com/documentation/visual-editing/layout-spacing/
https://oxygenbuilder.com/documentation/visual-editing/responsive-controls/

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

मैं निश्चित रूप से सहमत हूं, यह 5.0 रिलीज में होना चाहिए, आपको कॉलम ब्लॉक का उपयोग करके किसी भी हैकी समाधान से बचने के लिए एक कंटेनर की आवश्यकता है।

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

@ dingo -d और

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

बेशक, यह उल्लेखनीय मुद्दा है कि फ्लेक्सबॉक्स-आधारित संरेखण / लेआउट का उपयोग करने वाला एक कंटेनर ब्लॉक फ्लोट-संरेखित ब्लॉकों को सीधे इसमें नेस्टेड करने की अनुमति नहीं देगा। लेकिन मुझे लगता है कि इसका एक सरल उपाय है: एक कंटेनर का उपयोग करने की क्षमता को या तो मानक CSS display: block लेआउट या फ्लेक्सबॉक्स लेआउट में जोड़ना। मानक display: block मोड डिफ़ॉल्ट होगा, क्योंकि यह वही है जो रूट दस्तावेज़ का उपयोग करेगा। फ्लेक्सबॉक्स डिस्प्ले मोड को सक्षम करने से इंस्पेक्टर में सभी नीट एलाइनमेंट विकल्प दिखाई देंगे। इसके अलावा, आप स्पष्ट रूप से इंस्पेक्टर में 2 लेआउट मोड को एक अलग नाम देना चाहेंगे ताकि इसे और अधिक उपयोगकर्ता के अनुकूल बनाया जा सके। मुझे यकीन नहीं है कि आप उन्हें क्या कहेंगे, हालांकि। शायद "मानक" और "लचीले"?

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

विशेष रूप से, यदि कंटेनर ब्लॉक में दो लेआउट मोड हैं, तो बहुत सी विशेषताओं की तरह लगता है (और मुझे नहीं लगता कि यह वास्तव में एक समस्या होगी), तो बस दो अलग-अलग ब्लॉक हो सकते हैं:

• एक मानक कंटेनर ब्लॉक जो फ्लोट्स का समर्थन करता है लेकिन इसमें सभी उन्नत संरेखण / लेआउट विकल्प नहीं हैं
• एक उन्नत कंटेनर (या उन्नत लेआउट या लचीले लेआउट या जिसे आप इसे कहते हैं) ब्लॉक करें जो फ्लेक्सबॉक्स लेआउट का उपयोग करता है और सभी स्वच्छ विकल्प प्रदान करता है

मैं इस ऑक्सीजन प्रलेखन वीडियो को देखने की सलाह देता हूं कि इसका लेआउट सिस्टम कैसे काम करता है। यह वास्तव में प्रभावशाली है:

https://www.youtube.com/watch?v=NnSfR-YFcQI

मुझे लगता है कि गुटेनबर्ग को बहुत शक्तिशाली बनाने के लिए यहां बहुत संभावनाएं हैं। बेशक, एक प्रारंभिक कार्यान्वयन के लिए मैं केवल कंटेनर ब्लॉक को पृष्ठभूमि विकल्प, उपयोग किए गए HTML तत्व को बदलने की क्षमता, और कंटेनर को पूर्ण-चौड़ाई (लेकिन इसके अंदर की सामग्री नहीं) बनाने का विकल्प होगा। शायद यहां तक ​​कि सिर्फ पृष्ठभूमि विकल्प।

वास्तव में, बस एक कंटेनर ब्लॉक होने पर भी कोई विकल्प नहीं है, अभी भी उपयोगी है, क्योंकि यह सीएसएस के माध्यम से ब्लॉकों के एक समूह को स्टाइल करना आसान बनाता है।

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

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

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

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

आप किस डेटा स्रोत पर इस धारणा को आधार बना रहे हैं?

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

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

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

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

@karmatosed

कोई भी यह नहीं कह रहा है कि इसे बनाया नहीं जाएगा यह प्राथमिकता का विषय है कि संपादक क्या है और फिर चरण दो में क्या है।

मेरी राय में, कंटेनर ब्लॉक बिल्कुल कुछ है जो चरण एक में है।

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

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

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

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

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

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

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

@SuperGeniusZeb ऑक्सीजन बहुत अच्छा है! इनमें से कुछ अन्वेषणों के लिए निश्चित रूप से देखा जाना चाहिए।

जिज्ञासा से बाहर, क्या होता है यदि थीम और प्लगइन्स अपने स्वयं के खंड ब्लॉक जोड़ते हैं, और उपयोगकर्ता प्लगइन को निष्क्रिय करता है या थीम बदलता है? क्या जगह में किसी प्रकार की गिरावट है? या उपयोगकर्ता अपनी सामग्री खो देता है?

@tomusborne उस तरह की स्थिति के बारे में एक मुद्दा है: # 7811।

आह! मुझे नहीं पता था कि यहां चर्चा की गई थी। इसलिए मैंने एक प्लगइन भी बनाया क्योंकि मुझे इसकी आवश्यकता थी।

https://github.com/marcusig/gutenberg-section-block

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

इस मुद्दे के बाद .. मैंने एक "कंटेनर" बनाया है जो कॉलम की संरचना , और अन्य विकल्पों को चुनने की अनुमति देता है।
यदि यह "कॉलम" ब्लॉक को बेहतर बनाने में मदद कर सकता है, या कोर में एक नया निर्माण कर सकता है, तो यह यहाँ है: https://github.com/MarieComet/WP-container-block/

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

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

मुझे पता चला है कि HTML और CSS के साथ लेआउट बनाने का भविष्य हमेशा अधिकांश पेज बिल्डरों की तरह कॉलम का उपयोग नहीं करना है, बल्कि कम <div> s का उपयोग करके सामग्री प्रदर्शित करने के लिए CSS Flex और ग्रिड का उपयोग करना भी है। मार्कअप और अधिक लचीला और क्लीनर स्टाइल है। मैं मुख्य रूप से आक्सीजन क्या कर रहा हूं से प्रेरित हूं। मैंने इस टिप्पणी में ऑक्सीजन के बारे में

यह समस्या अभी कॉलम ब्लॉक को बदलने के बारे में नहीं है। यह ध्यान रखना ज़रूरी है कि यह समस्या एक खंड खंड के बारे में क्या है।

@karmatosed @melchoyce बोलते हुए, इस मुद्दे का नाम नहीं बदला जाना चाहिए? हमने इसे "अनुभाग" कहना बंद कर दिया और <section> तत्वों के साथ भ्रम से बचने के लिए "कंटेनर" पर स्विच कर दिया।

नाम तय नहीं किया गया है, इसलिए हम सभी अच्छे हैं जैसा कि थोड़ा सा है।

फिलहाल मैं गुटेनबर्ग संपादक के साथ मिलकर एक विषय को लागू करने की कोशिश कर रहा हूं।

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

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

मैं वास्तव में आशा करता हूं, कि इस विषय को एक उच्च प्राथमिकता दी जाएगी

मैं कॉलम-ब्लॉक के संयोजन में सभी जगह (जैसे परमाणु ब्लॉक) पर 3-पार्टी कंटेनर ब्लॉक का उपयोग कर रहा हूं। वे सुपर उपयोगी और मेरे सबसे लोकप्रिय ब्लॉक रहे हैं। मुझे यह अजीब लगता है कि इसे भविष्य में बाद में या ऐड-ऑन के रूप में माना जाएगा; कोर में होना चाहिए।

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

क्या किसी को सूचीबद्ध किया गया है / वर्तमान में लागू करने की सूची को जंगली बना रहा है? मुझे लगता है कि इसे "सही काम, और गलत" के किसी पैरामीटर मैट्रिक्स की भी आवश्यकता होगी। उदाहरण के लिए, संबंधित पैडिंग / मार्जिन (गलत) के लिए हार्डकोडेड इकाइयाँ (px) निर्दिष्ट करना, जब इकाइयों को संभवतः उपयोगकर्ता (दाएं), आदि के लिए एक विकल्प छोड़ दिया जाना चाहिए।

https://editorblockswp.com/library/ के पास कैटलॉग में कुछ है, लेकिन इस मुद्दे को आगे बढ़ाने के लिए, ऐसा लगता है कि कुछ अनुभागों / कंटेनरों के लिए विशिष्ट होना चाहिए।

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

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

इसके अतिरिक्त, मैं निम्नलिखित भी करना पसंद करूंगा:

• सीएसएस फ्लेक्स लेआउट विकल्प: टॉप-बॉट से लेफ्ट-राइट, राइट-लेफ्ट और बॉटम-टॉप से ​​कंटेंट फ्लो डायरेक्शन सेट करने की क्षमता; और सामग्री के ऊर्ध्वाधर और क्षैतिज संरेखण सेट करने की क्षमता
• बेशक, फ्लेक्स विकल्पों का उपयोग फ्लोट संरेखण के साथ असंगत है, इसलिए ब्लॉक में कम से कम 2 लेआउट मोड होने चाहिए: मानक और फ्लेक्स, या फिर एक अलग फ्लेक्स कंटेनर ब्लॉक होना चाहिए
• फ़ॉन्ट आकार और रंग विकल्प कंटेनर में सामग्री के लिए चूक सेट करने के लिए और व्यक्तिगत रूप से प्रत्येक निहित ब्लॉक के लिए इसे सेट करने से बचें

फेलिक्स अरेंत्ज़ ने अपने खंड खंड कार्यान्वयन से संबंधित एक ब्लॉग पोस्ट प्रकाशित किया।
मैं उत्तरदायी पृष्ठभूमि छवि को पसंद करता हूं।
https://felix-arntz.me/blog/building-a-reusable-gutenberg-section-block/

पिछले हफ्तों में मैं मार्क लैक्रोइक्स के कार्यान्वयन के साथ प्रयोग कर रहा हूं, जो ठीक काम करता है, लेकिन गुटेनबर्ग में ब्रेक लगता है 3.9.0 https://github.com/marcusig/gutenberg-section-block

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

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

अगर हम इसे 5.0 में चाहते हैं तो हमारे पास इसे करने के लिए ज्यादा समय नहीं है।

@mtias यदि अंतिम उपयोगकर्ता के लिए एक कंटेनर ब्लॉक को उजागर करना एक चिंता का विषय है, तो शायद हर ब्लॉक में डिफ़ॉल्ट रूप से एक कंटेनर या कंटेनर सेटिंग्स होनी चाहिए।

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

मुझे लगता है कि यह वास्तव में एक अच्छा विचार है क्योंकि तब जो लोग मनमाने ढंग से ब्लॉक का विस्तार या रैप करना चाहते हैं, उनके पास ऐसा करने के लिए एक स्पष्ट स्थान होगा, और अंतिम उपयोगकर्ता इससे परिचित होंगे क्योंकि यह हर ब्लॉक पर है।

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

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

@rchipka तकनीकी रूप से अधिकांश ब्लॉक एक पैरेंट डिव के साथ लिपटे हुए हैं और आप जिस तरह के ब्लॉक-लेवल सेटिंग्स का वर्णन कर रहे हैं, वे ब्लॉक अब सक्षम हैं।

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

@mikemcalister अच्छा बिंदु, अंतिम उपयोगकर्ता को अभी भी ब्लॉक ट्री को नेत्रहीन समूहीकरण / व्यवस्थित करने के तरीके की आवश्यकता होगी।

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

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

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

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

@ जिवडिग मुझे नहीं लगता कि गुटेनबर्ग टीम सहित कोई भी, किसी तरह के ब्लॉक कंटेनर तंत्र का विरोध कर रहा है।

गुटेनबर्ग टीम (इस मामले में और कई अन्य) से मुख्य झिझक कोर इंटरफेस को एक यूआई / यूएक्स दृष्टिकोण से जटिलता के स्क्वैरस्पेस स्तर तक रखने के लिए है।

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

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

यही कारण है कि मैंने अंतिम उपयोगकर्ताओं के लिए "कंटेनरों" के लिए अधिक स्वीकार्य सादृश्य के रूप में "समूहीकरण" की अवधारणा का प्रस्ताव दिया।

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

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

बेशक, ये "समूह" आंतरिक रूप से एक कंटेनर ब्लॉक की तरह कार्य करेंगे, यह सिर्फ एक अधिक एकीकृत और सहज फ्रंट एंड इंटरफेस है।

@rchipka एक बहुत ही आसान तरीका है जो एक या अधिक ब्लॉकों का चयन करने की क्षमता रखता है और "अधिक" मेनू में "चयनित ब्लॉक (ओं) को कंटेनर ब्लॉक में ले जाएँ" विकल्प पर क्लिक करें। इस तरह से ब्लॉक को _additional_ settings पैनल की जरूरत नहीं है।

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

-
वेड्स मोड्स
अमेरिकी नदी के लोगों का एक गुप्त इतिहास
http://peoplesriverhistory.us

मेरे Apple से भेजा गया] [ई

12 अक्टूबर 2018 को सुबह 8:09 बजे, मतिस वेंचुरा नोटिफिकेशन @github.com ने लिखा:

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

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

अगर हम इसे 5.0 में चाहते हैं तो हमारे पास इसे करने के लिए ज्यादा समय नहीं है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपको इस धागे की सदस्यता दी गई है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

फिर से प्रत्येक ब्लॉक में अपनी कक्षा की विशेषता निर्धारित करने की क्षमता होनी चाहिए। भले ही प्रकार का हो।

-
वेड्स मोड्स
अमेरिकी नदी के लोगों का एक गुप्त इतिहास
http://peoplesriverhistory.us

मेरे Apple से भेजा गया] [ई

12 अक्टूबर, 2018 को सुबह 8:40 बजे, रॉबी चिपका नोटिफिकेशन @github.com ने लिखा:

@mtias यदि अंतिम उपयोगकर्ता के लिए एक कंटेनर ब्लॉक को उजागर करना एक चिंता का विषय है, तो शायद हर ब्लॉक में डिफ़ॉल्ट रूप से एक कंटेनर या कंटेनर सेटिंग्स होनी चाहिए।

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

मुझे लगता है कि यह वास्तव में एक अच्छा विचार है क्योंकि तब जो लोग मनमाने ढंग से ब्लॉक का विस्तार या रैप करना चाहते हैं, उनके पास ऐसा करने के लिए एक स्पष्ट स्थान होगा, और अंतिम उपयोगकर्ता इससे परिचित होंगे क्योंकि यह हर ब्लॉक पर है।

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

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपको इस धागे की सदस्यता दी गई है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

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

-
वेड्स मोड्स
अमेरिकी नदी के लोगों का एक गुप्त इतिहास
http://peoplesriverhistory.us

मेरे Apple से भेजा गया] [ई

12 अक्टूबर, 2018 को प्रातः 10:50 बजे, क्रिस वान पैटन नोटिफिकेशन @ithub.com ने लिखा:

@rchipka एक बहुत ही आसान तरीका है जो एक या अधिक ब्लॉकों का चयन करने की क्षमता रखता है और "अधिक" मेनू में "चयनित ब्लॉक (ओं) को कंटेनर ब्लॉक में ले जाएँ" विकल्प पर क्लिक करें। इस तरह से ब्लॉक को अतिरिक्त सेटिंग्स पैनल की जरूरत नहीं है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपको इस धागे की सदस्यता दी गई है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

@chrisvanpatten मैं सहमत हूं, हालांकि यह समाधान कंटेनर या अनुभाग की अवधारणा को अंतिम उपयोगकर्ता तक उजागर करने की @mtias की मूल चिंता को पर्याप्त रूप से संबोधित नहीं करता है।

@Mtias द्वारा उठाया गया मुद्दा, एक कंटेनर में ब्लॉक डालने के लॉजिस्टिक्स के बारे में नहीं है,

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

दी गई, यूआई के माध्यम से इसे कैसे करना है, इसके लिए काम करना होगा, लेकिन उम्मीद है कि मेरी उपरोक्त बात समझ में आती है।

@chrisvanpatten मेरा पिछला बयान पूरी तरह से ब्लॉक प्रकारों के शब्दार्थ पर आधारित है।

यहाँ केवल शब्दार्थ का तर्क दे रहा हूँ, @mtias की ओर से, क्योंकि पहली बार इन शब्दार्थों को उजागर करने की जटिलता के साथ एक मुद्दा उठाया गया था।

मुझे आपका सुझाव पसंद है, लेकिन अगर मैं अपने सादृश्य का पालन कर रहा हूं, तो शायद मैं शब्दार्थ "समूह चयनित ब्लॉक (ओं)" को बदल दूंगा।

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

कहा कि मैं गलत होने से ज्यादा खुश हूं :)

@ जिवडिग मैं बहुत सहमत हूँ ...।

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

इन तर्कों को उठाने और इन विचारों को प्रस्तुत करने का मेरा एकमात्र आधार है।

फिर, अगर यह मेरे थे, तो हम सिर्फ लानत कंटेनर ब्लॉक होगा।

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

@rwrobe यह विचार नेस्टेड कंटेनरों के लिए काम नहीं करता है।

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

• "खंड" ब्लॉक का सबसे अच्छा नाम है। इसका अर्थ डेवलपर्स और अंतिम उपयोगकर्ताओं के लिए स्पष्ट है, और यह तार्किक रूप से <अनुभाग> ब्लॉक का उपयोग करके मार्कअप / विकल्पों को जटिल करने से बचता है।

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

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

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

@ZebulanStanphill क्या आप स्तंभों के बारे में बात कर रहे हैं? मैं "सेक्शन" को ब्लॉक किए गए अलग-अलग कंटेंट के लिए जॉब करते देख सकता था- पिछले सेक्शन से स्टाइल इनहेरिट करने के लिए एक टॉगल भी हो सकता है, जो आपको सेक्शन के अंदर "नेस्ट" स्टाइल वेरिएशन की अनुमति देता है।

स्तंभों की तरह क्षैतिज रचना, आवश्यक रूप से अधिक कठिन लगती है जिस तरह से गुटेनबर्ग पृष्ठ को पूर्ण-चौड़ाई वाले ब्लॉकों में ऊपर से नीचे तक बनाते हैं।

@mikedance मुझे लगता है कि वास्तव में इसकी आवश्यकता है। IMO के बावजूद एक पृष्ठभूमि छवि विकल्प महत्वपूर्ण होगा। शायद यह ब्लॉक कवर ब्लॉक की जगह ले सकता है, हालांकि नामकरण लोगों के लिए अनुकूल नहीं हो सकता है कि _only_ इसके ऊपर मूल पाठ के साथ एक पृष्ठभूमि छवि चाहते हैं। यद्यपि कार्यक्षमता में कुछ ओवरलैप है, लेकिन यह bg छवि समर्थन को जोड़े बिना अनुभाग ब्लॉक के लिए उपयोग-मामलों का एक बड़ा प्रतिशत दूर ले जाएगा।

@ श्रवण यह ध्यान दिया जाना चाहिए कि आपके पास क्षैतिज-रखी-आउट ब्लॉक हो सकते हैं। कॉलम ("s" की कमी पर ध्यान दें) ब्लॉक बस यही हैं। कॉलम ब्लॉक उन्हें क्षैतिज रूप से बाहर देता है। यूआई शायद कुछ क्षेत्रों में सुधार किया जा सकता है, लेकिन ब्लॉक केवल पूर्ण-चौड़ाई या लंबवत-ले-आउट होने तक सीमित नहीं हैं।

@mikedance

"खंड" ब्लॉक का सबसे अच्छा नाम है। इसका अर्थ डेवलपर्स और अंतिम उपयोगकर्ताओं के लिए स्पष्ट है, और यह तार्किक रूप से उपयोग करके मार्कअप / विकल्पों को जटिल करने से बचता है

खंड मैथा।

क्योंकि <section> तत्व इसे से जुड़े अर्थ विज्ञान है, यह सबसे अच्छा होगा यदि आप एक का उपयोग करने के लिए चुन सकते हैं अगर हैं <div> के बजाय एक <section> , के बाद से कई मामलों में आप रैप करना चाहते हैं कई ब्लॉक, लेकिन वे शब्दार्थ सेक्शन का हिस्सा नहीं हैं। वास्तव में, यह और भी बेहतर होगा यदि आप <aside> भवन में <header> जैसे तत्वों का उपयोग करना चुन सकते हैं, बाद वाले को पृष्ठ निर्माण में शीर्षकों-पृष्ठभूमि के साथ शब्दार्थ जोड़ने के लिए विशेष रूप से उपयोगी है।

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

@ZebulanStanphill मैं

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

@ZebulanStanphill @wmodes मुझे संदेह है कि किसी भी तत्व का चयन करने के विकल्प में कभी कोर

@mikedance सहमत है, हमें शायद <div> उपयोग करना चाहिए। यदि सिमेंटिक लेआउट एक चिंता का विषय है तो इसे कंटेनर ब्लॉक के विस्तार के रूप में देखा जाएगा।

@strarsis थीम्स ब्लॉक में शैलियों को जोड़ने के लिए मौजूदा ब्लॉक स्टाइल एपीआई का उपयोग कर सकते हैं। (कोर बटन और उद्धरण ब्लॉक में डिफ़ॉल्ट रूप से कई स्टाइल वेरिएंट शामिल हैं।) दुर्भाग्य से, मैं इस कार्यक्षमता पर कोई दस्तावेज नहीं पा सकता हूं। (डॉक्स की वर्तमान कमी को ट्रैक करने वाले कई मुद्दे हैं: https://github.com/WordPress/gutenberg/milestone/500)

@mikedance

एक निश्चित दृष्टिकोण से

तत्व उतना ही अर्थपूर्ण है जितना संभवतः यह हो सकता है क्योंकि उपयोगकर्ता पहले से ही इसे ब्लॉक बनाने के गुण से "खंड" के रूप में परिभाषित कर रहा है।

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

लेकिन हाँ, <div> सबसे तटस्थ विकल्प है क्योंकि इसका कोई अर्थ नहीं है। यदि HTML तत्व को बदलने के लिए कोर में कोई विकल्प नहीं होगा, तो <div> सबसे अच्छा विकल्प है।

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

@strarsis @ZebulanStanphill

आप एक्स्टेंसिबिलिटी के तहत हैंडबुक में Block Styles जोड़ने के लिए डॉक्स पा सकते हैं। https://wordpress.org/gutenberg/handbook/extensibility/extending-blocks/#block -style- रूपांतर

@ajitbohra धन्यवाद! मैंने कई बार उस पेज को चेक किया लेकिन मैं किसी भी तरह उस सेक्शन को याद नहीं कर रहा था। :हस रहा:

@ajitbohra : धन्यवाद! वहाँ Gutenberg ब्लॉक शैली बदलाव btw के लिए एक डेमो है।?

@strarsis

हां, कोर button और quote ब्लॉक की जांच करें

https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/button
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/quote

@strarsis pullquote , table , और separator ब्लॉकों में भी शैली भिन्नताएँ हैं:
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/pullquote
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/separator
https://github.com/WordPress/gutenberg/tree/master/packages/block-library/src/table

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

इसे 5.1 रिलीज़ के लिए अस्थायी रूप से स्थानांतरित करना ताकि हमारे पास यह निर्धारित करने में थोड़ा और समय हो कि इस ब्लॉक को कैसे प्रस्तुत किया जाए।

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

@JiveDig

क्या होगा यदि कवर ब्लॉक उस समय "कॉन्फ़िगरेशन" से अधिक था, जब आप उस ब्लॉक को जोड़ते हैं, यह वास्तव में एक प्रीकन्फिगर्ड सेक्शन बॉक को हेडिंग या टेक्स्ट / पैराग्राफ ब्लॉक के साथ जोड़ देता है, जिसके अंदर नेस्टेड होता है?

ऐसा लगता है कि एक पुन: प्रयोज्य ब्लॉक मेरे लिए एक स्टैंडअलोन ब्लॉक के रूप में डाला जा रहा है। शायद कोर डिफ़ॉल्ट रूप से कई पुन: प्रयोज्य ब्लॉक टेम्पलेट्स को शामिल कर सकता है। पुन: प्रयोज्य ब्लॉक को स्टैंडअलोन के रूप में सम्मिलित करने के लिए UI को बेहतर बनाना होगा। # 8403 देखें।

क्या नए खंड / कंटेनर ब्लॉक के परीक्षण के लिए कांटा होगा? मुझे इसके साथ खेलने और इसे परखने में मदद करने में दिलचस्पी है।

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

यह टिप्पणी करते हुए कि एक खंड खंड टेम्पलेट विकास के लिए अविश्वसनीय रूप से उपयोगी होगा।

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

इसे PR # 12406 (ऊपर) में हल किया गया है

क्या खंड को अभी भी 5.1 (21 फरवरी, 2019 के लिए लक्षित) या बाद में माना जाता है?

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

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

अनुभागों का मतलब है कि gutenberg _must_ उन वर्गों के साथ ठीक से व्यवहार करने में सक्षम हो सकता है, जिन्होंने flex में अपना प्रदर्शन सेट किया है और वे तत्काल बच्चों के flex गुणों का प्रतिपादन कर रहे हैं।

मैं अपने अनुभागों को जेएस में प्रस्तुत करता हूं, लेकिन कोड में एक संख्या है जिसे मैं हैक मानता हूं। PHP में उन्हें सौंपना केक का एक टुकड़ा होगा ... इनरब्लॉक्स कंटेंट को नीचे भेजने के अलावा PHP अभी भी अनसुलझी है, है ना?

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

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

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

ब्लॉक नेस्टेड हैं क्योंकि उन ब्लॉकों के माता-पिता / बच्चे का संदर्भ आवश्यक है कि वे कैसे प्रदर्शित और संपादित किए जाते हैं। संदर्भ मौजूद नहीं है आदर्शवाद सबसे खराब है।

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

(मुझे लगता है कि columns ब्लॉक अधिक उपयोगी होगा यदि यह [अभी भी प्रायोगिक] CSS columns प्रॉपर्टी को लागू करता है। यह अनिवार्य रूप से section एक विशेष प्रकार होगा, जो सभी को लेता है। निरीक्षक में परिभाषित स्तंभ गुणों के माध्यम से इसके भीतर और उन्हें प्रवाहित करना: column-width , column-count , column-rule , आदि)

क्या इस ब्लॉक प्रकार (ब्लॉक जोड़ें: अनुभाग) के लिए कोई रिलीज़ तिथि है?

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

नमस्ते,

मैं इसके बारे में केवल एक बार नहीं सोचता। एक खंड पूर्ण-चौड़ाई वाला कंटेनर होना चाहिए। क्या हम सिर्फ एक सेक्शन के अंदर कंटेनर में एक गटर डाल सकते हैं और उन्हें add_theme_support('alignwide') तरह काम कर सकते हैं या नहीं।

एक मामले के लिए:

https://tech.cornell.edu/

हमारे कई अलग-अलग वर्ग हैं। उनमें से कुछ एक कंटेनर में जीवित हैं। कुछ नहीं हैं। लेकिन उन सभी को एक एकल कंटेनर की आवश्यकता है।

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

जब मैं एक https://www.luminasolar.com/ विकास करता हूं, तो मुझे उन्हें संरचना रखने के लिए template कुंजी के अंदर लपेटना होगा।

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

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

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

यह मूल रूप से केवल गायब होने वाली विशेषता है जो मुझे अपनी साइटों पर चारों ओर तत्व रखने देती है ...

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

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

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

खंड ब्लॉक मूल Gutenberg में होना चाहिए (और विषयों द्वारा विन्यास और एक्स्टेंसिबल) अंत में अधिक जटिल पृष्ठों को बाहर करने में सक्षम होने और अभी भी विषयों को स्विच करने में सक्षम होने की समस्याओं को हल करने के लिए।

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

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

इंस्पेक्टर पैनलों

• _Background._ मेरा प्लग-इन पृष्ठभूमि रंग और / या छवि सेट करने की अनुमति देता है, यदि वांछित हो, तो छवि प्लेसमेंट, सम्मिश्रण, अवरोहण और यहां तक ​​कि एक रंग को ओवरले करने के लिए नियंत्रण के साथ।
• _Dimensions, Padding, Margins._ डिफ़ॉल्ट रूप से, अनुभाग सामग्री को ऑटो-ऊँचाई और पूर्ण और विस्तृत और केंद्र संरेखण का पालन करते हैं, बाएँ और दाएँ 45% पर। उस ने कहा, मैं निर्दिष्ट चौड़ाई और / या ऊंचाई की अनुमति देने के लिए नियंत्रण जोड़ रहा हूँ, इनरब्लॉक और ब्लॉक के चारों ओर मार्जिन। _But Gutenberg._ के साथ मुद्दों के लिए नीचे देखें
• _Columns ... और Rows._ फ्लेक्स का उपयोग करने के बाद बहुत सारे प्रयोग के बाद, सीएसएस _grid_ तत्काल बच्चों के लिए, यदि आप स्तंभ-आधारित लेआउट के बाद हैं, तो उपयोग करने का सबसे अच्छा तरीका है। ग्रिड का उपयोग करना एक टॉगल है; अन्यथा बच्चे सिर्फ सामान्य ब्लॉक हैं। (ईमानदारी से, जब पंक्तियाँ प्राप्य होती हैं, तो वे संपादन इंटरफ़ेस में बहुत अधिक जटिलता जोड़ते हैं जो कि आपके द्वारा काम करने के दौरान एक नया अनुभाग जोड़कर सबसे अच्छी तरह से नियंत्रित किया जा सकता है जब आपको एक नई पंक्ति शुरू करने की आवश्यकता होती है।) ग्रिड से बेहतर है। फ्लेक्स - भले ही आप सिर्फ कॉलम कर रहे हों - क्योंकि फ्लेक्स _requires_ कंटेनर या बच्चे की वस्तुओं पर सेट होने के लिए एक विशिष्ट, गैर-प्रतिशत ऊंचाई है, जो बहुत सारे लचीलेपन को हटा देता है।

मोबाइल
ग्रिड का उपयोग कर किसी भी अनुभाग प्लगइन के साथ एक समस्या यह है कि परिभाषित मोबाइल ब्रेकप्वाइंट पर ग्रिड का क्या होता है। उपयोगकर्ता (या थीम लेखक) को तब परिभाषित करने में सक्षम होना चाहिए जब एक खंड 3 आइटमों को 2 वस्तुओं के पार से 1 आइटम के पार प्रदर्शित करता है।

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

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

Columns:        3,2,1,1
Column 1 width: 70%,50% 

आदि (स्पष्ट रूप से एकल कॉलम 100% हैं और निर्दिष्ट करने की आवश्यकता नहीं है)।

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

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

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

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

गुटेनबर्ग मुद्दे
इसलिए, गुटेनबर्ग खराब तरीके से निम्न कार्य करते हैं:

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

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

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

@rogerlos आपको Kadence Blocks पर एक नज़र डालनी चाहिए। वे फ्लेक्सबॉक्स-आधारित स्तंभों को बहुत अच्छी तरह से संभाल रहे हैं।

मुझे यह जोड़ना चाहिए कि मैं दृढ़ता से मानता हूं कि फॉन्ट फेस, हेडिंग साइज, आदि चीजें ऐसी चीजें नहीं हैं जो सेक्शन ब्लॉक को सीधे तौर पर कहने के लिए होनी चाहिए।

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

यहां तीन अलग-अलग आंतरिक सामग्री चौड़ाई, समायोज्य स्तंभ चौड़ाई, समायोज्य शीर्ष / निचले पंक्ति मार्जिन के साथ-साथ पृष्ठभूमि और पाठ रंग सेटिंग्स के लिए अनुमति देने के लिए उपकरण टूलबार में "Align Modes" का पुन: उपयोग कैसे किया जाता है, इसका

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

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

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

सभी स्क्रीन आकारों में एक सुसंगत और अनुमानित लेआउट को लागू करने के लिए, हमारे सेटअप में रूट स्तर पर कोई "टेक्स्ट-ओरिएंटेड" ब्लॉक की अनुमति नहीं है।

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

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

@strarsis अच्छा विचार है।

आदर्श रूप से, एक खंड खंड z- इंडेक्स का उपयोग टॉगल करने योग्य अग्रभूमि / पृष्ठभूमि संपादन मोड प्रदान करने के लिए करेगा।

इस तरह से सेक्शन ब्लॉक अपने आप में बैकग्राउंड इमेज / ओवरले स्टफ को रीइन्वेंट नहीं करता है, जो बिल्ट-इन कवर इमेज ब्लॉक पर उपलब्ध है।

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

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

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

इसका कारण यह है कि, जबकि उपयोगकर्ता पैडिंग मानों को समायोजित करने के लिए बहुत सुरक्षित होंगे, हम निश्चित रूप से नकारात्मक मार्जिन को कुछ उपयोगकर्ता-परिभाषित नहीं करना चाहते हैं।

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

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

@strarsis मेरी राय में, कुछ भी जो the_content() क्षेत्र के बाहर होता है उसका गुटेनबर्ग संपादक के अंदर कोई व्यवसाय नहीं है।

ये "क्षेत्र" पृष्ठ टेम्पलेट का एक हिस्सा हैं न कि पृष्ठ सामग्री और इसे कहीं और संभाला जाना चाहिए।

पृष्ठ सामग्री बनाम पेज टेम्पलेट (/ लेआउट)

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

एक तत्व पृष्ठ टेम्पलेट का हिस्सा है ( और पृष्ठ सामग्री नहीं ), यदि:

1. तत्व एक पूरे के रूप में the_content() क्षेत्र की संरचना, सीमाओं, या स्थिति पर निर्भर करता है या निर्भर करता है, और
2. तत्व एक दोहराई जाने वाली पद्धति का हिस्सा है (यानी संभावित रूप से दो या अधिक पर्मलिंक पर देखा जा सकता है)

कुछ अनुभव-आधारित पृष्ठभूमि

दोहराए जाने वाले टेम्प्लेट / लेआउट तत्व आमतौर पर एक कस्टम पोस्ट प्रकार के लिए विशिष्ट होते हैं और इसमें सामग्री हिरो, सामग्री साइडबार और सामग्री पाद शामिल होते हैं।

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

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

तो आखिरकार

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

कुछ भी जो "टेम्पलेट" के अंतर्गत आता है और "कंटेंट" को किसी भी खंड ब्लॉक के बाहर और गुटेनबर्ग संपादक (अब के लिए) के बाहर संभाला जाना चाहिए।

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

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

एक आसान विकल्प के रूप में, मैंने बस एक कॉलम ब्लॉक का उपयोग किया और कॉलम की संख्या को 1 पर सेट किया (स्लाइडर 2 और 6 के बीच सीमित है, लेकिन आप इनपुट क्षेत्र में 1 दर्ज कर सकते हैं)। उसके बाद आपको व्यवस्थापक में CSS ठीक करने की आवश्यकता है:

//Allow single columns
add_action('admin_head', 'gutenberg_allow_single_columns');
function gutenberg_allow_single_columns() {
    ?>
    <style type="text/css">
    <strong i="6">@media</strong> (min-width: 600px) {
        .wp-block-columns.has-1-columns > .editor-inner-blocks > .editor-block-list__layout > [data-type="core/column"] {
            flex-basis: 100% !important;
            flex-grow: 0; } }
    </style>
    <?php
}

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

और कितने और कौन से रैपर का उपयोग किया जाता है, इसे नियंत्रित करने के लिए विषय (डेवलपर्स) के लिए एक साधन जोड़ें।
कुछ डिजाइनों में सिर्फ एक तत्व की जरूरत होती है। वर्तमान में मुझे कंटेनर तत्व के लिए एक और प्लगइन का उपयोग करना है और फिर कंटेनर सामग्री को स्टाइल के लिए अतिरिक्त आवरण तत्वों में लपेटने के लिए PHP पार्सर का उपयोग करके पूरी सामग्री को पार्स करना है।

@strarsis यह निश्चित रूप से कुछ ऐसा है जो शुरू से किया जाना चाहिए था।

पोस्ट सामग्री के किसी भी सभ्य स्टाइल को करने के लिए, प्रत्येक रूट-स्तरीय बच्चे को एक सुसंगत पंक्ति / अनुभाग में रखा जाना चाहिए।

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

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

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

रूट कंटेनर ब्लॉक ब्लॉकों के एक सीमित उप-समूह को लागू करता है जिसे भीतर जोड़ा जा सकता है।

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

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

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

देख:
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

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

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

सादर धन्यवाद।

हाँ, यह बिल्कुल सही है। मुझे लगता है कि वर्तमान में विकसित किए जा रहे अन्य सभी ब्लॉकों की तुलना में यह और भी महत्वपूर्ण है। @youknowriad क्या आप इसे अधिक प्राथमिकता नहीं दे सकते?

यह पहले से ही चरण 2 स्कोप https://github.com/WordPress/gutenberg/issues/13113 पर है अगर कोई जाने देने को तैयार है, तो कृपया करें।

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

हाँ, चिंता मत करो मैं समझता हूँ।

यहां पीआरओ हैं। https://github.com/WordPress/gutenberg/pull/10562

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

मैं दोहराता हूं कि अगर ऐसे डेवलपर हैं जो इसे और अधिक तेज़ी से देखना चाहते हैं और मदद करना चाहते हैं, तो वे कोर स्लैक # कोर-एडिटर चैनल (और मीटिंग्स) में साप्ताहिक बैठकों में आपका स्वागत करते हैं और चर्चा / सहयोग / मदद के लिए पूछते हैं।

आह्ह हाँ यह बात है! महान! आपका अवलोकन है !!!

हाँ, यह सच है और यह एक फटकार नहीं होनी चाहिए। मैंने केवल अपने आप से क्या पूछा: क्या कोई महत्वपूर्ण और अधिक महत्वपूर्ण कार्य नहीं हैं? अगर 50 लोगों को आरएसएस ब्लॉक की जरूरत है, लेकिन 1000 को कंटेनर ब्लॉक की जरूरत है, तो यह पूरी तरह से विशेष रूप से ध्यान केंद्रित करने के लिए समझ में आता है। कंटेनर ब्लॉक अब कुछ भी विदेशी नहीं है। मुझे लगता है कि यह हर design_ के लिए _basis है।

कृपया गलत न समझें: आप बहुत अच्छा काम कर रहे हैं। और आप चरण 2 के नेता के रूप में प्रथम श्रेणी का काम कर रहे हैं। यह सब ध्यान केंद्रित करने के सवाल के बारे में है। मैं अगले सुस्त चैट पर टोस्ट करूँगा ... ;-)

बहुत धन्यवाद फिर से!

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

ये दोनों कार्य जटिलता के संदर्भ में "मध्यम" कार्य हैं, वे महत्वपूर्ण फ़ीचर वार हैं, लेकिन वे महत्वपूर्ण फ्रेमवर्क-वार नहीं हैं। इस समय मेरी व्यक्तिगत उच्च प्राथमिकता फ्रेमवर्क चीजें हैं जो चरण 2 लक्ष्यों (विजेट स्क्रीन में ब्लॉक, पोस्ट_ कॉन्टेंट के बाहर संपादक) को सक्षम करेंगी क्योंकि ये आकस्मिक मुद्दे बाद में के बजाय जल्द ही प्रयोग और स्पष्ट करने के लिए महत्वपूर्ण हैं।

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

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

सादर धन्यवाद।

जब तक यह आकार नहीं ले लेता, तब तक मैं इसे और नए ब्लॉक संपादक की अन्य कमियों को ले रहा हूँ। उम्मीद है कि ऐसा होगा क्योंकि नए संपादक के लिए कुछ अच्छे पहलू हैं।

एक खंड ब्लॉक भयानक होगा, मैं बैकेंड विकास कौशल की कमी होने पर मैं क्या मदद कर सकता हूं।

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

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

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

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

यहां बड़ा सवाल यह है कि इसकी देखभाल कौन करता है। कुछ डेवलपर्स नहीं हैं जिनके पास करने के लिए समय और ऊर्जा है?

हाँ हाँ हाँ! मेरा मानना ​​है कि एक लचीला खंड ब्लॉक गुटेनबर्ग से सबसे बड़ी लापता विशेषता है।

मुझे विश्वास नहीं हो रहा है कि यह अभी तक मौजूद नहीं है ...

एक विकल्प यह होगा कि कॉलम ब्लॉक में केवल एक कॉलम हो और साथ ही कॉलम में बैकग्राउंड कलर सेट करने की अनुमति हो। TA-DA: खंड खंड।

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

https://github.com/Impuls-Werbeagentur/impuls-section-block

मैं इस पर काम करने के लिए अपना हाथ रखने जा रहा हूं। मैं अगले सप्ताह के मध्य से इस पर एक शुरुआत कर सकूंगा

@chrisvanpatten - ऐसा लगता है कि आपने पहले इस पर वास्तव में अच्छी प्रगति की थी, बस यह जांचना चाहते थे कि क्या आप मेरे साथ इसे ले रहे हैं?

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

मुझे लगता है कि पहला सुधार किसी भी ब्लॉक के बाहर अधिक आवरण जोड़ रहा है।

उदाहरण के लिए:

<div class="wp-block-paragraph">
  <div class="wp-block-paragraph__container">
    <InnerContent />
  </div>
</div>

अभी, कई तत्व सीधे सम्मिलित किए जाते हैं, हमें आवरण बनाने के लिए स्टाइल लागू करने से रोकते हैं।

<ol>
  <li></li>
</ol>

उस के लिए आवरण जोड़ सकते हैं:

<div class="wp-block-listing">
  <div class="wp-block-listing__container">
    <ol>
      <li></li>
    </ol>
  </div>
</div>

फिर हम उन्हें मिलान रखने के लिए कंटेनर सेट लागू कर सकते हैं:

// Example
#content > * > * {
  max-width: 1280px;
  padding: 0 20px;
}

@ पतलदान क्या इस मुद्दे पर अपनी नज़र
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

खंड खंड भयानक होंगे, लेकिन कृपया इसे सिमेंटिक मार्क-अप करें! सिमेंटिक HTML संरचना में चीजों को रखने से सबसे अज्ञेय कोड आधार बन जाएगा।
<section>, <article>, <header> रास्ता बेहतर है <div class="wp-section"> या जो भी हो।

@talldan क्षमा करें, मैं आपकी टिप्पणी से चूक गया, लेकिन मैं 100% ठीक हूं, क्योंकि आप इसे हिला देंगे!

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

एक महान बात, जो, वैसे, बहुत सारे पृष्ठ बिल्डरों के पास भी है। या कम से कम ऐसा कुछ:

एक फोकल प्वाइंट पिकर सहमत हुए तो यहां बहुत अच्छा होगा। यह कवर ब्लॉक में वास्तव में अच्छी तरह से काम करता है!

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

पूर्वावलोकन :

आप यहां प्रोटोटाइप देख सकते हैं ।

कुछ अतिरिक्त नोट:

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

मैं मानता हूं, यदि आवश्यक हो तो पृष्ठभूमि छवि को सीएसएस का उपयोग करके जोड़ा जा सकता है: +1:

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

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

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

अच्छा! ऊर्ध्वाधर गद्दी के लिए छोटे / मध्यम / बड़े वर्गों के लिए उपयोगी होगा।

अच्छा! ऊर्ध्वाधर गद्दी के लिए छोटे / मध्यम / बड़े वर्गों के लिए उपयोगी होगा।

यह थीम / फ्रेमवर्क-स्तर में डूबा हुआ है, और मुझे यकीन नहीं है कि अगर कोर में https://cdn.vaadin.com/vaadin-lumo-styles/1.4.1/demo/sizing-and-spacing जैसी किसी भी चीज़ के लिए जगह है

मुझे लगता है कि हमें इसे शुरू करने के लिए पृष्ठभूमि की छवि के बिना लॉन्च करना चाहिए

अधिक सहमत नहीं हो सका। एक v1 प्राप्त करें और फिर v2 अधिक जटिल कार्यक्षमता जोड़ सकते हैं।

इस ब्लॉक में कोई उत्तरदायी सेटिंग नहीं होगी

सहमत - यह ब्लॉक जितना संभव हो उतना सरल और निर्विवाद होना चाहिए।

मुझे लगता है कि यदि संभव हो तो हमें इस पीआर को मर्ज करना चाहिए।

मैं कुछ इस तरह से एक अजीब लिया ... एक प्लगइन के रूप में जारी:

https://wordpress.org/plugins/magic-block/

कृपया, कोई और प्लगइन्स नहीं जो इसके आधार पर लोगों को छोड़ देगा। बस पहले से ही शापित ब्लॉक जारी करें।

@webdados I यह दूसरा है।

किसी के काम को कम करने के लिए नहीं, लेकिन हमें वास्तव में कुछ स्तरों पर इसके निर्माण की आवश्यकता है।

विशेष रूप से एक ऐसी दुनिया में जहाँ यह मुद्दा है ।

# 13391 के लिए एक पर्याप्त समाधान मिलना चाहिए, तो अनगिनत कंटेनर ब्लॉक कार्यान्वयन का अस्तित्व शायद ठीक होगा।

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

हम इस सुविधा की उम्मीद कब कर सकते हैं?

पहले से ही नवीनतम संस्करण में होना चाहिए:
https://github.com/WordPress/gutenberg/releases/tag/v5.5.0

@ksere : मुझे याद है कि शायद क्योंकि प्लगइन के v5.5.0 के लिए चैंज खाली है ।

वास्तव में इस पर अब तक के कार्यान्वयन को खोद रहा है। मैं समझता हूं कि यह सिर्फ ५.५ में जारी किया गया था, लेकिन मैं सोच रहा हूं कि हम पृष्ठभूमि की छवियों (और उनकी स्थिति), पृष्ठभूमि के रंग अस्पष्टता आदि के लिए अतिरिक्त की उम्मीद कर सकते हैं, क्या यह कुछ है जो हमें २०१ ९ के अंत से पहले उम्मीद करनी चाहिए, या क्या हम और अधिक लंबी बात कर रहे हैं -इससे ज्यादा अच्छा है?

@nathansnelgrove प्रतिक्रिया के लिए धन्यवाद। समूह ब्लॉक में निश्चित रूप से कुछ सुधार आ रहे हैं, यहाँ दो पहले से ही प्रगति पर हैं:

• स्टाइल को आसान बनाने के लिए एक आंतरिक कंटेनर को जोड़ना - https://github.com/WordPress/gutenberg/pull/15210
• ब्लॉक के चयन के लिए समूहीकरण / अनग्रुपिंग के लिए संपादक विकल्प जोड़ना - https://github.com/WordPress/gutenberg/pull/14908

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

पृष्ठभूमि चित्र / रंग / अस्पष्टता मूल प्रस्ताव से हैं - मैं उनके लिए एक नया मुद्दा बनाऊंगा।

मैंने अभी वर्डप्रेस ५.२.४ स्थापित किया है, और मुझे कोई भी "खंड" या "समूह" ब्लॉक नहीं मिल रहा है। यहाँ क्या चल रहा है?

@patrikhuber : यह वर्डप्रेस 5.3 में शामिल किया जाएगा जिसे वर्तमान में 12 नवंबर को रिलीज़ करने की योजना है।

@ मैं देख रहा हूँ, बहुत बहुत धन्यवाद!