संपादक परिवर्तन के लिए @noisysocks और @iseulde को पिंग करना । मैं कोर बदलाव जोड़ सकता हूं।

संपादक के लिए परिवर्तन (जैसा कि मैं उन्हें देखता हूं) होगा:

• सभी <img> टैग में data-wp-attachment-id="1234" विशेषता जोड़ें।
• हमेशा "बड़ी" आकार की छवि डालें।
• मध्यम, बड़े और xlarge आकारों के साथ srcset विशेषता जोड़ें (हम शीघ्र ही डिफ़ॉल्ट आकार में xlarge छवि आकार जोड़ देंगे)।
• संपादक में छवि चौड़ाई के लिए उपयुक्त sizes विशेषता जोड़ें।
• बचत करने पर, शायद दोनों srcset और sizes निकाल दें क्योंकि वे प्रदर्शित करते समय संभवतः अलग होंगे। वैकल्पिक रूप से हम उन्हें डिस्प्ले फिल्टर में ओवरराइड कर सकते हैं।
• छवि आयामों के लिए कोई भी पिक्सेल मान सेट करते समय, उन्हें संपादक चौड़ाई से दूर करें। यह संपादक में दिखाई देने वाली छवियों की तुलना में व्यापक होने का कोई मतलब नहीं होगा।

TODO: इस बात पर विचार करें कि फ्रंट-एंड के लिए प्रतिशत चौड़ाई पास करने का सबसे अच्छा तरीका क्या होगा।

इसे लिखने के लिए धन्यवाद, @azaozz! आवश्यक संपादक परिवर्तनों के साथ मदद करने में प्रसन्नता। वे मुझे अच्छे लगते हैं।

वैकल्पिक रूप से हम संपादक में प्रतिशत (HTML 4.0 शैली) में चौड़ाई सेट कर सकते हैं, फिर उन्हें इस बिंदु पर पिक्सेल से बदल सकते हैं।

इसके साथ मेरी झिझक यह है कि अगर कोई तीसरा पक्ष (जैसे प्लगइन, आरएसएस रीडर, एपीआई उपभोक्ता) post_content बिना प्रसंस्करण के करता है तो उनके पास मान्य HTML5 मार्कअप नहीं होगा। "ऑनरिंग एचटीएमएल" गुटेनबर्ग की आवश्यकताओं में से एक है ।

जोर से सोचकर: क्या हम इसमें से कुछ को पूरा करने के लिए गुटेनबर्ग मेटाडेटा का उपयोग कर सकते हैं, जैसे अटैचमेंट आईडी और प्रतिशत चौड़ाई को स्टोर करने के लिए?

<!-- wp:image {"attachmentId":123,"horizontalScale":0.25} -->
<img src="https://example.com/image.jpg" width="600" height="500" />
<!-- /wp:image -->

हाँ, छवियां "डायनेमिक ब्लॉक" हैं (यही कारण है कि क्लासिक संपादक में भी उनका इलाज किया जाता है)। वे सबसे अच्छे प्रकार के डायनामिक ब्लॉक हैं क्योंकि उनके पास "फ़ॉलबैक मार्कअप" है, और वहीं पर संसाधित होते हैं
उन्हें बढ़ाने के लिए फ्रंट-एंड।

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

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

अंत में यह उबलता है:

• कौन सा आसान, तेज, सरल, अधिक पठनीय / समझने योग्य है: ब्लॉक को पार्स करना और फिर HTML का हिस्सा (जिसमें कई तत्व शामिल हो सकते हैं) या <img> टैग पार्स करना जैसा कि हम वर्तमान में करते हैं।
• क्या हम गारंटी दे सकते हैं कि संपादक में उपयोग की जाने वाली सभी छवियां हमेशा wp:image ब्लॉक में रहेंगी। इसमें पेस्ट की गई छवियां, टेबल सेल में चित्र, उद्धरण और किसी भी अन्य ब्लॉक और टैग संयोजन प्लगइन्स शामिल हो सकते हैं।

Imho हमें ब्लॉक मेटा और img टैग विशेषताओं दोनों का उपयोग करना चाहिए, फिर (एक दिन) हम प्रदर्शन पर सामग्री को पार्स करते समय उपयोग करने में सक्षम होंगे।

@azaozz यह एक सुविचारित प्रस्ताव है। मैं पूरी तरह से लोभी नहीं हूं कि हम मौजूदा थीम-घोषित छवि आकारों का उपयोग क्यों नहीं करते हैं। क्या इसके आसपास पूर्व चर्चा है?

वर्तमान में एक प्रतिशत क्षेत्र उजागर है, लेकिन मैं यह निर्धारित करने में सक्षम नहीं था कि यह वर्तमान में कुछ भी है। https://github.com/WordPress/gutenberg/blob/master/blocks/library/image/block.js#L266

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

हम मौजूदा थीम-घोषित छवि आकारों का उपयोग क्यों नहीं करते ...

हम करते हैं :) हम फ्रंट-एंड पर srcset विशेषता जोड़ते समय सभी उपलब्ध आकारों (जिसमें समान w / h अनुपात है) का उपयोग करते हैं। फिर ब्राउज़र तय करता है कि किस छवि फ़ाइल का उपयोग करना है।

@azaozz मेरा मानना ​​है कि यह वर्तमान व्यवहार की तुलना में थोड़ा अलग कार्य करेगा। शैलियों को वितरित करने के लिए छवि आकार का उपयोग किया जा सकता है, न कि केवल छवि फसल का उपयोग करने के लिए। मुझे यह भी लगता है कि मौजूदा आलसी लोड प्लगइन्स src मूल्य "सही" आकार की उम्मीद करते हैं, इसलिए मुझे यकीन नहीं है कि हम srcset पर पूरी तरह से भरोसा कर सकते हैं।

संपादित करें: यह मेरे विचार से image_size_names_choose फ़िल्टर होगा।

@davisshaver मैंने पिछले सप्ताह में कई आलसी लोड प्लगइन्स के माध्यम से जाना है। उनमें से कई मौजूदा src और srcset विशेषताओं की तलाश करते हैं और बस PHP में अन्य मार्कअप के साथ उन्हें the_content फ़िल्टर का उपयोग करके बदलते हैं। यहां चुनौती यह है कि पहली जगह में srcset और sizes विशेषताओं के साथ-साथ भौतिक चित्र बनाने के लिए कोर कैसे प्राप्त करें।

उत्तरदायी छवियों से संबंधित कई मुद्दे हैं जिनके अतिव्यापी समाधान होंगे। मैं प्रस्ताव करता हूं कि हम इस मुद्दे पर चर्चा के आगे फ्रैक्चर से बचने के लिए सब कुछ समेकित करें। यहाँ अपूर्ण सूची है:

संबंधित मुद्दों:

• # 5674 गैलरी छवियां उत्तरदायी नहीं हैं
• # 4505 Add 'में व्यापक-समर्थन' वर्ग और तंत्र हैं
• # 4342 विषय स्विच करते समय सामग्री गलत तरीके से प्रदर्शित होती है
• # 6131 विषय को विस्तृत / पूर्ण चित्रों के लिए आकार विशेषता को नियंत्रित करने की अनुमति दें

कोर टिकट:

• स्थैतिक छवि के साथ स्थैतिक बदलें सम्मिलित छवियों के लिए आकार
• Srcset से पूर्ण आकार का छवि पथ कैसे निकालें और srcset उम्मीदवार सूची में अधिक बुद्धिमान विकल्प
• पूर्ण आकार की छवियों का अनुकूलन करें

इस बारे में, @azaozz प्रस्ताव में:

नया डिफ़ॉल्ट आकार 2x बड़ा, 2048px अधिकतम चौड़ाई या ऊंचाई जोड़ें

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

अन्यथा, शब्द "मध्यम" और "बड़े" अपने अर्थ अर्थ खो देंगे।

इसके अलावा संबंधित: # 5650 content_width और नई ब्लॉक चौड़ाई

एक ही मूल समस्या का कारण: नई सामग्री चौड़ाई प्रतिमान उन चीजों को बनाता है जो मानक के रूप में काम नहीं करते थे और अपेक्षित रूप से कार्य करते हैं कि कोर कैसे काम करता है।

/ update / image-block एक "प्रगति में काम" है :) कृपया परीक्षण करें।

परिवर्तन:

• संपादक के अंदर srcset और sizes ।
• यदि बड़ा मौजूद नहीं है, तो हमेशा large छवि आकार, या full सम्मिलित करें।
• Default छवि आकार, Thumbnail , और प्लगइन्स और थीम द्वारा किसी भी आकार योजक को दिखाएँ।
• data-wp-attachment-id और ata-wp-percent-width को img टैग में जोड़ें। फ्रंट-एंड पर srcset और sizes ठीक से सेट करने के लिए उपयोग किया जाएगा, और width और height जहां गायब है।
• छवि आयाम सेट करने / रीसेट करने में सुधार करें।
• एपीआई से अनुलग्नक डेटा और मीडिया मोडल में डेटा में srcset जोड़ें।

करने के लिए:

• फ्रंट-एंड कोड जोड़ें जो नए img टैग विशेषताओं को संभालेगा।
• कैप्शन केंद्रित होने पर छवि से फोकस हटाएं (और रिसाइज़ हैंडल छिपाते हुए)।
• खींचकर आकार बदलने को ठीक करने का प्रयास करें। वर्तमान में बाएं या दाएं कोने को खींचना कुछ भी नहीं करता है, केवल ऊपर या नीचे खींचना छवि को आकार देता है (और चंकी है)।

@azaozz यह अब तक वास्तव में बहुत अच्छी लग रही है। अच्छा काम!

यह परीक्षण करते समय कुछ बातें जो मैंने देखी हैं:

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

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

मैं। यहाँ आकार ड्रॉपडाउन में परिवर्तन कर रहा हूँ। यदि आप इस बारे में सोच रहे हैं कि यह कस्टम क्रॉप साइज के लिए कैसे बढ़ाया जा सकता है, तो मैं उत्सुक हूं। add_image_size() विकल्प यहां शामिल किए जाने चाहिए ताकि कोई व्यक्ति किसी छवि के लिए कठिन फसली विकल्पों का एक सेट बना सके।

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

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

REST API द्वारा लौटाए गए प्रत्येक आकार और wp_prepare_attachment_for_js एक विशिष्ट srcset मूल्य जोड़ने के विकल्प से मैं आश्चर्यचकित था लेकिन यह एक चतुर दृष्टिकोण है जिसे मैंने कभी नहीं सोचा था। हमें इसके लिए कोर में एक टिकट खोलना चाहिए, ताकि हम एक बार गुटेनबर्ग भूमि के फिल्टर में इसे छोड़ने के बजाय उन प्रतिक्रियाओं के लिए स्पष्ट रूप से इस डेटा को जोड़ने के लिए पेशेवरों / विपक्ष पर चर्चा कर सकें। एक छोटा सा नोट, मुझे REST फ़िल्टर में कुछ नोटिस दिखाई दे रहे हैं कि कभी-कभी $response->data['media_type'] मौजूद नहीं होते हैं, और नोटिस फेंक रहे हैं, जो अजीब है क्योंकि इसे हमेशा परिभाषित किया जाना चाहिए। कुछ खुदाई में मज़ा आया।

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

@joemcgill एक नज़र रखने के लिए धन्यवाद!

सबसे पहले, संपादक चौड़ाई संभवतः सामने के छोर पर इच्छित प्रदर्शन चौड़ाई से मेल नहीं खा रही है

सही। यह img टैग में data-wp-percent-width विशेषता जोड़ने का कारण है। तब हम फ्रंट-एंड पर चौड़ाई को पुनर्गणना करने में सक्षम होंगे और "मैच" जो उपयोगकर्ता संपादक में देखता है। यह भी एक फोन पर संपादन के साथ संगत बनाता है, और जब विषय में सेट किया जाता है, तो हम wide और full का समर्थन करते हैं (हमें इन जोड़ने के लिए विषयों को प्राप्त करना चाहिए और सामने वाले का उपयोग करना शुरू करना चाहिए- समाप्त)।

... संपादक विशेषता के आधार पर आकार विशेषता को सहेजना शायद गलत दृष्टिकोण है

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

अब हम वर्डप्रेस में ब्लॉक पार्सर का लाभ उठा सकते हैं ...

संभवतः, लेकिन यह बहुत धीमी गति से होने वाला है। अभी के लिए फ्रंट-एंड पर ब्लॉक पार्सर को चलाना कुछ ऐसा नहीं है जो हम कर सकते हैं।

वर्तमान में, ब्लॉक डुप्लिकेट विशेषता डेटा को छवि ब्लॉक की टिप्पणी परिसीमन और मार्कअप में सहेज रहा है।

कि ब्लॉक गुण कैसे काम करते हैं। वैकल्पिक रूप से हम कुछ regex के साथ छवि ब्लॉक को "एक्सट्रैक्ट" कर सकते हैं और छवि टैग की तलाश में उनमें HTML को पार्स कर सकते हैं। फिर भी ... regex के साथ HTML का थोड़ा सा भी पार्स करना ऐसा लगता है जैसे हमें कुछ बचना चाहिए। तो अब के लिए वास्तविक img टैग में संपादक से सभी आवश्यक संदर्भ जोड़ने के लिए सोच रहा था।

यदि आप इस बारे में सोच रहे हैं कि यह कैसे कस्टम फसल के आकार (आकार में गिरावट) के लिए बढ़ाया जा सकता है तो मैं उत्सुक हूं

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

बग जो मैं भाग गया था, एक छवि सम्मिलित कर रहा था, स्रोत प्रकार को थंबनेल पर सेट करना, एक ड्राफ्ट सहेजना, और फिर पृष्ठ को ताज़ा करना।

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

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

हाँ, यह सोचकर कि पिछला व्यवहार वहाँ बेहतर था। हमें शायद 50% चौड़ाई पर दाएं / बाएं संरेखित चित्रों को सेट करने के लिए वापस जाना चाहिए। अगर हम उस विशेषता को img टैग के लिए रख रहे हैं, तो हम sizes भी बदल सकते हैं।

REST API द्वारा और wp_prepare_attachment_for_js द्वारा लौटाए गए प्रत्येक आकार में एक विशिष्ट srcset मान जोड़ने के चुनाव से मैं हैरान था

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

हमें इसके लिए कोर में एक टिकट खोलना चाहिए ...

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

मुझे REST फ़िल्टर में कुछ नोटिस दिखाई दे रहे हैं जो कभी-कभी $ प्रतिक्रिया-> डेटा ['media_type'] मौजूद नहीं होता है

हम्म, हमें शायद उसके लिए एक कोर ट्रेक टिकट खोलना चाहिए। यह हमेशा मौजूद होना चाहिए।

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

मैं WCEU योगदानकर्ता दिन पर @azaozz के साथ एक बातचीत की और इस आगे बढ़ने के प्रयास में हर किसी के साथ अपने विचारों को साझा करना चाहते हैं।

__Context: __ फ्रंट-एंड (थीम / प्लगइन क्षेत्र)
__Assumations: __ प्रस्ताव @azaozz द्वारा आगे रखा गया है: उपलब्ध स्थान के सापेक्ष प्रदर्शित चौड़ाई के साथ data-wp-percent-width विशेषता सेट करना।

प्रस्ताव

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

निम्नलिखित परिदृश्यों पर विचार करें, i के माध्यम से:

ऐतिहासिक रूप से, हमने प्रदर्शित की गई किसी भी छवि के बारे में दो बातें जानी हैं: छवि फ़ाइल की भौतिक चौड़ाई, और $content_width जैसा कि विषय द्वारा परिभाषित किया गया है। फिर हमने sizes विशेषता का पता लगाने के लिए इन दो मापदंडों का उपयोग किया।

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

ये उदाहरण दिखाते हैं कि _two constants_ हैं जिन्हें थीम डेवलपर (और एक्सटेंशन प्लगइन डेवलपर्स) द्वारा आसानी से परिभाषित किया जा सकता है:

• $content_width - सामग्री की अधिकतम चौड़ाई जब इसे alignwide या alignfull रूप में प्रदर्शित नहीं किया जाता है।
• $max_display_area - यदि सामग्री alignfull सेट है, तो उपलब्ध होने वाली अधिकतम उपलब्ध जगह।

एक तीसरी धारणा यह भी है कि हम क्या कर सकते हैं:

• एक तत्व alignwide के लिए उपलब्ध $content_width और $max_display_area बीच उपलब्ध स्थान का पूरा $content_width प्लस आधा ले जाएगा, और इसकी गणना की जा सकती है

$content_width + ( $max_display_area - $content_width ) / 2

दूसरे शब्दों में, यदि वर्डप्रेस $content_width और $max_display_area मूल्यों को जानता है, तो यह उस स्थान की सही गणना कर सकता है जिसके अंदर सामग्री प्रदर्शित होती है और वहाँ से यह निर्धारित होता है कि sizes विशेषता क्या है एक प्रदर्शित छवि इस बात पर आधारित है कि यह कैसे प्रदर्शित की जाती है, जिसमें @azaozz द्वारा पेश किए गए नए data-wp-percent-width शामिल हैं।

व्यावहारिक आवेदन

थीम डेवलपर दो मूल्यों को परिभाषित करता है:

• $content_width किसी भी प्रदर्शन की स्थिति के लिए अधिकतम alignwide या alignfull लागू होती है) की घोषणा नहीं करता है।
• $max_display_area किसी भी प्रदर्शन की स्थिति के लिए अधिकतम उपलब्ध चौड़ाई की घोषणा।

ये दोनों मान शर्तों के आधार पर परिवर्तनशील होंगे इसलिए न तो वैश्विक रूप से $content_width है (जब तक कि मुझे गलतफहमी नहीं है कि $content_width वर्तमान में कैसे काम करता है)।

alignwide या alignfull प्रदर्शित छवियों के लिए, $content_width चर (और यदि उपलब्ध हो तो कस्टम चौड़ाई डेटा-विशेषता) sizes विशेषता निर्धारित करने के लिए पर्याप्त है: प्रदर्शित आकार कभी भी डेटा-विशेषता द्वारा परिभाषित $content_width या $content-width कुछ प्रतिशत से अधिक व्यापक नहीं होगा। यह वर्तमान कार्यप्रणाली btw की तुलना में थीम डेवलपर्स के लिए स्थापित करने के लिए काफी सरल होगा।

alignwide या alignfull संदर्भ में प्रदर्शित छवियों के लिए, हमें $max_display_area मूल्य का उपयोग करने की आवश्यकता है। यह _could_ इस चर को व्यूपोर्ट चौड़ाई और उपलब्ध प्रदर्शन क्षेत्रों की जोड़ी के रूप में परिभाषित करने के लिए समझ में आता है। यह सरणी डेटा-विशेषता के संयोजन में, मक्खी पर उत्पन्न sizes विशेषताओं में बदल सकती है।

तो एक विषय से ऊपर के उदाहरणों के लिए कुछ इस तरह की घोषणा की जाएगी:

// In this theme there is a fixed maximum content width of 720px.
$content_width = 720px;

if ( is_active_sidebar( 'sidebar-1' ) {
  $max_display_area = [
    'min-width: 48em' => 'calc( 100vw - 30em), // sidebar is 30em wide.
    'fallback' => '100vw',
  ];
} else {
  $max_display_area = [
    'fallback' => '100vw',
  ];
}

डी, ई, और एफ के लिए मान लें, तो विराम बिंदु जहां साइडबार दिखाई देता है 48em और g, h, और i के लिए, data-wp-percent-width विशेषता 50% है, परिणामस्वरूप sizes उदाहरणों के लिए विशेषताएँ इस टिप्पणी के शीर्ष पर निम्नानुसार होगा:

/**
 * a: Image width is equal to $content_width area.
 */
sizes="(min-width: $content_width) $content_width, fallback"
sizes="(min-width: 720px) 720px, 100vw"

/**
 * b: Image width is 50% of the available space between $content_width and $max_display_area.
 */
sizes="(min-width: $content_width) calc(($max_display_area - $content_width) / 2), fallback"
sizes="(min-width: 720px) calc((100vw - 720px) / 2), 100vw"

/**
 * c: Image width is equal to fallback.
 */
sizes="fallback"
sizes="100vw"

/**
 * d: Image widths is equal to $content_width area.
 */
sizes="(min-width: $content_width) $content_width, fallback"
sizes="(min-width: 720px) 720px, 100vw"

/**
 *e: Image width is $content_width plus 50% of the available space between $content_width and $max_display_area.
 */
sizes="(min-width: $content_width) calc(($max_display_area - $content_width) / 2), fallback"
sizes="(min-width: 720px) calc((100vw - 30em) - 720px) / 2, 100vw"

/**
 * f: Image width is equal to $max_display_area.
 */
sizes="$max_display_area, fallback"
sizes="(min-width: 48em) calc(100vw - 30em), 100vw"

/**
 * g: Image width is 50% of $content_width. 
 */
sizes="(min-width: $content_width) calc($max_display_area * (data-wp-percent-width / 100)), calc(fallback * (data-image-width / 100))"
sizes="(min-width: 720px) calc(720px * .5), calc(100vw * .5)"

/**
 * h: Image width is 50% of $content_width plus 50% of the available space between $content_width and $max_display_area.
 */ 
sizes="(min-width: $content_width) calc((($max_display_area - $content_width) / 2) * (data-wp-percent-width / 100)), calc( fallback * (data-image-width / 100))"
sizes="(min-width: 720px) calc(((100vw - 720px) / 2) * .5), calc(100vw * .5)"

/**
 * i: Image width is equal to 50% of fallback.
 */
sizes="calc(fallback * (data-wp-percent-width / 100))"
sizes="calc(100vw * .5)"

धन्यवाद @ mor10 , बहुत अच्छी तरह से :)

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

मेरे पास कुछ छोटे सुझाव / स्पष्टीकरण हैं।

$content_width - सामग्री की अधिकतम चौड़ाई जब इसे संरेखित या संरेखित के रूप में प्रदर्शित नहीं किया जाता है।
$max_display_area - यदि सामग्री को संरेखित करने के लिए सेट किया गया हो तो उपलब्ध अधिकतम उपलब्ध स्थान।

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

तो ये कुछ इस तरह होने चाहिए:

• $content_width
• $alignwide_width
• alignfull_width

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

एक और महत्वपूर्ण अंतर यह है कि हम इन नई चौड़ाई को "प्रासंगिक" होने की उम्मीद करेंगे। यानी HTML चालू करने से पहले उन्हें वर्तमान टेम्पलेट द्वारा सेट किया जाना चाहिए (और शायद अंत में रीसेट करें)। यह सभी चित्रों के लिए अधिक सटीक sizes विशेषताएँ उत्पन्न करने के लिए महत्वपूर्ण है।

गुटेनबर्ग न केवल alignwide और alignfull चौड़ाई का परिचय देते हैं, बल्कि विभिन्न तत्वों को wide या full बनाने की क्षमता भी रखते हैं।

ऐसा मत सोचो कि हमें उस पुन: छवियों के बारे में चिंतित होने की आवश्यकता है। यदि कोई ब्लॉक full सेट है, तो इसमें alignfull छवि होने का कोई अर्थ नहीं होगा। यह बिल्कुल "सामान्य" छवि के समान होगा। wide ब्लॉक के लिए समान।

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

ऐसा मत सोचो कि हमें उस पुन: छवियों के बारे में चिंतित होने की आवश्यकता है। यदि कोई ब्लॉक full सेट है, तो इसमें alignfull छवि होने का कोई अर्थ नहीं होगा। यह बिल्कुल "सामान्य" छवि के समान होगा। wide ब्लॉक के लिए समान।

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

नमस्कार @ mor10 , आपके उदाहरण में, 'b' के लिए आकार नहीं होना चाहिए:

आकार = "(न्यूनतम-चौड़ाई: $ सामग्री_प्रक्रिया) कैल्क ($ सामग्री_प्रक्रिया + ($ max_display_area - $ content_ उपलब्धता) / 2), फॉलबैक"

?

@alialaa गणित अच्छी तरह से

@azaozz हम इसके साथ कहाँ हैं? मैंने आधिकारिक गुटेनबर्ग स्टार्टर थीम के साथ गुटेनबर्ग 3.3 का परीक्षण किया और जहां तक ​​मैं बता सकता हूं कि वर्तमान ब्लॉक सब कुछ के लिए पूर्ण छवि आकार का उपयोग कर रहे हैं। प्लगइन सक्रिय होने पर यह एक महत्वपूर्ण प्रदर्शन हिट का कारण बनता है।

@ mor10 मैं कुछ ऐसा लागू करने की कोशिश कर रहा हूं जो आपके द्वारा प्रदान किए गए कोड ( wp_calculate_image_sizes फ़िल्टर) के समान है, सिवाय इसके कि मैं एक बड़े विषय के लिए इसे प्राप्त करने की कोशिश कर रहा हूं जिसमें बहुत अधिक लेआउट विविधताएं हैं। अब तक का सबसे बड़ा मुद्दा विषय में दिखाई देने वाली हर जगह के लिए sizes विशेषता का एक मजबूत जनरेटर लागू करना है। सबसे बड़ी समस्याएं हैं:

• द्रव बनाम निश्चित चौड़ाई लेआउट
• ग्रिड प्रणाली (कंटेनर से पर्केंट्स में)
• ग्रिड का गैप
• साइडबार उपस्थिति / अनुपस्थिति
• एकाधिक मीडिया क्वेरी विराम बिंदु

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

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

बात के लिए मान्य पैरामीटर हैं:

1. bootstrap_class : बहुत लंबा हो सकता है, बूटस्ट्रैप क्या स्वीकार करता है, यह वास्तव में पार्स किया जाता है और कई मीडिया क्वेरी उत्पन्न करने के लिए उपयोग किया जाता है
2. gutters : सच | असत्य। गणना में 30px गटर डालें या नहीं। यह राशि विन्यास योग्य है
3. fluid : सच | असत्य। गैर-तरल लेआउट सबसे कठिन हैं, उनके पास पिक्सेल में max-width हैं

यहां कुछ परीक्षण मामले हैं जो वास्तव में JSON प्रारूप में पास होते हैं (प्रत्येक प्रविष्टि एक परीक्षण मामला है, पहली वस्तु मेरे तर्क के लिए इनपुट है, और दूसरा आउटपुट है):

[
    [

        {"bootstrap_class": "col-md-12", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(100vw - 30px)"}]
    ],

    [
        {"bootstrap_class": "col-sm-12", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(100vw - 30px)"}]
    ],

    [
        {"bootstrap_class": "col-xs-6", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(50vw - 30px)"}]
    ],
    [
        {"bootstrap_class": "col-xs-8", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(66.6667vw - 30px)"}]
    ],
    [
        {"bootstrap_class": "col-xs-5", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(41.6667vw - 30px)"}]
    ],
    [
        {"bootstrap_class": "col-xs-9", "gutters": true, "fluid": true},
        [{"media_query": false, "image_size": "calc(75vw - 30px)"}]
    ],
    [
        {
            "bootstrap_class": "col-xs-10 col-sm-3 col-md-7 col-lg-11 col-xl-5",
            "gutters": true,
            "fluid": true
        },
        [
            {"media_query": "1300px", "image_size": "calc(41.6667vw - 30px)"},
            {"media_query": "1000px", "image_size": "calc(91.6667vw - 30px)"},
            {"media_query": "690px", "image_size": "calc(58.3333vw - 30px)"},
            {"media_query": "480px", "image_size": "calc(25vw - 30px)"},
            {"media_query": false, "image_size": "calc(83.3333vw - 30px)"}
        ]
    ]
]

आउटपुट प्राप्त करने के बाद, इसे आसानी से HTML में डाले जाने के लिए तैयार एक उचित sizes विशेषता में इकट्ठा किया जा सकता है।

उदाहरण के लिए, यहां पर बहुत जटिल col-xs-10 col-sm-3 col-md-7 col-lg-11 col-xl-5 छवि के लिए आउटपुट क्या होना चाहिए:

[
    {
        "bootstrap_class": "col-xs-10 col-sm-3 col-md-7 col-lg-11 col-xl-5",
        "gutters": true,
        "fluid": true
    },

    [
        {"media_query": "1300px", "image_size": "calc(41.6667vw - 30px)"},
        {"media_query": "1000px", "image_size": "calc(91.6667vw - 30px)"},
        {"media_query": "690px", "image_size": "calc(58.3333vw - 30px)"},
        {"media_query": "480px", "image_size": "calc(25vw - 30px)"},
        {"media_query": false, "image_size": "calc(83.3333vw - 30px)"}
    ]
],

अंतिम इकट्ठे HTML में कौन सा ऐसा दिखेगा:

<div class="container-fluid">
  <div class="row">
    <div class="col-xs-10 col-sm-3 col-md-7 col-lg-11 col-xl-5">

      <img
        srcset="..."
        sizes="
          (min-width: 1300px) calc(41.6667vw - 30px),
          (min-width: 1000px) calc(91.6667vw - 30px),
          (min-width: 690px) calc(58.3333vw - 30px),
          (min-width: 480px) calc(25vw - 30px),
          calc(83.3333vw - 30px),
        "
      >

    </div>
  </div>
</div>

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

इसके अलावा, कभी-कभी bootstrap_class पर्याप्त नहीं होता है और हमें कच्चे प्रतिशत में छवि की चौड़ाई को व्यक्त करने में सक्षम होने की आवश्यकता होती है।

अगर दिलचस्पी है, तो मैं इस चीज़ के बारे में कहीं और विस्तृत बातचीत कर सकता हूं, मैं वास्तव में इसे ठीक से आगे बढ़ाने में दिलचस्पी रखता हूं, अभी भी बहुत सारी समस्याएं हैं जिनका मैं सामना करता हूं hop

8593 ने व्यक्तिगत गैलरी छवियों में srcset और sizes विशेषताओं को जोड़ा है, लेकिन sizes विशेषता अभी भी कार्य करती है जैसे कि प्रत्येक छवि दृश्य की पूरी सामग्री चौड़ाई को लेती है जो शायद ही कभी होती है। मामला।

संबंधित: # 1450

हम इस के साथ कहाँ हैं?

इसे देखते हुए, थोड़ी देर के लिए afk था। आशा है कि कुछ दिनों में एक अद्यतन, "काम करने योग्य" शाखा होगी।

छवि ब्लॉक शाखा अपडेट करें: https://github.com/WordPress/gutenberg/tree/update/image-block। पिछले अद्यतन के बाद से कुछ बदलाव, सभी नई / आवश्यक कार्यक्षमता है, कृपया परीक्षण करें!

@joemcgill @getsource @ mor10 कल एक जनसंपर्क करने की सोच, शाखा की समीक्षा की सराहना की :)

फिर से ब्रांच अपडेट करें। लगभग तैयार है, बस और अधिक परीक्षण की आवश्यकता है :)

WP 5.0 मील के पत्थर में इसे जोड़ना क्योंकि यह काफी महत्वपूर्ण है कि हम पोस्ट सामग्री में डाली गई छवियों के साथ प्रदर्शन प्रतिगमन को प्रस्तुत नहीं करते हैं और मैं यहां अपडेट की समीक्षा करना नहीं भूलना चाहता।

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

Srcset के माध्यम से समाधान इस ब्लॉक के लिए काम नहीं करेगा।

बीस उन्नीस अब इस मुद्दे के लिए एक ठोस परीक्षण मैदान प्रदान करता है। अधिक जानकारी के लिए https://github.com/WordPress/twentynineteen/issues/50#issuecomment -434120505 देखें।

@azao Twenty Nineteen का उपयोग करके संदर्भित शाखा को चलाने से, मेरी सम्मिलित छवि को निम्न मार्कअप प्राप्त होता है:

<img 
  src="http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049-1024x768.jpg" 
  alt="Big Sur" 
  width="640" 
  height="480" 
  srcset="http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049-1024x768.jpg 1024w, http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049-300x225.jpg 300w, http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049-768x576.jpg 768w, http://gutenberg.local:8888/wp-content/uploads/2011/07/michelle_049.jpg 1600w" 
  sizes="(max-width: 640px) 100vw, 640px">

ऐसा लगता है कि थीम में content_width वैश्विक सेट का मिलान करने के लिए अधिकतम चौड़ाई निर्धारित है।

नई कार्यक्षमता का परीक्षण करने के लिए मुझे क्या नया मार्कअप (यदि कोई हो) थीम में जोड़ना चाहिए?

@ mor10 सही है, यह $content_width PHP ग्लोबल का उपयोग कर रहा है। यह नए शुरू किए गए $block_width वैश्विक की गिरावट है जिसमें तीन मूल्य शामिल होने चाहिए: डिफ़ॉल्ट, विस्तृत और पूर्ण, देखें: https://github.com/WordPress/gutenberg/blob/update/image-block-packages /block-library/src/image/index.php#L26 (ध्यान दें कि ये चौड़ाई अधिकतम-चौड़ाई की तरह ही काम करती हैं, जैसे (पुराना) $content_width )।

परीक्षण करने के लिए, शायद छवि खंड में phpdoc से उदाहरण का अनुसरण करें:

/**
 * Get the expected block width from the global $block_width array.
 *
 * The global $block_width array is expectd to be set by the theme for each block container.
 * It should contain three values: default, wide and full, in pixels.
 * - The `default` value should be the expected block width (similarly to $content_width).
 * - The `wide` value is optional and is used when the block alignment is set to `wide`.
 * - Similarly the `full` value is optional and used then the alignment is set to `full`.
 * If `wide` and `full` are not set, the `default` value is used instead.
 *
 * Example:
 *     $GLOBALS['block_width'] = array(
 *         'default' => 640,
 *         'wide'    => 800,
 *         'full'    => 1024,
 *     );
 *
 * In addition the $block_width array should be set contextually for each block container.
 * For example: in the main content column the `default` width will be something like 640(px),
 * but for a sidebar it would be something like 250.

यदि आप अधिक सटीक sizes विशेषता सेट करना चाह रहे हैं, तो सबसे अच्छा तरीका अभी भी https://developer.wordpress.org/reference/hooks/wp_calculate_image_sizes/ फ़िल्टर का उपयोग करना होगा। विषयों के लिए कुछ "आसान" जोड़ने पर देखा गया है, लेकिन उचित sizes करना अत्यधिक प्रासंगिक है और स्टाइल (कॉलम, ब्रेकप्वाइंट, मार्जिन, पैडिंग, आदि) पर निर्भर करता है। वहाँ एक "आसान तरीका" नहीं है, विषय पर पूर्ण नियंत्रण छोड़ने के लिए सबसे अच्छा (यानी फ़िल्टर का उपयोग करें)।

पिक्सल में यह मान क्यों है? कई (शायद सबसे) थीम चौड़ाई के लिए पिक्सेल मान का उपयोग नहीं करेंगे। बीस उन्नीस लेकिन एक उदाहरण है। किसी भी चौड़ाई मान का उपयोग करके चौड़ाई को परिभाषित करना संभव होना चाहिए। उदाहरण के लिए, पूर्ण-चौड़ाई वाली छवियां ज्यादातर मामलों में 100vw होंगी।

इसके अलावा, यह एक वैश्विक, बनाम add_theme_support विकल्प या फ़िल्टर के माध्यम से सेट क्यों हो रहा है?

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

पिक्सल में यह मान क्यों है

क्योंकि छवि (फ़ाइल) का आकार पिक्सेल में है और क्योंकि हमें <img> टैग का width और height विशेषताएँ (सर्वोत्तम अभ्यास) सेट करने की आवश्यकता है। sizes विशेषता में डिफ़ॉल्ट रूप से 100vw का उपयोग किया जाता है, लेकिन थीम को "संरेखित पूर्ण" छवि ब्लॉक के लिए भी स्वीकार्य अधिकतम-चौड़ाई पास करनी चाहिए।

संभवतः ऐसे विषय हैं जो यह तय करेंगे कि साइट विज़िटर को 3-4MB चित्र डाउनलोड करना चाहिए जब तक कि साइट 2560px स्क्रीन पर अच्छी लगती है। दूसरों को अधिक व्यावहारिक और सीमित किया जाएगा कि कुछ हद तक "समझदार" मूल्य।

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

यह एक वैश्विक, एक add_theme_support विकल्प बनाम एक फ़िल्टर के रूप में सेट क्यों हो रहा है

यह विचार इस वैश्विक के लिए "संदर्भात्मक" है, अर्थात अलग-अलग "टेम्पलेट" के लिए अलग-अलग मान हैं। ऐसा करने के कई तरीके हैं, लेकिन एक PHP ग्लोबल या फायरिंग एक WP कार्रवाई का उपयोग करना आसान लगता है।

@azaozz देखें https://github.com/WordPress/twentynineteen/pull/411 हमने यह पता लगाने के तरीके के बारे में बात की कि क्या वर्तमान छवि को नियमित रूप से प्रदर्शित किया गया था, alignwide , या alignfull wp_calculate_image_sizes थोड़ी देर पहले से। मेरा मानना ​​है कि एक विचार <img> तत्व के अंदर एक डेटा विशेषता जोड़ना था। इस संदर्भ की जानकारी के बिना मैं नहीं देखता कि मैं तीन लेआउट विकल्पों के लिए sizes कैसे सही प्रदान कर सकता हूं। विचारों का स्वागत है।

इस संदर्भ की जानकारी के बिना ...

सही। यह जानकारी $block_attributes सरणी में है। इसे (नया) render_block_core_image_tag_attributes फ़िल्टर (बेहतर नाम की आवश्यकता हो सकती है ...) पास किया जा रहा है। एक बार जब गुटेनबर्ग और कोर में विलय हो जाता है, तो मुझे लगता है कि हम दोनों wp_calculate_image_srcset और wp_calculate_image_sizes फिल्टर को ब्लॉक विशेषताओं को पारित करने में सक्षम होंगे।

उस पर आप कहां हैं? क्या मैं वर्तमान में इसका परीक्षण कर सकता हूं?

अभी तक यह कोर फ़ाइलों को संशोधित नहीं करता है। इसे "हैक" के रूप में जोड़ सकते हैं :)

आवश्यकताओं पारित करने के लिए $block_attributes जब बुला wp_calculate_image_srcset() और wp_calculate_image_sizes() , देख https://github.com/WordPress/gutenberg/blob/update/image-block/packages/block- पुस्तकालय / src / image / index.php # L210 और https://github.com/WordPress/gutenberg/blob/update/image-block/packages/block-library/src/image/index.php#L213। फिर इन फ़ंक्शंस में /wp-includes/media.php पर फ़िल्टर करें।

परीक्षण के लिए धन्यवाद!

क्या मुझे टिकट मिलने के लिए कोई कोर टिकट चाहिए? GB और ट्वेंटी उन्नीस को तब तक जारी नहीं किया जा सकता जब तक कि यह imo हल न हो जाए।

@azaozz मुझे कल शाखा का कुछ परीक्षण करने का मौका मिला (देरी के लिए खेद है)। मैं बहुत कुछ करना चाहता हूं, लेकिन निम्नलिखित प्रतिक्रिया छोड़ना चाहता था:

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

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

अतिरिक्त नोट्स:

मैंने देखा कि संपादक में, क्रोम अब हर छवि के दो संस्करण डाउनलोड कर रहा है (यह मास्टर शाखा पर नहीं होता है)। दूसरे की स्विचिंग के कारण है src में छवि घटक के गुण fetchImageSize() के दौरान जो कहा जाता है componentDidMount । यह घटक के लिए srcset और sizes को जोड़ने से होने वाले किसी भी लाभ को नकार देता है।

पूर्ण-चौड़ाई वाली छवियों पर, अधिकतम-चौड़ाई 1024px पर छाया जा रहा है जो पूर्वावलोकन को तोड़ता है। यह मास्टर में नहीं होता है।

मैं परीक्षण और नोट्स जोड़ना जारी रखूंगा , लेकिन करूंगा कि यह पीआर के रूप में समीक्षा करने में सक्षम होगा। धन्यवाद!

@joemcgill परीक्षण के लिए धन्यवाद! :)

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

यह कुछ ऐसा है जिसे हमने कुछ साल पहले देखा था जब srcset और sizes । सिद्धांत रूप में, जो कुछ हद तक संभव लगता है, हालांकि व्यवहार में ऐसा बहुत कम होता है कि इसे प्लगइन्स को संभालने के लिए छोड़ दिया जाए। जब sizes सामग्री sizes srcset और sizes जाती है, तब सामग्री एक WP साइट से निर्यात की जाती है और दूसरे में अनुलग्नक आईडी बदल जाती है (लेकिन URL नहीं बदलते)।

हालाँकि इस मामले में srcset और sizes विशेषताएँ विशुद्ध रूप से संपादक के लिए हैं। वे हमेशा सामने के छोर पर पुनर्जीवित होते हैं, https://github.com/WordPress/gutenberg/blob/update/image-block/packages/block-library/src/image/index.php#L244 देखें।

अभी भी लगता है कि हमें आयातित सामग्री को ठीक करने के रूप में srcset विशेषता का पुन: उपयोग करने के लिए WP 5.1+ के लिए एक कोर टिकट खोलना चाहिए। डिफ़ॉल्ट sizes विशेषता थीम अज्ञेयवादी है, लेकिन यह सोचकर इसे हमेशा सामने के छोर पर पुनर्जीवित और फ़िल्टर किया जाना चाहिए।

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

बिल्कुल नहीं :) वर्तमान में गुटेनबर्ग ने "पूर्ण आकार की" छवियों को संपादक और फ्रंट-एंड दोनों पर दिया है। यह सच है कि srcset विशेषता <img> टैग में जोड़ी जाती है, लेकिन डिफ़ॉल्ट sizes विशेषता को देखें। यह "borked" है :)

मुझे लगता है कि विषयों को आकार विशेषताओं को संशोधित करने के लिए उपलब्ध फिल्टर में सुधार पर ध्यान केंद्रित किया जाना चाहिए ...

बिलकुल सहमत। इसमें कुछ नए फ़िल्टर जोड़े गए हैं जो वहां मदद करते हैं, लेकिन सबसे महत्वपूर्ण बात यह है कि हमें block_attributes से लेकर wp_calculate_image_sizes फ़िल्टर (भी wp_calculate_image_srcset मिलान करने के लिए) पास करना चाहिए।

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

मैंने देखा कि संपादक में, क्रोम अब हर छवि के दो संस्करण डाउनलोड कर रहा है

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

पूर्ण-चौड़ाई वाली छवियों पर, अधिकतम-चौड़ाई 1024px पर छाया जा रहा है जो पूर्वावलोकन को तोड़ता है। यह मास्टर में नहीं होता है।

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

मैं परीक्षण और नोट्स जोड़ना जारी रखूंगा

हाँ कृपया! :)
आज रात एक पीआर बनाने के बारे में सोच, लगता है कि छवियों को संभालने के सबसे किनारे के मामले हैं।

हालाँकि इस मामले में सम्पादक और आकार विशेषताएँ विशुद्ध रूप से संपादक के लिए हैं।

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

बिल्कुल नहीं :) वर्तमान में गुटेनबर्ग ने "पूर्ण आकार की" छवियों को संपादक और फ्रंट-एंड दोनों पर दिया है। यह सच है कि srcset विशेषता को इसमें जोड़ा गया है टैग, लेकिन वहाँ डिफ़ॉल्ट आकार विशेषता को देखो। यह "borked" है :)

यहाँ सही है, उपयोगी अंतर यह है कि छवि की चौड़ाई विशेषता को गलत तरीके से सहेजा जा रहा है, क्योंकि हम अब छवि आकार को content_width लिए विवश नहीं कर रहे हैं।

यह केवल ताज़ा अपलोड की गई छवियों के लिए होता है।

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

सही। यहां विकल्प 2-4MB या कभी-कभी बड़ी छवियों को डाउनलोड करना है। यह अस्वीकार्य है, भले ही केवल संपादक में।

क्षमा करें, मुझे नहीं लगता कि मैं यहां स्पष्ट था। मैं जो देख रहा हूं वह संपादक में रैपिंग div पर इनलाइन शैली द्वारा सीएसएस में सीमित की जा रही छवि चौड़ाई है। यहाँ कुछ स्क्रीनशॉट मदद करने के लिए हैं:

सम्पूर्ण चौड़ाई में फैले संपादक में पूर्ण आकार की छवि - https://cloudup.com/cHob4kcjLrN

इंस्पेक्टर में ऊपर का मार्कअप - https://cloudup.com/cIVWetqpSoF

इस टिकट का दायरा बहुत बड़ा है, लेकिन कुछ बिट्स हैं जो WP 5.0 के लिए महत्वपूर्ण हैं। क्या हम उन विशिष्ट मुद्दों को तोड़ सकते हैं जो प्रतिगमन होंगे? जैसा कि मैंने इसे देखा, इसमें शामिल हैं:

• [] सामने के छोर पर लोड करने से पूर्ण आकार के चित्र रखें।
• [] पोस्ट कॉन्टेंट में सबसे उपयुक्त width से img तत्वों को बचाएं (सर्वोत्तम अभ्यास, लेकिन उत्तरदायी छवियों के लिए डिफ़ॉल्ट sizes विशेषता की गणना के लिए भी प्रासंगिक है)।

उच्च प्राथमिकता, संवर्द्धन:

• [] छवि संरेखण (# 6131) के आधार पर सामने के छोर पर sizes को फ़िल्टर करने का एक तरीका प्रदान करें।
• [x] सम्पूर्ण आकार के चित्र संपादक में लोड होने से रखें।

संवर्द्धन (अच्छा है):

• [] संपादक में छवि लोड करने के प्रदर्शन में सुधार (जैसे, उत्तरदायी छवियों के माध्यम से)
• [] संपादक और सामने के छोर के बीच मैन्युअल रूप से आकार की छवि चौड़ाई से निपटने में सुधार।
• [] 2x बड़े के लिए एक अतिरिक्त उत्पन्न छवि आकार जोड़ें (हमें यहां छवि पीढ़ी पर प्रभाव का मूल्यांकन करने की आवश्यकता है। यह https://core.trac.wordpress.org/ticket/37840 से संबंधित है जो https: // द्वारा अवरुद्ध है। core.trac.wordpress.org/ticket/40439)

मुझे कुछ भी याद आ रहा है?

इस विषय के लिए और सामान्य रूप से गुटेनबर्ग के लिए एक अवरोधक क्यों है, ट्वेंटी उन्नीस रेपो में एक उदाहरण प्रदान किया। वर्तमान में गुटेनबर्ग द्वारा किया गया प्रदर्शन महत्वपूर्ण है: https://github.com/WordPress/twentynineteen/issues/50#issuecomment -436829300

मेरे परीक्षण से, उत्तरदायी छवियां अभी भी 5.0 आरसी 1 में हल नहीं हुई हैं। wp_calculate_image_sizes में ब्लॉक गुण विशेषता नहीं होती है, और # 11973 से render_block_core_image_tag_attributes विलय नहीं हुआ है।

इस पर एक बिंदु भी ठीक नहीं है, लेकिन इसका मतलब यह है कि सभी छवियों को संपादक के भीतर मैन्युअल रूप से आकार नहीं दिया गया है और alignnone , alignwide , और RC1 में alignfull को तोड़ा गया है क्योंकि sizes विशेषताएँ गलत हैं।

परीक्षण करने के लिए, बीस उन्नीस को सक्रिय करें, एक पोस्ट में एक बड़ी छवि (1200px या व्यापक) अपलोड करें, इसे none , alignwide , या alignfull संरेखित करें, और आउटपुट sizes जाँच करें

sizes="(max-width: 1024px) 100vw, 1024px"

इसका मतलब किसी भी स्थिति के लिए जिसमें छवि 1024px से अधिक व्यापक दिखाई देती है (इसलिए बहुत सारे उदाहरण जहां एक लैपटॉप / डेस्कटॉप उपयोग में है), ब्राउज़र एक 1024px चौड़ी स्रोत छवि को लोड करेगा और इसे धब्बा पैदा करेगा।

इसे मर्ज करने की क्या योजना है। मैं तुम्हारी सहायता के लिए क्या कर सकता हूँ?

सम्बंधित:

• कोर टिकट 45406: व्यापक व्यूपोर्ट को समायोजित करने के लिए srcset के लिए अतिरिक्त डिफ़ॉल्ट छवि आकार जोड़ें
• कोर टिकट 45407: sizes विशेषता के उचित संचालन के लिए अनुमति देने के लिए wp_calculate_image_sizes लिए ब्लॉक विशेषताएँ जोड़ें

वर्तमान और सही व्यवहार को दिखाने के लिए एक परीक्षण के लिए अनुरोध किया गया है, इसलिए मैंने उन दोनों को बनाया है:

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

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

• डेमो 1: कोर https://gutenberg.mor10.com/image-test-current/ द्वारा प्रदान किए गए ऑटो-जनरेट किए गए आकार
• डेमो 2: सही आकार वाली समान सामग्री https://gutenberg.mor10.com/responsive-images-demo-corrected-code/

इतने विचार और देखभाल करने के लिए आप सभी का धन्यवाद। मैं दो पेचीदा चिंताओं को देखता हूं जिन्हें आगे बढ़ने के लिए अलग किया जाना चाहिए।

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

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

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

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

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

सही संदर्भ के लिए सही छवि देने में सक्षम होना महत्वपूर्ण है।

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

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

• अन्य गैर wp:image ब्लॉक के लिए स्केलिंग अनसुलझी बनी हुई है।
• अपरंपरागत सर्वर कार्यान्वयन (संभावना # 10108 जैसे कुछ की आवश्यकता है) जो जटिलता को जोड़ता है।
• छवि मार्कअप _ad hoc_ (सर्वर बनाम क्लाइंट) को पुन: पेश करने में ओवरहेड, संभावित एक्सटेंशन और फ़िडेलिटी क्लाइंट की ओर से टकराव।
• प्रतिशत के आकार के आसपास अपेक्षित UX में असमानता।
• विषय पक्ष पर बहुत अधिक जिम्मेदारी।
• इससे भी महत्वपूर्ण बात, चरण 2 शर्तों और आवश्यकताओं के साथ ओवरलैप में अस्पष्टता।

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

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

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

innerBlocks( 'post-content', sizes: {
    default: 600,
    wide: 1000,
    full: 100vw,
}

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

जो हमें भी करने की अनुमति देगा:

innerBlocks( 'sidebar', sizes: {
    default: 300,
    wide: false,
    full: false
} )

और इसी तरह।

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

धन्यवाद @mtias ,

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

पूर्व के बारे में, मैं अनिश्चित हूं कि हमने उन मुद्दों को पूरी तरह से संबोधित किया है, जिन्हें मैं https://github.com/WordPress/gutenberg/issues/6177#issuecomment -435091640 में विशेष रूप से रेखांकित करता हूं:

पोस्ट कॉन्टेंट में सबसे उपयुक्त width से img तत्व (सर्वोत्तम अभ्यास, लेकिन उत्तरदायी छवियों के लिए डिफ़ॉल्ट sizes विशेषता की गणना के लिए भी प्रासंगिक) सहेजें।

अगर हम इस बात की पुष्टि कर सकते हैं कि मुझे संबोधित किया गया है, तो मैं 5.0.x रिलीज और उससे आगे की हर चीज के साथ सहज रहूंगा।

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

ऊपर @joemcgill के साथ पूरी तरह से सहमत ^

आप जिस उच्च स्तरीय प्रयास के बारे में बात कर रहे हैं, उसके साथ मिलकर काम करना पसंद करूंगा, और यह ऐसी चीज है जिसके बारे में हम बात कर रहे हैं और काफी समय से काम करना चाहते हैं।

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

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

@joemcgill क्या आप इसे स्पष्ट कर सकते हैं:

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

"अधिक उपयुक्त" चौड़ाई क्या है? बस उस विशेष आइटम के मापदंडों को समझने की कोशिश कर रहा हूं क्योंकि मुझे यकीन नहीं है कि मैं अभी कर रहा हूं :)

आंतरिक आकार / रिक्त प्रश्न के लिए, यह अब प्रासंगिक है:

https://www.chromestatus.com/feature/4704436815396864
https://codepen.io/eeeps/pen/qLKwEZ

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

@yratof हाँ, सहमत हूँ कि यहाँ की प्रगति धीमी थी। हालाँकि, यहाँ (गुटेनबर्ग रेपो में) और स्लैक में काफी चर्चाओं के बाद, हमने फैसला किया है कि सीमांत सुधारों को जोड़ने का कोई मतलब नहीं है कि "कुछ हद तक" एक चीज या किसी अन्य को सुधारें। इसका दायरा कई बार घटा था।

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

बस यह कहने के लिए कि मुझे यह कितना पसंद आएगा .... वर्तमान में मेरा ब्लॉग होम पेज पर 350mb है ..... यह सिर्फ कमबख्त नट है

यह पूछने के लिए उपयुक्त धागा है कि क्या गुटेनबर्ग गैलरी ब्लॉक में एक छवि आकार चयनकर्ता जोड़ा जा सकता है ताकि छवियों को पूर्ण आकार के चित्रों के बजाय मध्यम आकार की छवियों को छोटा किया जा सके?

आज मैंने खुद को ऐसा करते हुए पाया:

// onDomReady
document.querySelectorAll('.wp-block-gallery.columns-2 figure img')
  .forEach(x => {
    x.setAttribute('sizes', '(max-width: 781px) 50vw, 344px');
  });

... जो $content_width और .columns-N साथ समरूपता कर सकता है। और एक प्लगइन रोल। मुझे आशा है कि यह उस पर नहीं आएगा :) ... और मैं इसे कोर में लैंड करने के बाद इसे निष्क्रिय करना याद रखूंगा।

संपादित करें: जावास्क्रिप्ट कोड एक बार काम किया, गलती से, मुझे लगता है। आपको कहीं न कहीं, आदर्श रूप से, Gutenberg markup और the_content फ़िल्टर के बीच, PHP स्तर पर sizes विशेषता इंजेक्षन करना होगा। ओह।

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

बस यह कहने के लिए कि मुझे यह कितना पसंद आएगा .... वर्तमान में मेरा ब्लॉग होम पेज पर 350mb है ..... यह सिर्फ कमबख्त नट है

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

FYI करें intrinsicsize अब एक बात है: https://github.com/WICG/intrinsicsize-attribute

/ update / image-block एक "प्रगति में काम" है :) कृपया परीक्षण करें।

• यदि बड़ा मौजूद नहीं है, तो हमेशा large छवि आकार, या full डालें।

कैसे के बारे में: हमेशा get_intermediate_image_sizes () से सभी छवि आकार विकल्प डालें; ?
कुछ छवियों के आकार तक पहुंच को रोकने के लिए अतिरिक्त मूल्य क्या है?

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

उपयोगकर्ता 500mb के बजाय सभी 5mb छवि आकार लोड कर रहे हैं।

मुझे भी यकीन नहीं है कि अगर मेरे लिए यह संभव है कि ब्लॉक को lazysizes जोड़ने के लिए फ़िल्टर किया जाए?

नमस्ते।
मैं Wordpress पर कोई विशेषज्ञ नहीं हूँ लेकिन मुझे लगा:
'कम से कम एक साधारण गैलरी सुविधा हाथ में है'।

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

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

ठीक है, मेरे लिए https://github.com/klihelp/Kli-Gutenberg-Gallery काम करता है। उसके लिए धन्यवाद !!

Gutenberg @ararename :( के बाद छवियों को संभालने के लिए एक प्लगइन जोड़ने की आवश्यकता नहीं होनी चाहिए

अच्छा, फिर यह धागा यहाँ क्यों है?
और यह गैलरी के लिए एक सेटिंग के बारे में है, न कि छवियों के बारे में।

Gutenberg @ararename :( के बाद छवियों को संभालने के लिए एक प्लगइन जोड़ने की आवश्यकता नहीं होनी चाहिए

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

यह विस्मयकारी है। मैं फटा हुआ ऐपर्ट कर रहा हूं, जबकि अपनी खुद की उत्तरदायी छवि / गैलरी / मीडिया-टेक्स्ट ब्लॉक बनाने के बीच चयन करने में सक्षम होने के बावजूद किसी भी देशी वर्डप्रेस ब्लॉक से भविष्य के अपडेट या फ़्लिपिंग नहीं हो पा रही है या असफल लोगों से चिपके रहने की उम्मीद है, जबकि ग्राहक 4k छवियों को डाउनलोड करेंगे। उनके मोबाइल पर या उनके 4k मॉनिटर पर 500px चित्र

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

नमस्ते! 👋

क्या इस पर प्रगति हो रही है? क्या इस टिकट से बातचीत दूर हो गई है?

अगर मैं इसे आगे बढ़ाने में मदद कर सकता हूं तो मैं साथ चलना चाहता हूं और इसमें शामिल होना चाहता हूं। 😄

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

क्या मैं एक साथ 'सरलतम गैलरी' प्लस 'फैंसीबॉक्स-फॉर-वर्डप्रेस' प्लगइन्स का उपयोग करना याद रखता हूं और प्रश्न में छवियों की छवि चौड़ाई (अंगूठे, जिसके लिए मैंने एक फंक्शंस में एक कस्टम इमेज साइज बनाया है) को 100 पर सेट करता हूं। % चौड़ाई और ऑटो की ऊँचाई (यह इनलाइन html चौड़ाई- / ऊँचाई-विशेषताएँ, यदि कोई हो) को मेरी ज़रूरतों को पूरा करता है। अगर यह पहले से ही आपकी मदद करता है तो मुझे बताएं। कम से कम मंगलवार तक दूर रहेगा, हालांकि।

कोई प्रगति?

क्या इस पर काम किया जा रहा है? या कहीं और नज़र रखी?

@mtias @azaozz - क्या छवियों का उपयोग करने वाले प्रत्येक ब्लॉक में छवि आकार चयनकर्ताओं को जोड़ना शुरू करना है? छवि आकार 5.0 या 5.1 के साथ पूरी तरह से संबोधित नहीं किया गया है और छवि ब्लॉक में पहले से ही एक चयनकर्ता है।

हो सकता है कि कवर ब्लॉक को अगला (# 19223) चयनकर्ता मिल सकता है?

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

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

@ararename> ठीक है, मेरे लिए https://github.com/klihelp/Kli-Gutenberg-Gallery काम करता है। उसके लिए धन्यवाद !!

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

मैंने वास्तव में प्लगइन स्थापित किया है और इसे प्रबंधित नहीं किया है

@ShareTextures
यह एक नया इंस्टॉलेशन था, मुझे याद नहीं है कि प्लगइन्स को इंस्टॉल करते समय एक ऑर्डर रखना महत्वपूर्ण था, लेकिन यह वही है जो मैंने इंस्टॉल किया है:

• Colorlib से वर्डप्रेस, संस्करण 3.2.2 के लिए फैंसीबॉक्स
• क्लीप - गुटेनबर्ग गैलरी, संस्करण 1.0.0, क्लिपोलिस से
• सरलतम गैलरी, संस्करण 4.4

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

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

सबसे पहले, अगर मुझे यह सही याद है, 'गैलरी एलिमेंट में' थंबनेल के रूप में चित्र '5.1 से कुछ अपग्रेड के बाद चले गए। * 5.2 से। *।

काम करने वाली गैलरी के लिए मुझे स्थापित करना पड़ा

• क्लीप-गुटेनबर्ग गैलरी
• सबसे सरल गैलरी
• वर्डप्रेस के लिए फैंसीबॉक्स

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

और कहीं ना कहीं मुझे भी करना था
.fancyboxforwp img {चौड़ाई: 100%! महत्वपूर्ण; ऊंचाई: ऑटो! महत्वपूर्ण;)

और मुझे उन पंक्तियों को लगाना था (वह हिस्सा जहाँ $ ("। फैंसीबॉक्स")। फैंसीबॉक्स को इनिशियलाइज़ किया गया है) 133 से 157 (लगभग) टिप्पणियों में ब्राउज़र में कुछ जेएस-त्रुटि नहीं है।

_ हाँ, यह बेहूदा लगता है ।_
लेकिन मैंने वापस जाँच की यह अभी भी काम करता है (सैम, बैकएंड नहीं, जैसा कि पहले ही कहा गया है)।
आशा है आप किसी तरह सफल होंगे, जयकार
खुलकर

एक और विचार:
मैंने अपने कार्यों में सेट किया है।
add_image_size ('थंबनेल', 152, 152, सच);
इसलिए मैंने स्पष्ट रूप से थंबनेल के लिए एक आकार निर्धारित किया था, शायद यह समग्र परिणाम को भी प्रभावित करता है।
और मैं Regenerate थंबनेल प्लग इन का उपयोग कई बार कर चुका हूँ, शायद यह समग्र परिणाम को भी प्रभावित करता है। बस बेतहाशा अनुमान लगा रहा है और जुड़े सामान की जाँच कर रहा है ...

@ararename तेजी से उत्तर के लिए धन्यवाद। मेरी वेबसाइट पर पहले से ही 500+ पोस्ट हैं। तो यह मेरे लिए काम नहीं करेगा :(
मैं Wordpress Gutenberg के अगले अद्यतन की प्रतीक्षा करूंगा।

@azaozz क्या इसके बारे में कोई अपडेट है? सभी मैं जानना चाहता हूं कि पूर्ण गैलरी के बजाय मेरी गैलरी में छवियों के थंबनेल लिंक का उपयोग कैसे करें।

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

उत्तरदायी कवर छवियाँ

उत्तरदायी कवर छवियों के लिए एक मार्ग प्रस्तावित करने के लिए, मैं यह समझने की कोशिश कर रहा हूं कि CSS छवि-सेट कैसे काम करता है https://developer.mozilla.org/en-US/docs/Web/CSS/image-set और कुछ परीक्षण करना ।

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

चित्र स्थित

छवि-सेट संपत्ति srcset विशेषता से बहुत अलग लगती है। छवि-सेट कई छवि आकारों की स्थापना का समर्थन नहीं करता है; यह एकाधिक छवि रिज़ॉल्यूशन (dpi / घनत्व) की स्थापना का समर्थन करता है। ऐसा लगता है कि वर्डप्रेस द्वारा स्वचालित रूप से उत्पन्न विभिन्न छवि आकार में 72DPI है।
छवि-सेट संपत्ति कुछ शर्तों के आधार पर ब्राउज़र को सबसे अच्छी छवि डाउनलोड करती है। शर्तों के कुछ उदाहरण हैं:

• स्क्रीन प्रति इंच पिक्सेल।
• जब कनेक्शन बहुत धीमा हो, तो निम्न डीपीआई छवि डाउनलोड करना चुनें।
• प्रिंटर पर कुछ भेजते समय एक बेहतर छवि डाउनलोड करें।

व्यूपोर्ट का आकार प्रभावित नहीं करता है कि छवि-सेट द्वारा किस छवि को चुना गया है।

Src- सेट और आकार

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

वर्डप्रेस निम्नलिखित आकारों की विशेषता का उपयोग करता है "(अधिकतम-चौड़ाई: $ चौड़ाई px) 100vw, $ चौड़ाई px" जहां $ चौड़ाई छवि फ़ाइल की चौड़ाई है, इसका मतलब है कि अगर व्यूपोर्ट $ चौड़ाई से छोटा है तो छवि आकार के रूप में व्यूपोर्ट आकार का उपयोग करें व्यूपोर्ट $ चौड़ाई से बड़ा है, छवि चौड़ाई के रूप में $ चौड़ाई का उपयोग करता है।

वर्डप्रेस srcset और size के पेयर जोड़े यह सुनिश्चित करते हैं कि स्क्रीन पर जिसकी चौड़ाई x की मात्रा है, हम ऐसे चित्र नहीं डाउनलोड करते हैं जिनकी चौड़ाई x से अधिक हो।

आगे का रास्ता

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

छवि-सेट इस व्यवहार की अनुमति नहीं देता है; यदि डिवाइस का पिक्सेल घनत्व हाईट (जैसे, रेटिना डिस्प्ले) है और स्क्रीन के पिक्सेल घनत्व छोटा है, तो कम डीपीआई वाली छवि है, तो यह उच्च डीपीआई के साथ एक छवि को डाउनलोड करने में सक्षम बनाता है।

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

छवि-सेट उपयोग के लिए एक और चुनौती यह है कि लगता है कि हम वर्डप्रेस पर उत्पन्न सभी छवि फ़ाइलों में डीपीआई की समान मात्रा है।

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

अगर मुझे कुछ याद आया है, या आपके पास अतिरिक्त जानकारी है जो उपयोगी हो सकती है, तो कृपया एक टिप्पणी छोड़ दें।

महान विचार, @ जोर्जफिलिपोस्टा। मैंने अभी-अभी # 19909 बनाया है, जिसका उद्देश्य यह पता लगाना है कि कोई भी ब्लॉक उत्तरदायी संपादन कैसे प्राप्त कर सकता है। क्या आपके पास यह देखने के लिए एक नज़र हो सकता है कि क्या उत्तरदायी कवर छवियों का आपका विचार उस इंटरफ़ेस का लाभ उठा सकता है?

अगर FLIF या JPEG-XR पर्याप्त रूप से पहले से ही पर्याप्त रूप से समर्थित हो सकते हैं ... EG
कुछ छोरों का उपयोग करके सामान्य मीडिया प्रश्नों के साथ छवि-सेट को जोड़ना संभव है,
यह बड़ी मात्रा में सीएसएस का परिणाम होगा। निश्चित रूप से, gzip शायद इसे स्क्विश करेगा, लेकिन यह डेवलपर टूल में ढेर सारे ओवरराइड मीडिया प्रश्नों की तरह जटिलता भी है।
अभी के लिए मैं srcset और sizes साथ एक <img उपयोग करता हूं और इसे सामग्री के पीछे बिल्कुल स्थान देता हूं।
इस दृष्टिकोण का उपयोग करके मुझे hidpi / रेटिना भाग को संभालना नहीं है और बस आकारों के लिए कुछ नियम प्रदान करना है। - लेकिन इसे अलग से स्टाइलशीट में एडजस्ट करना होगा।

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

क्या इसके लिए पहले से कोई अपडेट है?
मैंने अभी-अभी अपनी साइट पर एक गैलरी जोड़ी है और अब मेरे पृष्ठ का आकार 25 एमबी है क्योंकि गैलरी थंबनेल नहीं बल्कि पूर्ण चित्रों को लोड करती है।

नमस्कार @azaozz और अन्य।
क्या हम इस समस्या के लिए स्थिति अद्यतन प्राप्त कर सकते हैं?

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

धन्यवाद।

क्या पित्त की समस्या को ठीक करने का कोई तरीका है? मेरा मतलब मीडिया फाइल से लिंक करना है? वर्तमान में मेरी कुछ छवियों में पूर्ण चौड़ाई के लिए मान्य लिंक हैं, लेकिन उनमें से अधिकांश बड़े प्रारूप (1024x) से जुड़ रहे हैं।

अरे @ CNK001

देखें कि क्या आप संबंधित समस्या का पता लगाने में सक्षम हैं। मैंने मीडिया लेबल मुद्दों की खोज की: https://github.com/WordPress/gutenberg/labels/%5BFeature%5D%20Media
यदि आपका पता लगाने में सक्षम नहीं है तो एक नया मुद्दा खोलें।

मुझे अभी और अधिक उन्नत छवि संचालन की आवश्यकता वाले उपयोगकर्ता के लिए एक समर्थन अनुरोध था।

पिछले Wordpress Autoupdates में से एक के बाद मेरा समाधान नाली की तरह नीचे चला गया ...
बैकेंड और फ्रंटेंड ने जमकर गड़बड़ की। मुझे नए सिरे से शुरुआत करनी होगी।

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

हे @ यारनेमे

आंतरिक ब्लॉकों का उपयोग करने के लिए गैलरी को फिर से काम किया जा रहा है। अधिक जानकारी के लिए इस पुल अनुरोध को देखें।
https://github.com/WordPress/gutenberg/pull/25940

@paaljoachim त्वरित उत्तर के लिए धन्यवाद! चला गया चेक :-)

@ararename आप इस बीच PhotoPress प्लग-इन का उपयोग कर सकते हैं। इसमें एक कोर गैलरी ट्रांसफॉर्मेशन है।

एक और विकल्प के लिए @padams धन्यवाद। मुझे लगा कि मैं आज इसे प्राप्त करूंगा लेकिन मुझे इस विषय पर लौटने में कुछ दिन लगेंगे। वापस रिपोर्ट करेगा कि यह कैसे गया।