Gutenberg: إضافة بلوك: القسم

أنا بالفعل أعجبتني هذه الفكرة! أنا أيضا أحب الحقيقة أن لديها إعداد الخلفية لها.

لطيف! ماذا لو سمحت الكتلة بالإعدادات "المتقدمة" الثلاثة التالية:

• حدد اسم فئة ليتم إجراء تسلسل له على الأطفال .child_class, .child_class_1
• أضف فئة فرعية أولى اختيارية .child_class, .child_class_1, .child_class_first
• أضف فئة فرعية اختيارية أخيرة .child_class, .child_class_n, .child_class_last

محددات :nth-child قد تكون قادرة على تعويض الأخيرين ، لكنني أعتقد أن إضافة فصل دراسي لجميع الأطفال قد يكون مفيدًا في سياقات معينة.

أحب هذه الفكرة. إذا كان من الممكن تغيير ألوان الخلفية والنص ، فقد يكون من المنطقي إضافة ألوان الارتباط أيضًا.

فكرة ممتازة. سيضيف هذا حرفيًا قيمة كبيرة إلى محرر جوتنبرج.

أفضل بكثير من مجرد كتلة الأعمدة ، التي بها الكثير من المشكلات. رائع!

هذا هو أول شيء شرعت في إنشائه عندما رأيت أن التعشيش كان متاحًا. روايتي متشابهة إلا أنني تخيلت أنك ستضيف كتلة الأعمدة إليها.

هل لديك رمز متاح لهذا؟

إذا كانت هذه الكتلة تحتوي على "أعمدة" ، يجب علينا فقط تحديث كتلة "الأعمدة". ولكن لا يزال من الممكن استخدام كتلة أعمدة داخل كتلة قسم والحفاظ على كتلة القسم بدون أعمدة.

طالما لا يمكنك وضع كتل أعمدة داخل كتل أعمدة 😉

يتم تقسيم الكثير من صفحات الموقع إلى أقسام بها محتوى مختلط مع صفوف متعددة من الأعمدة وغالبًا ما تكون الأعمدة متداخلة داخل أقسام أكبر. هذا مثال سريع:

كتلة المقطع التي تعمل فقط مثل غلاف مكشوف أعتقد أنها ستكون الأكثر مرونة. (مثل القدرة على تداخل كتل الأعمدة!)

لقد بدأنا مشروع موقع جديد هذا الأسبوع. عادةً ما يتم تصميمه باستخدام تخطيطات محتوى مرنة للحقول المخصصة المتقدمة ، لكنني سأرى إلى أي مدى يمكننا الوصول إلى استخدام Gutenberg وحده.

نعم ، أعتقد أن الأقسام متعددة الأعمدة مثل مثالjvisick أعلاه ليست غير شائعة. ستكون الحاوية ذات خيارات الخلفية / النص التي تتداخل مع الكتل هي الطريقة الأكثر مرونة. نظرًا لأن لدينا الآن كتلة عمود عاملة ، يمكننا حتى التفكير في إخراج خيار العمود من هذا.

سيكون رائعًا إذا كان هناك حاوية داخلية (div) في هذه الكتلة التي تحتوي بعد ذلك على جميع الكتل الفرعية. يمكن بعد ذلك تصميم هذه الحاوية باستخدام max-width و margin-left / right: auto لتوسيط الكتل الفرعية ولها خلفية كاملة العرض.

يعد وجود قسم كامل العرض مع المحتوى المضمن في تخطيط أضيق نمط تصميم شائعًا. أتساءل عما إذا كان من الأفضل التحكم فيها بواسطة الكتل المتداخلة بدلاً من خبزها في كتلة القسم الأصل؟

أعتقد أن كتلة القسم ستكون مفيدة جدًا ... حسنًا ، الأقسام الموجودة في الصفحة ، وأنا أوافق على أن الأعمدة يجب أن تكون كتلة منفصلة (مثل الكتلة الموجودة الآن) والتي يمكن دمجها في كتلة قسم. أعتقد أن هذا شيء ، جنبًا إلى جنب مع كتلة الأعمدة ، يجب تضمينه في إصدار Gutenberg الذي تم دمجه في WordPress 5.0. إذا نظرت إلى الإضافات الموجودة في أداة إنشاء الصفحات ، فسيتم استخدام الأقسام كثيرًا ، وكذلك الأعمدة (من الواضح) ، لذا فإن تضمينها في الإصدار الأساسي الأولي أمر ضروري في رأيي.

(أعتقد أيضًا أنه من المهم أن تحصل كتلة الأعمدة على ميزات مثل الأعمدة ذات العرض المتغير والأعمدة المتجاوبة ، سواء من أجل التجربة الأساسية بالإضافة إلى تسهيل قيام منشئي الصفحات الحاليين بإعادة تأسيس أنفسهم خارج Gutenberg ، ولكن هذة مشكلة منفصلة.)

بعد التفكير في الأمر أكثر ، أعتقد أنه سيكون من المنطقي أن تكون كتلة القسم والأعمدة هي نفسها. فقط أضف القدرة على أن يكون لديك عمود واحد فقط في كتلة الأعمدة بدلاً من اثنين على الأقل. ثم أضف إعدادات الخلفية لكتلة القسم المقترحة إلى كتلة الأعمدة.

أعتقد أن وجود كتلة قسم / أعمدة واحدة سيقلل من مقدار التداخل الذي يتعين عليك القيام به. في الوقت الحالي ، لا تعد كتلة القسم المقترحة أكثر من مساحة بها خيارات عرض وخلفية. يمكن إضافة كلاهما إلى كتلة الأعمدة ، وإذا سمحت كتلة الأعمدة بوجود عمود واحد فقط ، فلن تكون هناك حاجة لكتلة القسم.

بالإضافة إلى ذلك ، إذا كنت تريد قسمًا كامل العرض بمحتوى عرض قياسي ، فيمكن تحقيق ذلك إما عن طريق دمج كتلة قسم / أعمدة أخرى في قسم آخر تم تعيينه على العرض الكامل. يمكن أن يتم ذلك من خلال إعداد في المفتش لتغيير عرض محتوى الكتلة بشكل مستقل عن عرض الكتلة بأكملها ؛ يمكن أيضًا إضافة هذا كمقابض مرئية لتغيير الحجم ، على غرار طريقة عمل صفوف / أعمدة Beaver Builder ، أو كيفية عمل كتلة الصورة في Gutenberg.

بالنسبة لما يمكن أن تسميه هذه الكتلة المدمجة ، أعتقد أن الاحتفاظ بالاسم "الأعمدة" يعمل فقط ، لأن هذه هي الوظيفة الأكثر وضوحًا التي يبحث عنها الأشخاص. لا ينبغي أن يكون من الصعب العثور على إعدادات الخلفية في المفتش (وأتصور أنه سيكون المكان الذي سيبحث فيه بعض الأشخاص في المقام الأول على أي حال إذا كانت هناك كتلة قسم منفصلة ولم يكونوا على علم بها) ، واستخدام الأعمدة لا ينبغي أن يكون من الصعب اكتشاف الكتلة كحاوية ذات عمود واحد لأن شريط التمرير لتغيير عدد الأعمدة يجب أن يوضح كيفية القيام بذلك ... فقط اسحبه إلى اليسار.

لقد غيرت رأيي بشأن دمج كتلتَي الأقسام والأعمدة. من أجل الحصول على أكبر قدر من المرونة مع الأعمدة ، سيكون من المنطقي أن يكون كل عمود كتلة خاصة به: كتلة العمود. سيسمح ذلك بالتحكم بسهولة في إعدادات عمود فردي ، بالإضافة إلى سحب عمود من صف إلى آخر. بالطبع ، نظرًا لأن الأعمدة تنتقل من اليسار إلى اليمين (وتلتف في معظم أنظمة التخطيط) ، فستحتاج إلى أن تكون الكتلة الأصلية هي تلك التي أدرجت المحتوى في هذا الاتجاه الأفقي ولها التفاف (بدلاً من الاتجاه الرأسي القياسي) وهذا من المحتمل أن تسمح الكتلة الأصلية فقط بإدراج كتل العمود فيها. ستكون هذه الكتلة صفًا. ستحل هاتان الكتلتان محل كتلة الأعمدة. لكنها لا تغطي الموقف الذي تريد أن تكون فيه صفوف متعددة (غالبًا بأعداد مختلفة من الأعمدة بداخلها) في نفس الخلفية / الحاوية ، وهو ما ستفعله كتلة القسم. بالطبع ، لن تكون كتلة القسم أكثر من حاوية بها خيارات الخلفية والحشو والعرض ، ويمكن إدراج أي كتلة فيها. وللحصول على تخطيطات أكثر تعقيدًا ، يمكن إدراج كتل القسم في كتل العمود.

انظر # 6461.

أعتقد في الواقع أن الحد الأدنى من فكرة العمود 1 ليس حلاً سيئًا. في الواقع ، إذا استخدمت المفتش الخاص بك لتغيير سمة "min" في شريط التمرير إلى 1 ، واخترت واحدة ، فستعمل إلى حد كبير كما تتوقع.

ومع ذلك ، فإن كتلة المقطع المعنوية أكثر منطقية على أي حال. يمكن تحقيق المحتوى الداخلي (على سبيل المثال ، قسم أقصى عرض داخل مقطع كامل مع قسم) من خلال تداخل قسمين - عرض محتوى داخل عرض كامل.

فكرة لون الخلفية جيدة ، ولكن ... ربما تكون فكرة محددة قليلاً. أعتقد أن النهج الأكثر عمومية سيكون مجرد استخدام الفئات المخصصة في القسم. يمكن لـ CSS للواجهة الأمامية التقاط ذلك وأي أطفال بشكل مباشر.

بعد بعض المناقشة في # 6461 ، قررت أن فكرة كتلة الصف + كتلة العمود ليست هي الطريقة الصحيحة للذهاب. من المحتمل أن تكون كتلة Layout المشابهة لتلك الموجودة في # 5351 (تعليق) أقل إرباكًا بكثير وأكثر مرونة بكثير. مهما كان الأمر ، يجب أن يكون هناك مقطع قسم بالتأكيد ، وأعتقد أنه يجب بالتأكيد إضافته قبل إصدار WordPress 5.0.

بالنسبة لخيارات ألوان الخلفية ، أعتقد أنه من المنطقي تمامًا أن يكون لديك خيارات خلفية في القسم. فقط وجود خيارات للفصل يبدو مقيدًا بعض الشيء. غالبًا ما يكون الهدف الكامل من التداخل في كتلة القسم هو مشاركة أشياء متعددة في الخلفية. بالإضافة إلى ذلك ، أفضل ما إذا تم تنفيذ خيارات الخلفية الأخرى مثل صور الخلفية وخلفيات التدرج ، حيث تكون هذه الخيارات مطلوبة غالبًا بدلاً من الخلفيات ذات الألوان الصلبة. تسمح كتل الأقسام المتداخلة حتى بتطبيق ألوان الخلفية على كتلة واحدة ، مما يعني أن خيارات لون الخلفية في كتلة الفقرة قد لا تكون ضرورية بعد الآن.

بالنسبة لتداخل كتل الأقسام بدلاً من وجود إعدادين منفصلين للعرض ، أعتقد أن ذلك قد ينجح. أكبر ما يقلقني هو مقدار الحشو الإضافي الذي سيتم إضافته عن طريق تداخل كتل الأقسام ، مما يؤدي إلى خيارات الحشو.

أعتقد أنه من الضروري أن يكون لكتلة القسم القدرة على تخصيص مقدار الحشو الذي تستخدمه ، أو على الأقل إزالة الحشو الافتراضي. بالطبع ، هذا يثير تساؤلات حول كيفية تحديد كتلة القسم عندما يتم تضمين كتلة أخرى فيه. أعتقد أنه سيتم حل هذه المشكلة من خلال تحسينات مثل # 6471 والأشياء التي يتم العمل عليها في الفرع try/alternate-hover-approach .

: +1:

نحتاج حقًا إلى كتلة صف / حاوية عامة ، خاصةً مع إعدادات العرض.

من الناحية المثالية ، أعتقد أن الإعدادات الأخرى مثل "لون الخلفية" و "لون النص" يجب أن تعيش ضمن علامة تبويب إعدادات "إضافية" في كل كتلة (بالإضافة إلى العديد من إعدادات CSS الأخرى القابلة للتطبيق بشكل عام).

فيما يتعلق بالاستجابة ، أعتقد أنه يجب علينا " .

المشكلة مع لون الخلفية ولون النص هي ببساطة: أين تنتهي؟ بالفعل في هذا الموضوع وحده لديك شخص ما يقترح لون الارتباط. لماذا لا لون الحدود وسمكها ونمطها؟ لنكون صادقين ، فإن الحشو والهامش منطقيان. ماذا عن الظل المسقط وصور الخلفية وخيارات تحديد الموضع وأوضاع العرض؟ نمط الخط وحجمه ، وارتفاع الخط وأدنى ارتفاع؟ هناك المئات من خصائص CSS وتختلف تلك التي تحتاجها وفقًا لتصميمك.

يجب أن تكون إما فئة ، والتي يمكنك استخدامها بعد ذلك لتصميم أي شيء بما في ذلك العناصر الفرعية ، أو قائمة قابلة للتصفية من خصائص CSS بحيث يمكن لـ div السمة ربطها وإضافة العناصر التي يريدها.

tmdesigned وتنتهي عند تحكم WYSYWIG كامل الميزات وبديهية في نمط وتنسيق وتخطيط صفحة الويب. أليس هذا هو هدف جوتنبرج؟

تقدم Gutenberg للعالم محتوى ويب جديدًا ومخططًا جيدًا ومتطورًا وقابلًا للنموذج وقابل للتمديد WYSYWIG ... يجب أن نكتشف مدى رغبتنا في الاستفادة من ذلك الآن وإلا سنفتقد القارب.

الفكرة في النهاية هي تقليل حجم العمل الذي نقوم به الآن ، سواء أكان كتابة CSS ، أو كتابة تجاوزات CSS ، أو القيام بمهام محتوى متكررة.

لا يمكن أو يجب تعريف كل شيء بالفئات ، خاصةً إذا كانت فئات مستهدفة بشكل سيئ أو سمات لا يمكن تجاوزها.

خذ إعدادًا رقميًا يحدده المستخدم على سبيل المثال. سيكون من الصعب تحديد فئة لكل قيمة وقد يغري مطور الكتلة فقط بحقن القيمة مباشرة في السمة style .

إذا كانت موجودة ككتلة ويمكن أن يكون لها أنماط CSS محددة من قبل المستخدم مطبقة عليها ، فيجب أن تكون هناك وسيلة موحدة وموحدة للقيام بذلك ، حتى لو كانت عبارة عن لوحة من مربعات نص زوج المفتاح / القيمة.

إذا كنت ترغب في ذلك ، يمكنك قراءة الطريقة التي اقترحتها للقيام بذلك بطريقة تعالج مخاوفك.

لقد قرأت اقتراحك الخاص بواجهة برمجة التطبيقات (API) وهو ليس بعيدًا عما كنت أقوله حول ربط مضاف للسماح بإضافة أزواج القيمة الرئيسية.

ومع ذلك أعتقد أن وجهة نظري الأصلية لا تزال صالحة. كما قلت ، هناك المئات من العقارات وبينما بعضها أكثر شيوعًا ، فإن هذه القائمة ستنمو بسرعة. يمكننا السير في هذا الطريق ، ومحاولة إيجاد "حل وسط جيد" مثل ميزات TinyMCE التي تم تضمينها مقابل إزالتها في Classic. ولكن هناك الكثير من الخصائص قيد التشغيل هنا ، لذا سيكون ذلك تحديًا.

ولكن الأهم من ذلك ، أن فكرة إضافة تصميم مباشر على مستوى الكتلة تتفكك عند التصغير قليلاً ولا تفكر فقط في كتلة واحدة. عندما يكون لديك العديد من الكتل المتشابهة ، في صفحة واحدة أو عبر الصفحات ، فلن ترغب في إعادة إدخال كل هذه القيم. سترغب في فكرة تجريدية ... مثل فئة CSS.

السماح - أو التشجيع - بتصميم على مستوى الكتلة الفردية ليس مثاليًا لأنه غير قابل لإعادة الاستخدام. أنت محق في القول إنه لا يجب تجريد كل شيء في الفصل ، ولكن تم تطوير CSS لسبب ما ولا ينبغي إلقاؤه في الريح بهذه السرعة.

tmdesigned أنا أقدر ملاحظاتك. أعتقد أنني أتفهم الالتباس لذا سأحاول التوضيح.

الهدف ليس التخلص من عدد فئات CSS أو حتى تقليلها.

الهدف ، على وجه التحديد ، هو توحيد إعدادات تصميم الكتلة المعرفة من قبل المستخدم في واجهة مستخدم واحدة أو على الأقل واجهة برمجة تطبيقات واحدة.

سيظل مطورو الويب ، ومطورو الكتل ، ومطورو السمات يكتبون كود CSS إلى كتل النمط ، وستظل الكتل تحتوي على فئات وسمات ومعرفات حتى يتمكن المطورون من تصميمها.

سيكون لديهم نفس الفصول الدراسية التي لديهم الآن بالضبط وسيكون لديهم نفس التصميم الذي لديهم الآن.

لكن

في اللحظة التي يدرك فيها مطور الكتلة أن لديهم خاصية (خصائص) CSS التي يمكن / ينبغي تكوينها بواسطة المستخدم ... وذلك عندما يتولى Gutenberg المسؤولية ويقرر كيفية حقن هذه الأنماط (والتحكم فيها بشكل محتمل).

سينتج عن ذلك واجهة مشتركة واحدة (لكل من المطورين والمستخدمين) عندما يتعلق الأمر بالتحكم غير المبرمج في التكوينات الشائعة القائمة على النمط لمحتوى صفحة الويب.

يمنح هذا كل من المستخدمين والمطورين وسيلة واحدة متسقة لعرض وإضافة وإزالة وتعديل وتجاوز أنماط الحظر والتي ، في نهاية اليوم ، تتلخص جميعها في خصائص CSS البسيطة.

آسف للتسبب في الكثير من الضوضاء على هذا الموضوع. ربما ينبغي لنا أن ننتقل إلى مزيد من المناقشة إلى القضية ذات الصلة.

تحرير مذكرة:

لقد نسيت أن أتطرق إلى النقطة المتعلقة بالتجريد.

الدقيقة التي يحتاجها المستخدم لتطبيق نفس النمط بالضبط على نفس الكتلة مرتين هي اللحظة التي يجب فيها التخلي عن إعدادات النمط المحددة من قبل المستخدم لفئات CSS (لتلك الكتلة).

بعبارة أخرى ، توفر إعدادات النمط المحددة من قبل المستخدم آلية متسقة للمستخدم لتخصيص الكتل حسب رغبته ، سواء كان ذلك شيئًا فريدًا لمرة واحدة (كما ينبغي أن يكون) أو 100 مرة في كل صفحة ، وكيف تختار الهيكل لا يزال الأمر متروكًا لك تمامًا.

أعتقد أننا نتفق في الغالب. اقتراحي في المنشور الأول هو أن يكون لديك رابط لإضافة / إزالة عناصر التحكم. أنا لست ضد تخصيص المستخدم للأنماط على مستوى الكتلة ، من الصعب فقط اختيار "الأنماط التي تستحق الحصول عليها افتراضيًا في كتلة قسم عام" دون زيادة القائمة بشكل كبير. لا بأس من امتلاك القليل منها ، خاصة إذا كان يسمح بإضافة عناصر تحكم أخرى. على أي حال ، أنا مندهش من أن الهامش والحشو لن يكون مفيدًا بشكل عام أكثر من لون الخلفية لكتلة القسم.

FWIW ، تعجبني فكرتك في أن تكون الفئات المولدة هي المخرجات ، بحيث تظل قابلة للتجاوز دون الحاجة إلى استخدام!

tmdesignedrchipka وأنا أعلم أن هذا منذ أكثر من أسبوعين، ولكن هل تكون مهتمة في تجزئة بعض أكثر من تلك التفاصيل في قضية أخرى؟ أعتقد أنه سيكون من المفيد أن يكون لدينا المزيد من الأنظار على هذه القافلة.

ألقوا نظرة أخرى على هذه المجموعة بناءً على المحادثات السابقة.

أسهل طريقة لمشاركة أفكاري هي من خلال نموذج أولي: https://wp.invisionapp.com/share/PQJPPAX4JZW

بعض الملاحظات:

• بناءً على استطلاع سريع: https://wordpress.slack.com/archives/C02QB2JS7/p1527283199000343 لقد غيرت الاسم من _Section_ إلى _Container_.
• لقد أزلت إعدادات العمود ، نظرًا لأنه من المعقول أن يرغب الأشخاص في دمج تخطيطات الأعمدة ومطابقتها داخل قسم معين ، كما هو موضح فيjvisick.
• بالإضافة إلى لون الخلفية ، أضفت دعمًا لصورة الخلفية. تستند الإعدادات إلى ميزة صورة الخلفية الموجودة في Core.
• هل يجب أن ندع الناس يعششون كتلة حاوية في كتلة حاوية؟

melchoyce تبدو رائعة!

إحدى الميزات الرائعة التي أود رؤيتها هي التحديد في المفتش لتبديل عنصر HTML للكتلة بين <aside> ، <div> ، و <section> .

يجب بالتأكيد السماح بالقدرة على تداخل الحاويات ، في رأيي. لن يكون مفيدًا فقط في سياق وجود مناطق ملونة مختلفة داخل قسم دلالي واحد باستخدام اقتراح عنصر HTML المقترح أعلاه ، ولكنه سيكون مفيدًا أيضًا في المواقف التي تريد فيها إعطاء خلفية لكتلة واحدة عندما لا تحتوي على خيار لون الخلفية نفسه.

ميزة أخرى لطيفة هي الخلفيات المتدرجة ، حيث يبدو أنها تحظى بشعبية كبيرة في بعض التصميمات.

melchoyce +1

إن قدرةSuperGeniusZeb على تغيير عنصر HTML كانت في

jvisick نعم ، هذا ما كنت أفكر فيه. يحتوي كل من Beaver Builder و Elementor على إعدادات مثل تلك الخاصة بالصفوف / الأقسام.

melchoyce أعتقد أن الحاويات يجب أن تكون

لا يوجد سبب لإضافة قيود متداخلة إلى كتلة حاوية عامة.

أنا أفهم قيمة عناصر HTML الدلالية ، لكنني أتساءل أيضًا عما إذا كانت هناك طريقة لتفويض هذه الوظيفة للمكونات الإضافية بطريقة ما بحيث تكون متاحة كخيار للمستخدمين المتقدمين ، لكن المستخدمين العاديين لا يحتاجون إلى التفكير في الأمر. نظرًا لأنه في اللحظة التي تضيف فيها ذلك ، فأنت لا تتحمل فقط مسؤولية توفير الوظيفة ، ولكن أيضًا مسؤولية تثقيف المستخدمين بشأن الآثار الدلالية ... التي غالبًا ما تكون ظرفية للغاية.

chriskmnds نقطة جيدة. أعتقد أن هذا هو المكان الخطأ لوضع علامات الحاوية.

يجب أن تعمل كتلة الحاوية كحاوية عامة بدون معنى دلالي.

يجب توفير المعنى الدلالي من خلال وظيفة قالب القوالب (المستقبلية) ، بحيث يكون المحتوى <aside> جزءًا من القالب و <section> جزء آخر.

بهذه الطريقة ، يمكن للمستخدمين تنظيم المحتوى في حاويات كيفما يريدون (على أي مستوى عمق) ، دون التأثير على المعنى الدلالي.

أوافق على أن القدرة على تبديل عنصر HTML تبدو متقدمة بعض الشيء بالنسبة لمعظم الأشخاص ، وربما لا تنتمي إلى إعداد Gutenberg الأساسي.

يجب توفير المعنى الدلالي من خلال وظيفة قالب القوالب (المستقبلية) ، بحيث يكون محتوى <aside> جزءًا من القالب و <section> جزء آخر.

سيكون هذا بالتأكيد جيد للاستكشاف.

لا أوافق على النقاط التي تم وضعها لإبقاء UX الأساسي بسيطًا ولكني سأطلب بعد ذلك أين ستضيف <section> ، <nav> ، <header> ، إلخ .. عناصر التغليف؟ تبدو كتلة الحاوية العامة ، والتي هي أساسًا عنصر غلاف ، كخيار طبيعي. قد يكون ذلك أفضل من كتلة مكررة لكل من هذه الحالات. يمكن أن يكون الإعداد الافتراضي هو <div> ولا يضطر المستخدم مطلقًا إلى لمس الإعداد إلا إذا لزم الأمر.

ماذا لو عملت خيارات عناصر HTML بشكل مشابه للإعدادات المحاذاة / الكاملة حيث يمكن تعيين مجموعة من العناصر المدعومة من القالب أو المكون الإضافي؟

jvisick من الناحية المثالية ، سيتم إنشاء عناصر الالتفاف هذه باستخدام "قالب تخطيط الكتلة" للصفحة /

باستخدام قالب تخطيط الكتلة ، يمكنك إعداد مجموعة من كتل الحاوية الافتراضية وتوفير إعداد (في الكود) لما يجب أن يكون عليه اسم العلامة التي تم إنشاؤها لكتلة الحاوية.

rchipka أرى من أين أتيت في استخدام قوالب التخطيط التي تمنح المستخدمين مناطق محددة مسبقًا لإدارة المحتوى. إنني أنظر إلى هذا أكثر من منظور استخدام Gutenberg كمنشئ صفحات للصفحات التي لم يتم تعريفها والتي سيكون من المفيد فيها تحديد نوع عنصر HTML المستخدم من المحرر. أعتقد أن كلا السيناريوهين مهمان.

ومع ذلك ، أتفق مع melchoyce على أن تعيين عناصر HTML ليس ضروريًا للتشغيل الأولي لكتلة الحاوية ، لكنني أعتقد أنه شيء يستحق الاستكشاف في مرحلة "منشئ الصفحة" التالية.

الأقسام هي في الأساس عمود واحد .. حسنًا ، أعمدة.

ألاحظ أن كتلة الأعمدة 3.0.0 (بيتا) لا تسمح بعمود واحد على شريط التمرير الخاص بها.

لست متأكدًا مما إذا كان من الأفضل التمسك بكتلة العمود فقط في كل مكان والجمع بين هذه التطبيقات. ما هو الجانب السلبي؟

الشيء الوحيد الذي سيكون من الجيد إضافته هو التبديل بين ما إذا كان يجب أن تكون الحاوية (القسم) كاملة العرض أو مضمنة. إذا تم احتوائه ، فيجب أن يحترم content_width المعين في السمة (# 5650) ، وإلا يجب أن يكون العرض كاملًا. أعتقد أن غالبية منشئي الصفحات لديهم هذه الميزة.

نعم ، هذا مضمن في شريط الأدوات السريع في آخر نموذج بالحجم الطبيعي.

melchoyce ضع في اعتبارك أنه ستكون هناك مواقف يجب أن تكون فيها كتلة القسم / الحاوية نفسها كاملة العرض ، ولكن لا ينبغي أن يكون المحتوى داخل كتلة القسم / الحاوية. كيف سيتم التعامل مع هذا؟

لقد أدركت بشكل افتراضي أن الحاوية نفسها يمكن أن تصبح كاملة العرض ، ولكن أي محتوى بداخلها لا يدعم العرض الكامل أصلاً (مثل الصور / كتل الغلاف) سيظل مقيدًا بعرض المحرر.

melchoyce بافتراض أنني

نعم ، هذا ما أفكر فيه!

لست متأكدًا مما إذا كان قد تمت مناقشته ، ولكن يمكن أن يكون القسم عنصر 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 المستخدمة فكرة جيدة. تبدو أسهل طريقة لدمج عناصر HTML الدلالية مثل <aside> و <section> بدون إنشاء مجموعة كاملة من الكتل المتشابهة بشكل مفرط.

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 );

لماذا تمت إزالة هذا من معلم WordPress 5.0 ،mtias؟ يبدو هذا كشيء من المحتمل أن يدخل في الإصدار الأولي ، وذلك ببساطة بسبب مدى فائدته وبساطته. لا تحتوي الكثير من الكتل على إعدادات خلفية لأنه كان من المفترض أنك ستستخدم كتلة الحاوية لذلك. ليس من الصعب حتى تنفيذ هذه الكتلة ، أليس كذلك؟ لا أفهم سبب وجوب إعادة هذا إلى إصدار ما بعد WordPress 5.0.

في ملاحظة أخرى ، كنت أتفقد مؤخرًا Oxygen وقد أعجبت بنظام التخطيط القائم على flexbox. ماذا لو نفذت مجموعة الحاوية بعض هذه الميزات؟ أراهن أنه يمكن أن يكون قويًا حقًا ويوفر طريقة بديلة للحصول على تخطيطات أخرى غير كتلة الأعمدة ... ربما يمكن أن تجعل كتلة الأعمدة غير ضرورية؟

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

أوصي بشدة بفحص هذا. في الواقع ، أوصي فقط بإلقاء نظرة فاحصة على الأكسجين بالكامل. إنه مختلف تمامًا عن جميع المكونات الإضافية الأخرى الخاصة ببناء الصفحات ، وأعتقد أن هناك الكثير من الأفكار الجيدة التي يمكن أن يستخدمها Gutenberg.

أوافق بالتأكيد ، يجب أن يكون هذا في الإصدار 5.0 ، فأنت بحاجة إلى حاوية لتجنب أي حلول اختراق باستخدام كتلة الأعمدة.

أعتقد أيضًا أن هذه الكتلة يجب أن تكون متاحة قريبًا وليس لاحقًا. تنتظر العديد من وكالات تطوير WordPress هذه الكتلة قبل البناء باستخدام Gutenberg.

@ dingo-d و ericvalois نعم ، لقد امتنعت عن استخدام Gutenberg لأي شيء غير

لتوضيح ما قلته سابقًا حول تبني كتلة الحاوية لأشياء يقوم بها الأكسجين ، أعتقد أن كتلة الحاوية يمكن أن يكون لها خيار لتغيير اتجاه تدفق الكتل المتداخلة من الوضع الرأسي الافتراضي إلى الأفقي. يمكن أن تكون هناك أيضًا خيارات محاذاة رأسية وأفقية مثل تلك الموجودة في Oxygen. ستكون هذه قوية حقًا - خاصةً إذا تم دمجها مع القدرة على تغيير هذه الخيارات بشكل متجاوب كما تسمح به معظم المكونات الإضافية لمنشئ الصفحات.

بالطبع ، هناك مشكلة ملحوظة تتمثل في أن كتلة الحاوية التي تستخدم المحاذاة / التخطيط المستندة إلى Flexbox لن تسمح بتداخل الكتل المحاذية للعوامة مباشرة فيها. لكنني أعتقد أن هناك حلًا بسيطًا لذلك: أضف القدرة على استخدام حاوية إما تخطيط CSS قياسي display: block أو تخطيط Flexbox. سيكون الوضع القياسي display: block الوضع الافتراضي ، لأن هذا هو ما سيستخدمه المستند الأساسي. قد يؤدي تمكين وضع عرض flexbox إلى ظهور جميع خيارات المحاذاة الأنيقة في المفتش. أيضًا ، من الواضح أنك تريد إعطاء وضعي التخطيط اسمًا مختلفًا في المفتش لجعله أكثر سهولة في الاستخدام. لكني لست متأكدًا مما قد تسميه لهم. ربما "قياسي" و "مرن"؟

السماح لكتل ​​الحاوية باستخدام الوضع الذي يدعم العوامات أو الوضع الذي يحتوي على خيارات محاذاة / تخطيط أفضل سيكون مفيدًا حقًا. يمكنك دمج كتل الحاوية لاستخدام كلا النوعين من التخطيط عند الضرورة. أضف هذا إلى القدرات الأخرى التي يمكن أن تمتلكها كتلة الحاوية (خيارات الخلفية ، والقدرة على اختيار علامة HTML للمعنى الدلالي الإضافي دون الحاجة إلى اللجوء إلى كتل HTML المخصصة ، وما إلى ذلك) وستصبح كتلة الحاوية واحدة من أهمها وكتل مفيدة في WordPress الأساسية.

والجدير بالذكر ، إذا كانت كتلة الحاوية ذات وضعين للتخطيط تبدو وكأنها العديد من الميزات (ولا أعتقد حقًا أنها ستكون مشكلة) ، فقد يكون هناك كتلتان منفصلتان فقط:

• كتلة حاوية قياسية تدعم العوامات ولكنها لا تحتوي على جميع خيارات المحاذاة / التخطيط المتقدمة
• كتلة حاوية متقدمة (أو تخطيط متقدم أو تخطيط مرن أو أي شيء تسميه) تستخدم تخطيط Flexbox وتوفر جميع الخيارات الأنيقة

أوصي بالاطلاع على فيديو توثيق Oxygen هذا لمعرفة كيفية عمل نظام التخطيط الخاص به. إنه أمر مثير للإعجاب حقًا:

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

أعتقد أن هناك الكثير من الإمكانات هنا لجعل جوتنبرج قويًا جدًا . بالطبع ، بالنسبة للتنفيذ الأولي ، أتوقع فقط أن يكون لكتلة الحاوية خيارات الخلفية ، والقدرة على تغيير عنصر HTML المستخدم ، وخيار جعل الحاوية كاملة العرض (ولكن ليس المحتوى الموجود بداخلها). ربما حتى مجرد خيارات الخلفية.

في الواقع ، مجرد وجود كتلة حاوية لا تحتوي على أي خيارات لا يزال مفيدًا ، لأنه يسهل تصميم مجموعة من الكتل عبر CSS.

من المهم التفكير في Gutenberg ليس فقط كما في التوقف بعد 5.0. هذه كتلة مفيدة حقًا وسيتم استكشافها ، ولكن بالنسبة للمرحلة الأولى ، فإن التركيز على التحرير ليس ضروريًا حقًا. عندما يتوسع المشروع إلى ما بعد التحرير البسيط في التخطيط ، فلا شك أن هناك حاجة إلى حل. لا أحد يقول أن هذا لن يتم إنشاؤه ، إنها مسألة تحديد أولويات ما هو المحرر وما الذي سيأخذ في المرحلة الثانية.

لكن الشيء هو أن غالبية الناس يستخدمون Gutenberg لأغراض التخطيط ، وليس لكتابة المشاركات.

لقد اعتاد الناس على كتابة منشورات مثل مستند Word ، لذا فهم يعطلون Gutenberg على صفحات Post.

لكن الشيء هو أن غالبية الناس يستخدمون Gutenberg لأغراض التخطيط ، وليس لكتابة المشاركات.

ما هو مصدر البيانات الذي تبني عليه هذا الافتراض؟

لقد تحدثت إلى العديد من الأشخاص خلال WCEU في بلغراد ، واتفقوا جميعًا على أنهم يجدون أنه من الغريب كتابة منشورات مع Gutenberg وبالتالي يقومون بتعطيلها في المشاركات.

على عكس ما رآه @ dingo-d ، أستخدم Gutenberg فقط للوظائف. في الواقع ، أجد تجربة ما بعد الإنشاء أجمل كثيرًا في Gutenberg مقارنة بالمحرر الكلاسيكي. يرجع ذلك جزئيًا إلى الطبيعة النمطية وعناصر التحكم السياقية ، وجزئيًا بسبب عدم وجود علامات <p> غير المرئية المزعجة في كل مكان. هذا يزعجني دائما

أحتاج إلى كتلة حاوية (حتى لو كانت بدون أي خيارات) وكتلة أعمدة مناسبة (أو كتلة تخطيط أخرى) من أجل استخدام Gutenberg لبناء صفحات متساوية. يبدو أن كتلة الأعمدة ستحصل على نوع من الاستجابة الأساسية (انظر # 6048) ، وهذا يعني أن الافتقار إلى كتلة الحاوية هو الذي يمنعني من استخدام Gutenberg في سياقات أكثر.

أعلم أنه من الواضح أنه سيتم إضافة كتلة الحاوية في وقت ما (ربما لا يتجاوز ذلك WordPress 5.1) ، لكنني أؤمن بشدة أنه يجب إضافتها قبل إصدار WordPress 5.0. حتى في سياق كتابة المنشورات ، يمكن أن تكون الحاوية مفيدة لشيء مثل <aside> (إذا كانت تحتوي على ميزة القائمة المنسدلة لاختيار عنصر HTML) لإضافة دلالات. في الوقت الحالي ، إذا كنت تريد التفاف أي شيء في عنصر HTML آخر للدلالات المضافة ، فيجب عليك استخدام كتلة HTML المخصصة ، مما يعني أنه لا يمكنك الاستفادة من ميزات كتلة الفقرة لأي فقرات في كتلة HTML المخصصة ، أو أي ميزات من كتلة الصورة لأي صور في كتلة HTML المخصصة ، وما إلى ذلك.

@ karmatosed

لا أحد يقول أن هذا لن يتم إنشاؤه ، إنها مسألة تحديد أولويات ما هو المحرر وما الذي سيأخذ في المرحلة الثانية.

في رأيي ، فإن كتلة الحاوية هي بالتأكيد شيء ينتمي إلى المرحلة الأولى.

ما أجده غريبًا هو أن كتلة الأعمدة تبدو وكأنها ستنتقل إلى WordPress 5.0 (ربما لا تزال تحمل تصنيف "(Beta)" هذا ، ومع ذلك قد لا يكون جزء Container block؟ إذا كان من المفترض أن يكون التركيز الآن على الكتابة المشاركات ، فلماذا تمت إضافة كتلة أعمدة ولكن بدون كتلة حاوية؟ إن كتلة الحاوية ، في رأيي ، أكثر فائدة بكثير في سياق المشاركات من كتلة الأعمدة. وبالطبع ، لها أيضًا الكثير من الفوائد في سياق بناء الصفحة كذلك.

إذا لم تصل كتلة الحاوية إلى ووردبريس 5.0 ، فهذا يعني أنها لن تظهر حتى الإصدار 5.1 ، مما يؤخر استخدامها من قبل معظم الناس لعدة أشهر. أريد أن ينجح Gutenberg ، وأشعر أنه لا يوجد سبب لمنع إصدار شيء أساسي مثل Container block حتى WordPress 5.1. من أجل الحصول على انطباعات أولى جيدة ، أوصي بإضافتها قبل وسيلة شرح WordPress 4.9.8.

لا أتوقع أن تحتوي على جميع الميزات التي اقترحها الناس ؛ يكفي مجرد وجوده لحل الكثير من حالات الاستخدام الشائعة التي لم تتم تغطيتها حاليًا إلا من خلال حل مبتكر لاستخدام كتلة أعمدة مع تعيين شريط تمرير الأعمدة يدويًا على 1. وبعد ذلك ، وجود خيار واحد فقط مثل خيارات ألوان الخلفية سيجعلها مفيدة أكثر.

أوافق على أن هذه كتلة رائعة ومفيدة ، لكنها كانت دائمًا تتعلق بالمرحلة 2 من المشروع ونحن بحاجة حقًا إلى التركيز أو لن نشحن أبدًا. لقد قمنا ببناء البنية التحتية للكتل المتداخلة لأنه كان من المهم الحصول على التجريدات بشكل صحيح ، والسماح للأشخاص ببناء كتل التخطيط المخصصة الخاصة بهم بحيث تكون الكتلة الأساسية الفعلية مثل هذه أقل أهمية. ينصب التركيز على الحصول على واجهة المستخدم المتداخلة والفرعية بشكل عام (باستخدام _Columns_ كخنزير غينيا).

كانت هذه المشكلة مفتوحة أيضًا لمدة خمسة أشهر حتى الآن ولم تكن هناك أي مقترحات تنفيذ قوية تتضمن أشياء مثل الألوان والعرض واتجاه الكتل مقابل الأعمدة المتداخلة والتداخل مع صورة الغلاف وما إلى ذلك. لا نعطيها الأولوية على الأعمال الأخرى ذات الأغراض العامة التي نحتاج إلى القيام بها ، وإشعار "try" الوشيك في WordPress. هذا لا يعني أنه لن يتم القطع ، خاصة إذا أراد شخص ما تقديم اقتراحات في التعليمات البرمجية.

أيضًا ، أكبر مشكلة بالنسبة لي هي أنه ليس واضحًا - مرئيًا فقط من المحادثة هنا - ما يجب أن تكون تجربة المستخدم المثالية للالتزام بالتنفيذ. تبدو أشياء مثل تعريض علامات html معقدة للغاية وغير بديهية للمستخدم العادي. إن فكرة الحاوية نفسها هي شيء يحتاج إلى اختبار أوسع لمعرفة ما إذا كان أفضل تجريد للتخطيط ، والذي ، مرة أخرى ، كان من المفترض أن يكون شيئًا يجب اكتشافه في مرحلة التركيز التالية. هناك أيضًا بعض الأشياء المجهولة حول كيفية قيام مثل هذه الكتلة بتدوير الأنماط وصولاً إلى الكتل التعسفية بداخلها - من السهل نسبيًا حساب الكتل الأساسية ، ولكن ليس أي كتلة عشوائية.

في الوقت نفسه ، يجب أن يكون لدى المطور الذي يرغب في تقديم كتلة مخصصة وقتًا سهلاً في تجميعه (مثل المقتطف الموضح أعلاه) مع أي علامة يريدها باستخدام InnerBlocks وجمع تعليقات المستخدمين. لذلك هناك ضغط أقل على اللب الذي يحتوي على مثل هذه الكتلة (ويتعين عليك الحفاظ عليه). بعد كل ما قيل ، يجب أن يشعر أي شخص بالحرية في تقديم اقتراح عبر العلاقات العامة والمساعدة في اختبار المستخدم له. سأكون موافقًا على إضافته إلى المكون الإضافي باعتباره "تجريبيًا" مع فكرة أنه قد يتم سحبه بعيدًا لمدة 5.0.

SuperGeniusZeb Oxygen رائع جدًا! يجب بالتأكيد النظر في بعض هذه الاستكشافات.

بدافع الفضول ، ماذا يحدث إذا أضافت السمات والمكونات الإضافية كتل الأقسام الخاصة بها ، وقام المستخدم بإلغاء تنشيط المكون الإضافي أو تغيير السمات؟ هل هناك نوع من الرجوع في المكان؟ أم يفقد المستخدم المحتوى الخاص به؟

tomusborne هناك مشكلة بخصوص هذا النوع من المواقف: # 7811.

آه! لم أكن أعرف أن هذا نوقش هنا. لذلك قمت أيضًا بإنشاء مكون إضافي لأنني كنت بحاجة إلى هذا.

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

لقد كنت أشاهد هذا الموضوع وأقدر كل الأفكار التي تدور فيه. لقد قمت مؤخرًا بإصدار كتلة حاوية في المكون الإضافي Atomic Blocks تحتوي على هوامش وحشوات وعرض الحاوية وخيارات صورة الخلفية والألوان. آمل أن يكون هذا مفيدًا ويمكن أن يوقفنا حتى تصل الكتلة الأساسية في وقت لاحق!

بعد هذه المشكلة .. لقد قمت بإنشاء كتلة "حاوية" تسمح باختيار بنية الأعمدة وخيارات أخرى.
إذا كان بإمكانه المساعدة في تحسين كتلة "الأعمدة" ، أو إنشاء كتلة جديدة في جوهرها ، فهي هنا: https://github.com/MarieComet/WP-container-block/

MarieComet هذا أنيق ، لكن أعتقد أنه يجب تقسيم مجموعتك إلى كتلتين مختلفتين. يجب أن يكون الأول عبارة عن كتلة أعمدة مع جميع خيارات تخطيط الهيكل القائم على العمود. والثاني هو كتلة الحاوية التي تحتوي على خيارات الخلفية وخيارات التخطيط التي لا تعتمد على الأعمدة ، مثل القدرة على استخدام المرن لتخطيط الأطفال أفقيًا بدلاً من عموديًا ومحاذاةهم وتبريرهم باستخدام الخيارات التي تتوافق مع خصائص CSS Flex.

ربما يمكنك أيضًا استخدام كتلة الحاوية لاستبدال كتل الأعمدة الفردية ، على الرغم من أنه قد تكون هناك بعض الخيارات التي قد ترغب في الحصول عليها في العمود والتي لا معنى لها في القسم.

لقد أدركت أن مستقبل إنشاء التخطيطات باستخدام HTML و CSS لا يتمثل في استخدام الأعمدة دائمًا مثل معظم منشئي الصفحات ، ولكن أيضًا للاستفادة من CSS Flex and Grid لعرض المحتوى باستخدام أقل من <div> s في الترميز والحصول على تصميم أكثر مرونة وأنظف. إن ما تفعله Oxygen يلهمني بشكل أساسي. لقد تحدثت عن Oxygen في هذا التعليق .

لا تتعلق هذه المشكلة باستبدال كتلة الأعمدة في الوقت الحالي. من المهم الاستمرار في التركيز على موضوع هذه المشكلة ، أي مقطع مقطع.

karmatosedmelchoyce عند الحديث عن ذلك ، ألا يجب إعادة تسمية هذه المشكلة؟ توقفنا عن تسميته "قسم" وانتقلنا إلى "حاوية" لتجنب الالتباس مع عناصر <section> .

لم يتم تحديد الاسم ، لذا فنحن جميعًا على ما يرام.

في الوقت الحالي أحاول تنفيذ موضوع مع محرر Gutenberg.

يحتوي تصميم الموقع على مناطق مختلفة بخلفيات مختلفة ، والتي تحتوي على عدة عناصر مثل الفقرات أو القوائم. هذا لأغراض التخطيط ولأغراض الملاحة. يجب أن تعمل كتل القسم / الحاوية كإرساء / يجب أن تحتوي على معرّفات CSS فريدة.

لا يمكنني إنهاء هذا الموضوع بدون "اختراق Gutenberg" عن طريق إنشاء الكتل الخاصة. يمكن أن يتم ذلك مع هذه الكتلة الأساسية بدلاً من ذلك. لن أستخدم محرر Gutenberg فقط للنص العادي والتخطيطات البسيطة - يجب أن يتم تخطيطي / تصميمي المستقبلي جنبًا إلى جنب مع السمة ونظام كتلة Gutenberg.

آمل حقًا أن يتم إعطاء هذا الموضوع أولوية أعلى.

أنا أستخدم كتل حاويات تابعة لجهة خارجية في كل مكان (على سبيل المثال ، كتل ذرية) ، بالاقتران مع كتلة الأعمدة. لقد كانت مفيدة للغاية وأكثر كتلتي شعبية. أجد أنه من الغريب أن يتم اعتباره لاحقًا في المستقبل أو كإضافة ؛ يجب أن يكون في جوهره.

بخلاف ذلك ، سأقوم فقط بإنشاء الحاويات يدويًا في عرض HTML ، ولكن هذا أمر مزعج / غير فعال لأن عرض HTML عبارة عن نقرة قائمة إضافية. يوجد اختصار لوحة مفاتيح لعرض HTML ... shift + option + cmd + M ... نعم. ولا حتى التبديل ذهابًا وإيابًا. لا يؤدي ضرب الاختصار مرة أخرى إلى أي شيء. للرجوع إلى طريقة عرض WYSIWYG ، يلزمك استعراض القوائم. سيكون مفتاح التبديل الكبير في شريط الأدوات الرئيسي كبيرًا.

هل قام أي شخص بالفهرسة / يحتفظ بقائمة التنفيذ حاليًا في البرية؟ أعتقد أنه سيحتاج أيضًا إلى نوع من مصفوفة المعلمات "الأشياء التي تتم بشكل صحيح ، وما هو خاطئ". على سبيل المثال ، تحديد الوحدات المشفرة (px) للحشوات / الهوامش المرتبطة (خطأ) ، عندما يجب أن تكون الوحدات على الأرجح خيارًا متروكًا للمستخدم (يمين) ، إلخ.

يحتوي https://editorblockswp.com/library/ على البعض في الكتالوج ، ولكن من أجل دفع هذه المشكلة إلى الأمام ، يبدو أن شيئًا خاصًا بالأقسام / الحاويات يجب أن يحدث.

في رأيي ، سيكون لكتلة الحاوية الأساسية الخيارات التالية على الأقل:

• الصورة الخلفية
• لون الخلفية
• القدرة على تراكب لون الخلفية على الصورة والتحكم في التعتيم
• خيارات الحشو والهامش لجميع الاتجاهات الأربعة ، مع إمكانية تبديل الوحدات المستخدمة بشكل فردي لكل قيمة
• دعم لمحاذاة تعويم اليسار ، عائم لليمين ، عريض ، ومحاذاة كاملة
• القدرة على التحكم في أقصى عرض للكتل المحتواة بطريقة ما
• القدرة على اختيار عنصر html الذي تستخدمه الحاوية

بالإضافة إلى ذلك ، أفضل أيضًا الحصول على ما يلي:

• خيارات تخطيط CSS المرن: القدرة على ضبط اتجاه تدفق المحتوى من أعلى إلى أسفل إلى اليسار واليمين واليمين واليسار ومن الأسفل إلى الأعلى ؛ والقدرة على ضبط المحاذاة الرأسية والأفقية للمحتوى
• بالطبع ، استخدام خيارات المرن غير متوافق مع محاذاة الطفو ، لذلك يجب أن تحتوي الكتلة على وضعين للتخطيط على الأقل: قياسي ومرن ، وإلا يجب أن يكون هناك كتلة Flex Container منفصلة
• حجم الخط وخيارات الألوان لتعيين الإعدادات الافتراضية للمحتوى في الحاوية وتجنب الاضطرار إلى تعيينها لكل كتلة متضمنة على حدة

نشر فيليكس أرنتز للتو منشور مدونة يتعلق بتنفيذ قسم القسم الخاص به.
تعجبني صورة الخلفية سريعة الاستجابة.
https://felix-arntz.me/blog/building-a-reusable-gutenberg-section-block/

في الأسابيع الماضية ، كنت أجرب تطبيق Marc Lacroix ، والذي يعمل بشكل جيد ، ولكن يبدو أنه اخترق gutenberg 3.9.0 https://github.com/marcusig/gutenberg-section-block

لقد كنت أفكر في هذا لبعض الوقت. تشير حقيقة ظهور العديد من التطبيقات إلى أنها ذات قيمة كبيرة وربما يكون من الأفضل لـ Core تقديم آلية متسقة لتجنب التجزئة. قلقي الرئيسي هو حول تعقيد كتلة "قسم" للمستخدم.

أقترح البدء بسيطًا جدًا ، باستخدام حاوية فقط (منطقة InnerBlocks واحدة) ، ومحاذاة واسعة وكاملة ، وإعداد لون الخلفية (بدون صورة ، إلخ - لدينا "غطاء" لذلك).

ليس لدينا الكثير من الوقت للقيام بذلك إذا أردنا ذلك في الإصدار 5.0.

mtias إذا كان تعريض كتلة حاوية للمستخدم النهائي يمثل مصدر قلق ، فربما يجب أن تحتوي كل كتلة على إعدادات حاوية أو حاوية بشكل افتراضي.

ثم لا داعي للقلق بشأن تعليم المستخدم النهائي أنه يحتاج إلى لف شيء ما في حاوية من أجل الحصول على أشياء معينة مثل صورة الخلفية.

أعتقد أن هذه فكرة جيدة في الواقع لأن الأشخاص الذين يرغبون في تمديد أو لف الكتل التعسفية سيكون لديهم مكان واضح للقيام بذلك ، وسيكون المستخدمون النهائيون على دراية بها لأنها موجودة في كل كتلة.

ربما يمكن أن تكون "إعدادات الحاوية" علامة تبويب بجوار "إعدادات الحظر". سيكون هذا مكانًا (قابلًا للتوسيع) للمطورين لإسقاط (أو تصفية) أشياء مثل إعدادات صورة الخلفية ، وإعدادات العرض ، وما إلى ذلك.

سيعطي هذا أيضًا للمطورين مكانًا لوضع إعدادات أكثر تعقيدًا يمكن تطبيقها على أي كتلة تقريبًا ، مثل عناصر التحكم سريعة الاستجابة / نقاط التوقف.

rchipka من الناحية الفنية ، يتم تغليف معظم الكتل

لا تكمن قوة الحاوية تمامًا في كتلة واحدة ، بل تتيح لك إضافة كتل أخرى داخل الحاوية ، مما يؤدي إلى إنشاء تخطيطات وأقسام وبنية صفحة أكثر تعقيدًا.

mikemcalister نقطة جيدة ، سيظل المستخدم النهائي بحاجة إلى طريقة لتجميع / تنظيم شجرة الكتل بشكل مرئي.

أعتقد أن الفلسفة لا تزال كما هي. إذا كان لدى المحرر آلية تجميع كتل على شكل شجرة (أي بدون واجهة "Container Block") ، فإن "إعدادات الحاوية" لأي كتلة فرعية ستعكس إعدادات تلك المجموعة (أي ذلك المستوى في الشجرة).

مرة أخرى ، فإن النقطة الوحيدة لهذه الفكرة هي تقليل عدد الخطوات التي ينطوي عليها المستخدم النهائي ، وبالتالي تقليل منحنى التعلم وزيادة قابلية الاكتشاف.

أعتقد أن المشكلة الرئيسية هي أن موقع Gutenberg يقتصر حاليًا على محتوى المنشور / الصفحة القياسي. بدون كتلة القسم / الحاوية ، ليس لدينا طريقة للسماح للمستخدمين ببناء صفحات أمامية بأقسام كاملة العرض (مع لون خلفية صلب / متدرج أو صورة خلفية كاملة العرض) مع كل أنواع المحتوى بالداخل (نأمل عبر الكتل المتداخلة).

ستكون كتلة القسم / الحاوية مثالية هنا. حتى عنصر أساسي يمكن توسيعه بمزيد من الضوابط حسب السمات / المكونات الإضافية. أرغب في الحصول على المزيد من إعدادات المحاذاة هناك أيضًا. نحن بالفعل نقوم بشيء ما باستخدام CMB للحصول على مُنشئ صفحات زائفة على الصفحات مباشرةً ، لكننا نأمل حقًا أن يتمكن Gutenberg من جعل هذا الأمر أكثر مرونة للجميع.

JiveDig لا أعتقد أن أي شخص ، بما في ذلك فريق Gutenberg ، يعارض نوعًا من آلية حاوية القوالب.

يتمثل التردد الرئيسي من فريق Gutenberg (في هذه الحالة والعديد من الآخرين) في إبقاء الواجهة الأساسية منخفضة إلى مستوى Squarespace من التعقيد من وجهة نظر UI / UX.

من أجل تنفيذ هذا في جوهره ، يبدو أن المشكلة الأساسية هي إيجاد طريقة يمكن من خلالها تمثيل ذلك دون وضع عبء إضافي على المستخدمين النهائيين.

على الرغم من، في رأيي، لا يبدو مثل صفقة كبيرة، و "كتلة الحاويات" لا عبئا صغير على المستخدم النهائي التي تتطلب معرفة الغرض منه واستخدامه.

لهذا السبب اقترحت مفهوم "التجميع" كمقياس أكثر ودودًا لـ "الحاويات" للمستخدمين النهائيين.

لن يفكر المستخدم النهائي من حيث التفاف الكتل في الحاويات وبدلاً من ذلك سيفكر في تجميع الكتل معًا ، الأمر الذي يبدو أكثر سهولة.

بهذه الطريقة ، لا يحتاج المستخدم النهائي إلى معرفة أي شيء مسبقًا من أجل تجميع الكتل معًا وتطبيق الإعدادات على تلك المجموعة.

بالطبع ، ستعمل هذه "المجموعات" تمامًا مثل كتلة الحاوية داخليًا ، إنها مجرد واجهة أمامية أكثر تكاملاً وبديهية.

rchipka طريقة سهلة للغاية للتعامل والتي

نعم ، يجب أن تكون كتلة القسم في جوهرها. يكفي تقديم div بسيط في HTML. ولكن نظرًا لوجود المئات من السمات التي يمكن تقديمها ، أقترح بشدة بدلاً من ذلك أن السمتين اللتين يجب تقديمهما هما CLASS و ID (مع كون المعرف هو الأقل أهمية). بهذه الطريقة يمكن تصميم العناصر في CSS حيث ينبغي أن تكون.

-
أوضاع ويس
تاريخ سري لشعب النهر الأمريكي
http://peoplesriverhistory.us

مرسلة من بلدي أبل] [ه

في 12 تشرين الأول (أكتوبر) 2018 ، الساعة 8:09 صباحًا ، كتب Matias Ventura [email protected] :

لقد كنت أفكر في هذا لبعض الوقت. تشير حقيقة ظهور العديد من التطبيقات إلى أنها ذات قيمة كبيرة وربما يكون من الأفضل لـ Core تقديم آلية متسقة لتجنب التجزئة. قلقي الرئيسي هو حول تعقيد كتلة "قسم" للمستخدم.

أقترح البدء بسيطًا جدًا ، فقط بحاوية وإعداد للون الخلفية (بدون صورة ، إلخ - لدينا "غطاء" لذلك).

ليس لدينا الكثير من الوقت للقيام بذلك إذا أردنا ذلك في الإصدار 5.0.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

مرة أخرى ، يجب أن تتمتع كل كتلة بالقدرة على تعيين سمة الفئة الخاصة بها. بغض النظر عن النوع.

-
أوضاع ويس
تاريخ سري لشعب النهر الأمريكي
http://peoplesriverhistory.us

مرسلة من بلدي أبل] [ه

في 12 أكتوبر 2018 ، الساعة 8:40 صباحًا ، كتب Robbie Chipka [email protected] :

mtias إذا كان تعريض كتلة حاوية للمستخدم النهائي يمثل مصدر قلق ، فربما يجب أن تحتوي كل كتلة على إعدادات حاوية أو حاوية بشكل افتراضي.

ثم لا داعي للقلق بشأن تعليم المستخدم النهائي أنه يحتاج إلى لف شيء ما في حاوية من أجل الحصول على أشياء معينة مثل صورة الخلفية.

أعتقد أن هذه فكرة جيدة في الواقع لأن الأشخاص الذين يرغبون في تمديد أو لف الكتل التعسفية سيكون لديهم مكان واضح للقيام بذلك ، وسيكون المستخدمون النهائيون على دراية بها لأنها موجودة في كل كتلة.

ربما يمكن أن تكون "إعدادات الحاوية" علامة تبويب بجوار "إعدادات الحظر". سيكون هذا مكانًا (قابلًا للتوسيع) للمطورين لإسقاط (أو تصفية) أشياء مثل إعدادات صورة الخلفية ، وإعدادات العرض ، وما إلى ذلك.

سيعطي هذا أيضًا للمطورين مكانًا لوضع إعدادات أكثر تعقيدًا يمكن تطبيقها على أي كتلة تقريبًا ، مثل عناصر التحكم سريعة الاستجابة / نقاط التوقف.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

لا أعارض طريقة التجميع (طالما يمكنني تعيين سمات الفئة) ، على الرغم من أنه سيكون من الرائع وجود كتلة حاوية أيضًا إذا كنت ترغب في البناء بهذه الطريقة.

-
أوضاع ويس
تاريخ سري لشعب النهر الأمريكي
http://peoplesriverhistory.us

مرسلة من بلدي أبل] [ه

في 12 أكتوبر 2018 ، في الساعة 10:50 صباحًا ، كتب كريس فان باتين [email protected] :

rchipka طريقة سهلة للغاية للتعامل والتي

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

chrisvanpatten أوافق ، ولكن هذا الحل لا يعالج بشكل كاف اهتمامmtias الأصلي بتعريض مفهوم الحاوية أو القسم للمستخدم النهائي.

المشكلة ، كما أثارتها mtias ، لا تتعلق بالخدمات اللوجستية لوضع الكتل في حاوية ، بل تتعلق بتقديم تلك الواجهة بشكل حدسي للمستخدم النهائي (دون الكشف عن أنواع كتل إضافية).

إن مناقشة "كيف نحصل على الكتل في الحاوية" ضرورية. ومع ذلك ، لا أرى بالضرورة أنه معقد للغاية للمستخدم. لن يستخدمه العديد من المستخدمين ، أو على الأقل لن يستخدموه خارج صفحتهم الرئيسية. يعبر العديد من عملائنا وعملاء السمات عن رغبات / احتياجات مواقع الويب الخاصة بهم بعبارات مرئية تناسب كتلة القسم. يقولون أشياء مثل ، "أريد عرضًا كاملاً كبيرًا {شريط / منطقة / قسم / كتلة / لوحة / امتداد} مع صورة جميلة" متبوعة "، و {إدراج طلبات المحتوى هنا} في هذا القسم". يفهمون بصريًا أن القسم نفسه (الحاوية) منفصل عن المحتوى الموجود بداخله.

من المؤكد أن كيفية القيام بذلك عبر واجهة المستخدم تحتاج إلى العمل عليها ، ولكن آمل أن تكون نقطتي أعلاه منطقية.

chrisvanpatten يستند بياني السابق فقط على دلالات أنواع الكتل.

السبب الوحيد الذي أجادله حول الدلالات هنا هو نيابة عن

يعجبني اقتراحك ، ولكن إذا كنت أتبع القياس الخاص بي ، فربما أغير الدلالات "مجموعة (كتل) مختارة من المجموعة".

rchipka ليست هذه هي الطريقة التي فسرت بها تعليقه - لقد

بعد قولي هذا ، أنا سعيد جدًا لكوني مخطئ :)

JiveDig أتفق كثيرا ....

ومع ذلك ، يبدو أن فريق Gutenberg شديد الحساسية لتعريض هذه الأشياء للمستخدم النهائي في Gutenberg core.

هذا هو الأساس الوحيد لدي لإثارة هذه الحجج وتقديم هذه الأفكار.

مرة أخرى ، إذا كنت أنا ، لكنا لدينا كتلة الحاوية اللعينة.

لا أعتقد أن كتلة الحاوية منطقية حقًا ، لأنها ستؤدي إلى تشويش واجهة المستخدم. أفضل أن أرى شيئًا مثل علامة "فاصل القسم" التي تراها مضمنة في Microsoft Word. ستوفر إضافة فاصل قسم بعض خيارات الأنماط في المفتش مثل اسم فئة للقسم ولون الخلفية ولون النص والظل المسقط ، أيًا كان ما يحدد أسلوبيًا القسم الخاص بك. يمكن إدخالها مثل أي كتلة وتحريكها مثل أي كتلة.

rwrobe هذه الفكرة لا تعمل مع الحاويات المتداخلة.

أقوم حاليًا ببناء موقع باستخدام Gutenberg واستخدمت بشدة نسخة معدلة من

• "القسم" هو أفضل اسم للكتلة. معناه واضح للمطورين والمستخدمين النهائيين ، ويتجنب تعقيد العلامات / الخيارات من خلال استخدام كتلة <section> منطقيًا.

• خيارات قائمة السياق الوحيدة المطلوبة هي محاذاة / واسعة / كاملة (وفي الحقيقة أنا فقط استخدم alignfull). لا تؤثر المحاذاة على الكتل الداخلية ، والتي تظل ضمن المحاذاة العادية ما لم يكن لديها خيارات المحاذاة الخاصة بها. كانت حالة الاستخدام الأساسية هي إنشاء لون خلفية محاذي يحتوي على كتلة نصية محاذاة بشكل طبيعي - نمط تصميم شائع جدًا غير ممكن حاليًا.

• إعدادات كتلة الشريط الجانبي الوحيدة المطلوبة هي لون الخلفية وصورة الخلفية (مع خيارات ثابتة / عتامة مرتبطة). يمكن التعامل مع أي تخصيص إضافي باستخدام فئة CSS المخصصة. (إن تضمين خيار صورة الخلفية له أيضًا تأثير جانبي لتحويل هذا إلى إصدار أكثر فائدة من Cover Block.) (ولكن: إذا كان mtias محقًا ، فإن تجنب تلك المحادثة من خلال تضمين خيار لون الخلفية فقط سيؤدي إلى إخراج هذا الباب أسرع ، فأنا جميعًا من أجله.)

• سهولة الاستخدام كانت بسيطة. أسهل من الأعمدة التي كانت موجودة منذ فترة حتى الآن. المشكلة الوحيدة المحتملة هي أنه عند إضافة القسم لأول مرة ، يتم تحويل التركيز إلى فقرة داخل القسم ، لذلك قد يكون من الصعب معرفة أن القسم قد تمت إضافته للتو حتى تقوم بتمرير الماوس فوقه. أحد الحلول الممكنة لذلك هو تعيين لون خلفية رمادي فاتح.

ZebulanStanphill هل تتحدث عن الأعمدة؟ يمكنني رؤية كتل "القسم" تؤدي المهمة للمحتوى المنفصل عموديًا - يمكن حتى أن يكون هناك تبديل لتوريث الأنماط من القسم السابق ، وهو نوع يسمح لك "بتداخل" أشكال مختلفة داخل القسم.

يبدو التكوين الأفقي ، كما هو الحال في الأعمدة ، أكثر صعوبة بالضرورة بسبب الطريقة التي يبني بها Gutenberg الصفحة من أعلى إلى أسفل في كتل كاملة العرض.

mikedance أعتقد أن هذا هو بالضبط ما هو مطلوب. سيكون خيار صورة الخلفية مهمًا على الرغم من IMO. ربما يمكن أن تحل هذه الكتلة محل Cover Block بعد ذلك ، على الرغم من أن التسمية قد لا تكون مناسبة للأشخاص الذين - فقط - يريدون صورة خلفية مع نص أساسي فوقها. على الرغم من وجود بعض التداخل في الوظائف ، إلا أنه قد يزيل نسبة كبيرة من حالات الاستخدام لكتلة القسم دون إضافة دعم صورة bg.

rwrobe وتجدر الإشارة إلى أنه يمكنك وضع كتل أفقية. كتل العمود (لاحظ عدم وجود "s") هي فقط ذلك. تضعهم كتلة الأعمدة أفقيًا. ربما يمكن تحسين واجهة المستخدم في بعض المناطق ، لكن الكتل لا تقتصر على العرض الكامل أو المخطط الرأسي.

mikedance

"القسم" هو أفضل اسم للكتلة. معناه واضح للمطورين والمستخدمين النهائيين ، وهو يتجنب تعقيد العلامات / الخيارات من خلال استخدام منطقي

منع.

نظرًا لأن العنصر <section> يحتوي على دلالات مرتبطة به ، فمن الأفضل أن تختار استخدام <div> بدلاً من <section> ، لأنه في كثير من الحالات تريد الالتفاف عدة كتل ، لكنها ليست جزءًا من القسم المعنوي. في الواقع ، سيكون من الأفضل إذا كان بإمكانك أيضًا اختيار استخدام عناصر مثل <aside> أو <header> ، الأخير مفيد بشكل خاص لإضافة دلالات إلى العناوين ذات الخلفيات في بناء الصفحة.

في ملاحظة أخرى ، أعتقد أن توفر خيارات صورة الخلفية لكتلة الحاوية سيكون مفيدًا للغاية. بالطبع ، يصبح التداخل مع مفهوم كتلة الغلاف واضحًا تمامًا. إذا جعلت كتلة الغلاف أكثر مرونة ، فإنها تتحول أساسًا إلى كتلة حاوية على أي حال ، لذلك ربما لا يلزم وجود مفهوم كتلة الغلاف؟ يمكن لكتلة الحاوية أن تفعل كل ما تفعله تقريبًا. يمكن أن يكون مفهوم الغلاف مجرد قالب قالب قابل لإعادة الاستخدام.

تضمين التغريدة سيكون من المفيد أن يكون التكوين المتقدم الذي يسمح لك بتحديد ما إذا كان قسمًا أم رأسًا أم جانبًا أم div (افتراضيًا). نعم ، قد لا يستخدم معظم المستخدمين هذا الخيار ، ولكنه خيار يدعم تطوير الويب الجيد.

كيف يمكن للموضوع أن يتكامل؟ هل يمكن للموضوع إضافة "تنويعات" إلى كتلة ، في هذه الحالة
كتلة القسم ويمكن للمستخدم أن يختار مباشرة واحدة من أولها ويرى الأنماط الناتجة المطبقة؟
كما قد يكون من المفيد جدًا إضافة مرشح أو خطاف إلى كتلة القسم للسماح به
يضيف السمة غلافًا وعناصر أخرى مطلوبة أحيانًا للتصميم.

ZebulanStanphillwmodes أشك في أن تضمين خيار لتحديد العنصر المحتوي المطورين الأساسيين. إنها تعقيد مفرط. من وجهة نظر معينة ، يكون عنصر <section> دلاليًا بقدر ما يمكن أن يكون لأن المستخدم يعرفه بالفعل على أنه "قسم" بحكم إنشاء الكتلة. الأمر متروك لهم لاستخدامه بشكل مسؤول ، تمامًا مثل العناوين. ولكن إذا كان من شأنه تجنب حجة الدلالات ، فليس لدي مشكلة في استخدام <div>.

mikedance متفق عليه ، ربما يجب علينا فقط استخدام <div> . إذا كان التخطيط الدلالي مصدر قلق ، فمن الأفضل التعامل معه على أنه امتداد لكتلة الحاوية.

strarsis Themes يمكن استخدام واجهة برمجة تطبيقات أنماط الكتلة الحالية لإضافة أنماط إلى الكتل. (تشتمل كتلة Button و Quote الأساسية على العديد من أنماط الأنماط بشكل افتراضي.) لسوء الحظ ، لا يمكنني العثور على أي وثائق حول هذه الوظيفة. (هناك عدة مشكلات في تتبع النقص الحالي في المستندات: https://github.com/WordPress/gutenberg/milestone/500)

mikedance

من وجهة نظر معينة

يعتبر العنصر دلاليًا قدر الإمكان لأن المستخدم يعرفه بالفعل على أنه "قسم" بحكم إنشاء الكتلة.

أعتقد أنني فهمت ما تقوله ، لكني أختلف. في كثير من الحالات ، سيتم استخدام كتلة الحاوية ببساطة لإضافة لون خلفية إلى زوجين أو حتى كتلة واحدة لا تحتوي على الخلفية الخاصة بها (أو خيارات التصميم الأخرى). يتم تغليف كتلة القائمة في حاوية لمنحها لون خلفية وإبرازها لا يعني أن القائمة موجودة في قسمها الخاص.

لكن نعم ، <div> هو الخيار الأكثر حيادية لأنه ليس له معنى دلالي. إذا لم يكن هناك أبدًا خيار أساسي لتغيير عنصر HTML ، فإن الخيار الأفضل هو <div> .

السبب الرئيسي في رغبتي في القدرة على اختيار علامة HTML هو أنها تتيح لك إنشاء صفحات ومنشورات دلالية بسهولة أكبر دون الحاجة إلى اللجوء إلى كتلة HTML المخصصة أو المكونات الإضافية التي تضيف كتل مخصصة. إذا كنت تريد استخدام علامة <section> في Gutenberg في الوقت الحالي ، فستضطر في النهاية إلى وضع كل شيء في هذا القسم في كتلة HTML مخصصة ، مما يؤدي إلى فقدان إمكانات التحرير المرئي لأشياء مثل الفقرات والقوائم وما إلى ذلك. وإلا. ربما يمكن إظهار مبدل العلامات ضمن المجموعة المتقدمة في المفتش؟

تضمين التغريدة

يمكنك العثور على مستندات لإضافة Block Styles في كتيب تحت التمديد https://wordpress.org/gutenberg/handbook/extensibility/extending-blocks/#block -style-variations

تضمين التغريدة لقد راجعت تلك الصفحة عدة مرات لكنني ظللت أفتقد هذا القسم بطريقة ما. : يضحك:

ajitbohra : شكرا! هل هناك عرض توضيحي لتغيرات نمط كتلة جوتنبرج بالمناسبة؟

تضمين التغريدة

نعم ، تحقق من الكتلة الأساسية button و quote block

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 حتى يكون لدينا مزيد من الوقت لتحديد كيفية تقديم هذه الكتلة.

بينما أفكر في ذلك ... نظرًا لوجود تداخل بين هذا وكتلة Cover ، ماذا لو كانت كتلة Cover عبارة عن "تكوين" في ذلك عندما تضيف تلك الكتلة ، فإنها تضيف فعلاً قسم مكون مسبقًا مع عنوان أو كتلة نص / فقرة متداخلة بداخلها؟

تضمين التغريدة

ماذا لو كانت كتلة الغلاف عبارة عن "تكوين" في ذلك عندما تضيف تلك الكتلة ، فإنها تضيف حقًا قسمًا تم تكوينه مسبقًا مع كتلة عنوان أو نص / فقرة متداخلة بداخلها؟

يبدو هذا كثيرًا مثل كتلة قابلة لإعادة الاستخدام يتم إدخالها ككتلة قائمة بذاتها بالنسبة لي. ربما تتضمن النواة العديد من قوالب الكتل القابلة لإعادة الاستخدام افتراضيًا مثل هذا. يجب تحسين واجهة المستخدم لجعل إدخال كتلة قابلة لإعادة الاستخدام ككائن مستقل أسهل. انظر # 8403.

هل سيكون هناك شوكة لاختبار القسم الجديد / كتلة الحاوية؟ أنا مهتم باللعب به والمساعدة في اختباره.

تعد كتلة الحاوية / القسم مفيدة للغاية ، وكان علي استخدام ملف
كتلة حاوية كتل جوتنبرج المتقدمة في الوقت الحالي.
ومن المهم جعل كتلة القسم / الحاوية مرئية بسهولة وقابلة للتحديد.

في جزء من التعليق للإشارة إلى أن كتلة القسم ستكون مفيدة بشكل لا يصدق لتطوير القالب.

لقد أنشأنا مؤخرًا قسمًا مخصصًا بدلاً من هذا العنصر الأساسي واكتشفنا مشكلة حيث لم يتم تحديث سمات الكتلة إذا ظلت الكتلة كما هي ولكن السمات كانت تتغير.

تم حل هذا في PR # 12406 (أعلاه)

هل ما زالت كتلة المقطع تعتبر 5.1 (مستهدفة في 21 فبراير 2019) أو لاحقًا؟

لقد كتبت مكونًا إضافيًا لكتلة القسم ، والذي استخدمته في مشروعين وأتمنى إصداره كشيء أكثر عمومية في مستودع المكونات الإضافية. يسمح بتعيين ألوان الخلفية والصور أو الفيديو ، بالإضافة إلى فئة محددة حسب الموضوع لتنسيق العناصر الموجودة في منطقة innerblocks .

في حالات الاستخدام الخاصة بي ، كان من الأسهل على العميل أن يكون لديه حقول وصف وعنوان (اختياري) محددة مسبقًا فوق منطقة الكتل الداخلية حيث يمكنهم تكديس "العناصر" ، والتي كانت ، في حالة الاستخدام الخاصة بي ، عبارة عن أدوات زائفة قمت بإنشائها باستخدام كتلة أخرى نوع. ولكن يمكن أن يكون هذا مجرد أقسام متداخلة بسيطة ، حيث احتوت كتلة القسم الأول على عنوان ، فقرة ثم كتلة قسم أخرى ، والتي بدورها تحتوي على العناصر ...

الأقسام تعني أن gutenberg _must_ يجب أن يكون قادرًا على التعامل بشكل صحيح مع الأقسام التي تم ضبط عرضها على flex وتقديم خصائص الأطفال الفورية flex بشكل صحيح.

أقوم بعرض الأقسام الخاصة بي في JS لكن الكود يحتوي على عدد مما أعتبره اختراقًا. جعلها في PHP سيكون بمثابة قطعة من الكعكة ... باستثناء إرسال محتوى innerblocks إلى 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. أنا سعيد لسماع أنه مخطط لإصدار مستقبلي ، لكنني أشعر بخيبة أمل لأن لا أحد يعمل عليه الآن. بدون ذلك ، لا يزال المستخدمون غير قادرين على تخطيط تنسيقات الصفحات الشائعة ولا يزال مطورو السمات بحاجة إلى اللجوء إلى تقنيات الملكية للوصول بها إلى حيث يمكن للمستخدم بالفعل إنشاء تخطيط صفحة مشترك بشكل معقول.

يجب أن تكون كتلة القسم في Gutenberg الأساسية (وقابلة للتكوين وقابلة للتوسيع حسب السمات) من أجل حل مشكلات القدرة على تخطيط صفحات أكثر تعقيدًا والاستمرار في تغيير السمات.

بالتأكيد ، بصفتي مصممًا للقوالب ، سأضيف لوحة الألوان الخاصة بي ، والتحكم في الهوامش والحشو لمطابقة موضوعاتي ، وتنسيق الصور لمطابقتها ، وجميع هذه الأنواع من عناصر "التصميم" الخاصة بالموضوع ... ولكن مستخدم يجب أن تكون قادرًا على التبديل إلى أي سمة من سمات WordPress وأن يتم الاحتفاظ بمحتواها على الأقل ، في نفس التصميم بشكل أساسي (أقسام مجمعة ، وأعمدة ، وما إلى ذلك) ، وتكون قابلة للتحرير مثل Gutenberg Block (دون الحاجة إلى التبديل إلى كتلة HTML مخصصة).

لديّ مكونًا إضافيًا لكتلة القسم لدي إصدار قديم من العمل ، وآمل تحديثه لاحقًا هذا الأسبوع وإرساله إلى المستودع. يسمح بالتداخل اللانهائي للكتلة (أعني ، في حدود المعقول ، أفترض). يسمح المكون الإضافي أيضًا للقوالب أو المكونات الإضافية بتحديد أنماط الأقسام الخاصة بهم إذا أرادوا ، والتي يمكن للمستخدم بعد ذلك اختيارها. أخطط لتضمين عدد قليل من الأنماط الافتراضية ، والتي يمكن تعطيلها حسب السمات ، إذا رغبت في ذلك.

لوحات المفتش

• _Background._ يسمح المكون الإضافي الخاص بي بتعيين لون الخلفية و / أو الصورة إذا رغبت في ذلك ، مع وجود عناصر تحكم في وضع الصورة والمزج وإلغاء التشبع وحتى تراكب اللون.
• _ الأبعاد ، الحشو ، الهوامش. بشكل افتراضي ، ترتفع الأقسام تلقائيًا للمحتويات وتلتزم بالمحاذاة الكاملة والواسعة والوسطى ، بحيث يكون اليسار واليمين عند 45٪. ومع ذلك ، سأضيف عناصر تحكم للسماح بعرض و / أو ارتفاع محددين ، والحشو حول القوالب الداخلية والهامش حول الكتلة. _ ولكن انظر أدناه للتعرف على المشكلات المتعلقة بـ Gutenberg._
• _الأعمدة ... والصفوف ._ بعد الكثير من التجارب باستخدام المرن ، CSS _grid_ للأطفال المباشرين هي أفضل طريقة للاستخدام إذا كنت تتبع تخطيطًا قائمًا على عمود. استخدام الشبكة هو تبديل ؛ وإلا فإن الأطفال مجرد كتل عادية. (بصراحة ، في حين أن الصفوف قابلة للتنفيذ ، فإنها تضيف الكثير من التعقيد إلى واجهة التحرير التي يمكن التعامل معها بشكل أفضل عن طريق إضافة قسم جديد أسفل القسم الذي تعمل عليه عندما تحتاج إلى بدء صف جديد.) الشبكة أفضل من مرن - حتى لو كنت تقوم فقط بعمل أعمدة - لأن المرن _ يتطلب_ ارتفاعًا محددًا غير نسبة مئوية يتم تعيينه على الحاوية أو العناصر الفرعية ، مما يزيل الكثير من المرونة.

التليفون المحمول
إحدى المشكلات المتعلقة بأي مكون إضافي للقسم باستخدام الشبكة هي ما يحدث للشبكة عند نقاط توقف متنقلة محددة. يجب أن يكون المستخدمون (أو مؤلفو السمات) قادرين على تحديد متى ينتقل القسم من عرض 3 عناصر إلى عنصرين عبر عنصر واحد عبر.

يجب أن تكون نقاط التوقف قابلة للتحديد من خلال الموضوع ولا تشعر حقًا أنها تنتمي إلى الكتلة نفسها ، لأنها تضيف مجموعة كبيرة أخرى من خيارات المفتش ، وربما تريد أن تكون نقاط التوقف الخاصة بك متسقة عبر المنشورات والصفحات . ولكن عند استخدام خيار الشبكة ، تحتاج الكتلة إلى معرفة نقاط التوقف ، وتحتاج إلى السماح للمستخدم (أو السمة) بتحديد كيفية تكييف تخطيط القسم معها.

أنا متأكد من أن هناك طريقة أنيقة للقيام بذلك ، ولكن على المدى القصير من أجل المنفعة ، فأنا ببساطة أسمح للكتلة "بالتعرف" على نقاط التوقف عبر التهيئة ثم استخدام قائمة قيم مفصولة بفواصل للمعرّف نقاط التوقف (تخيل لقطة شاشة هنا):

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

إلخ (من الواضح أن الأعمدة المفردة هي 100٪ ولا تحتاج إلى تحديد).

اعتبارات الموضوع والإضافات
يمكن للقالب (أو المكون الإضافي) تحديد قسم ، بكل سماته ، وإخفاء كل هذه السمات من المستخدم ، وحفظها من أي ارتباك محتمل ، أو يمكن للموضوع أن يعرض فقط الأشياء التي يريد المستخدم أن يتمكن من تعديلها (على سبيل المثال ، تم اختيار صورة الخلفية الفعلية). يمكن أيضًا إضافة السمات أو المكونات الإضافية مجانًا باستخدام ورقة الأنماط الخاصة بهم لتحديد أنواع الأقسام ... في الواقع ، من الناحية النظرية ، يمكن أن يتجاهل كل مربعات المفتش الخاصة بي ، ويخفي جميع لوحات المفتشين عن المستخدم ، ويصمم الأشياء بالكامل باستخدام أوراقهم. ومع ذلك ، فإن ذلك يزيل إمكانية بقاء المستخدمين على قيد الحياة في حركة موضوع مع بقاء أقسامهم سليمة.

اعتبارات المستخدم
بافتراض أن السمة لعبت بشكل جيد واستخدمت المسارات المختلفة المتاحة داخل الكتلة الخاصة بي لتحديد قسم وخصائصه "بشكل صحيح" ، إذا تم تغيير السمة ، فإن كل هذه السمات ستبقى ، وإذا كان الموضوع قد أخفيها من قبل المستخدم ، إعادة يتعرض. هذا لأن الخيار الأفضل في محدد "القسم المصمم مسبقًا" هو "مخصص" ، والذي يسمح للمستخدم بتعديل كل شيء ، وهو ما ستفترضه الكتلة بشكل افتراضي إذا لم يعد النمط المختار مسبقًا متاحًا. ستظل جميع الإعدادات التي أجراها السمة والتي لم تكن اختيارات ورقة أنماط مباشرة موجودة.

هذا لا يضمن بقاء القسم الخاص بك بطريقة تبدو جيدة (ربما كان لديك سمة ذات تخطيط عريض للغاية وانتقل إلى قسم ذي تخطيط ضيق ، لذلك قد لا يكون القسم المكون من ستة أعمدة هو الخيار الأفضل ... لكنه سيظل سليماً. يمكن للمستخدمين حفظ هذا التخطيط ككتلة قابلة لإعادة الاستخدام.

عند اختيار أنماط القسم ، إذا انتقلت من قسم محدد مسبقًا إلى قسم مخصص ، تتبع سمات مفتش القسم المحددة مسبقًا ، لذلك فهي طريقة للمستخدمين لتعديل قسم محدد مسبقًا دون الحاجة إلى تعديل تعريف هذا القسم في السمة أو توصيل في.

قضايا جوتنبرج
لذلك ، يقوم جوتنبرج بما يلي بشكل سيئ:

• الكتل التي يلزم تجميعها معًا عموديًا ، والتي قد تحتاج إلى تصوير أقسام في بعض الأحيان.
• أي نوع من المكالمات لعرض شيء مرن أو شبكة. بسبب حساء div للمحرر ، يجب عليك إلغاء ضبط استدعاء CSS إلى grid أو flex على غلاف innerblocks وإعادة تعيينه على إحدى كتل المحرر.
• محاذاة لليسار ومحاذاة لليمين. لقد قدمت خطأً حول هذا ، ولكن نظرًا لأن Gutenberg لا يقصر تعويم كتلة يسرى أو يمين على الطفل المباشر للكتلة التي لها سمة البيانات لليسار أو اليمين (أو المركز) ، يتم تعويم جميع الكتل المتداخلة اللاحقة إلى اليسار أو حق.
• غالبًا ما تكون إضافة كتل جديدة لغزًا كاملاً حيث سيتم إدراجها ... تعتقد أنك في الجزء السفلي من القسم الخاص بك ، وتريد كتلة داخلية جديدة ، وبدلاً من ذلك سيقوم المحرر بإدراج واحدة في أسفل المستند
• لا يعمل نموذج السحب / الإفلات Gutenberg للكتل المتحركة بشكل موثوق مع الكتل التي يمكن أن يكون لها وضع أفقي

جربها
سأقوم بنشر رابط في هذا الموضوع عندما أسقط نسخة على جيثب أعتقد أنها تستحق النظر ، إذا كان أي شخص مهتمًا. لقد أمضيت شهرين في هذا الأمر ، وربما لا يزال غير رائع ، لكنه شيء ما.

يجب أن أضيف أنني أؤمن بشدة أن أشياء مثل وجوه الخطوط وأحجام العناوين وما إلى ذلك ليست أشياء يجب أن يكون لكتلة القسم أي رأي بشأنها مباشرة. سمات المفتش التي أضعها أشعر بها مثل الأساسيات اللازمة للحفاظ على سمات "الصورة الكبيرة" لقسم من موضوع إلى موضوع ، أو لمنع إزالة المكون الإضافي من التلاعب بشكل كامل بمظهر الموقع.

rogerlos يجب أن تفكر في إلقاء نظرة على Kadence Blocks . يبدو أنهم يتعاملون مع الأعمدة المستندة إلى flexbox بشكل جيد.

يجب أن أضيف أنني أؤمن بشدة أن أشياء مثل وجوه الخطوط وأحجام العناوين وما إلى ذلك ليست أشياء يجب أن يكون لكتلة القسم أي رأي بشأنها مباشرة.

انا موافق تماما على ذلك. قد يكون الاستثناء الوحيد هو إعداد "لون الخط" على مستوى القسم. يعد هذا ضروريًا لأن الموقع الذي تكون خطوطه مظلمة بشكل أساسي لن تتباين بدرجة كافية داخل قسم يحتوي على صورة / تراكب خلفية داكنة.

إليك عرض توضيحي لكيفية إعادة استخدام مجموعة تخطيط الصف في Kadence لـ "أوضاع المحاذاة" في شريط أدوات الكتلة للسماح بثلاثة عروض مختلفة للمحتوى الداخلي ، وعرض عمود قابل للتعديل ، وهوامش صف أعلى / أسفل قابلة للتعديل ، بالإضافة إلى إعدادات لون الخلفية والنص.

تعد إعدادات "الحد الأقصى للعرض في قسم المحتوى" هي الأنماط المتكررة الوحيدة عالميًا (وبالتالي محددة الموضوع) التي تحتاج كتلة القسم إلى حسابها (بخلاف قيود المكونات الموروثة عالميًا ، مثل ألوان الخط المسموح بها وأحجام هامش الأعمدة وما إلى ذلك )

قادمًا من تجربة وكالة الويب ، لا يوجد أكثر من ثلاثة عروض مختلفة لأقسام المحتوى في أي تصميم تلقيته. يميل أي شيء خارج هذه العروض الثلاثة إلى أن يكون تنوعًا خاصًا بالمحتوى ينفصل عن قصد عن أنماط تصميم السمة بطريقة غير متكررة.

ستوجه كتلة القسم الجيدة المستخدمين نحو الإعدادات الافتراضية المحددة للموضوع (باتباع أنماط التصميم الأصلي) ، ولكن تسمح لهم أحيانًا بالانفصال عن تلك الأنماط بطريقة معقولة.

من أجل فرض تخطيط متسق وقابل للتنبؤ عبر جميع أحجام الشاشات ، لا يُسمح بأي كتل "نصية" على مستوى الجذر في إعدادنا.

يجب تضمين جميع الكتل التي لا تحتوي على صورة / تضمين في "قسم" (تخطيط صف Kadence) على مستوى الجذر ، والذي يفرض عرض قسم محتوى القالب الخاص بنا ، مع السماح للصفوف القابلة للتخصيص بالكامل مع أي عدد من الأعمدة بالإضافة إلى الخلفية ذات العرض الكامل خيارات ، إلخ.

يجب أن تسمح عناصر الحاوية أيضًا بعناصر الطبقة للتكديس (z-index).
يسمح هذا ، على سبيل المثال ، باستخدام عنصر فيديو أو شريط تمرير كخلفية أو تأثير اختلاف المنظر.

strarsis فكرة جيدة.

من الناحية المثالية ، قد تستخدم كتلة القسم الفهرس z لتوفير وضع تحرير للأمام / الخلفية قابل للتبديل.

بهذه الطريقة ، لا يقوم قسم القسم نفسه بإعادة اختراع صورة الخلفية / عناصر التراكب ، والتي تتوفر جميعها في كتلة صورة الغلاف المضمنة.

سيكون محتوى الخلفية غير مقيد بالعرض وبالتالي يجب أن يكون لدى مطوري السمات القدرة على تحديد الكتل التي يمكن أن تدخل في خلفية القسم. سيتم تقييد عرض المحتوى الأمامي على عدد معين من العروض القصوى التي يوفرها الموضوع.

إذا احتاج المستخدم إلى الابتعاد عن العرض الافتراضي نظرًا لجزء معين من المحتوى ، فيمكنه اختيار قسم به العرض الأكبر التالي ووضع الجوانب وفقًا لذلك.

يجب تسجيل المثيلات التي يحتاج فيها المحتوى الأمامي إلى قطع بصريًا خارج أقصى عرض للقسم كتنوع نمط يضبط الهامش السلبي على تلك الكتلة المحددة.

والسبب في ذلك هو أنه في حين أن المستخدمين سيكونون آمنين جدًا عند ضبط قيم الحشو ، فإننا بالتأكيد لا نريد أن تكون الهوامش السالبة شيئًا يحدده المستخدم.

إن السماح بتعريف الهوامش السلبية في المحرر سيكون بمثابة فوضى عند الاستجابة لأحجام مختلفة للشاشة ، وحشوات جانبية لقسم المحتوى ، وعرض الحضيض عند نقاط توقف معينة ، وما إلى ذلك ، وبالتالي يجب أن يقترن بإحكام مع السمة / الكود وأن يُكشف على أنه تجريدات ذات مستوى أعلى للمستخدم النهائي.

فيما يتعلق بالتحكم المطوِّر: هناك المكوِّن الإضافي Mesh الذي يوفر حاويات "صلبة" ،
التي يجب أن يفرضها الموضوع.
يجب أن يقيد النسق أحيانًا المناطق المتاحة ، مثل الزاوية اليسرى العليا فقط من الصفحة بأكملها.
يجب أن يوفر Gutenberg آلية للقوالب لتعيين هذه الحاويات "الصلبة" داخل محرر الصفحة.

strarsis في رأيي ، أي شيء يحدث خارج منطقة the_content() ليس له عمل داخل محرر Gutenberg.

هذه "المناطق" هي جزء من قالب الصفحة وليست من محتوى الصفحة ويجب التعامل معها في مكان آخر.

محتوى الصفحة مقابل قالب الصفحة (/ تخطيط)

يجب أن يفترض المحتوى / الأقسام الموجودة داخل المحرر أن التخطيط المحيط غير موجود (أثناء التحرير) ، وبدلاً من ذلك يكون مجهزًا للاستجابة بشكل مناسب عند وضعه داخل تخطيط معين (في الواجهة الأمامية).

يعتبر العنصر جزءًا من قالب الصفحة ( وليس محتوى الصفحة ) ، إذا:

1. يحدد العنصر أو يعتمد على بنية أو حدود أو موضع منطقة the_content() ككل ، و
2. العنصر جزء من نمط متكرر (أي يمكن رؤيته في اثنين أو أكثر من الروابط الثابتة)

بعض الخلفية القائمة على الخبرة

عادةً ما تكون عناصر القالب / التخطيط المكررة خاصة بنوع منشور مخصص وتتضمن أبطال المحتوى والأشرطة الجانبية للمحتوى وتذييلات المحتوى.

في كل حالة على حدة ، وجدت أن المحتوى داخل عناصر التخطيط هذه مشتق بشكل كافٍ من المعلومات الموجودة في الحقول المخصصة أو التصنيفات أو الإعدادات الأخرى الموجودة على مستوى النشر وليس على مستوى الكتلة.

وفي كل حالة على حدة ، عززت اعتقادي بأنه سيكون مهمة لا تصدق لإجراء تعديل جماعي أو إعادة تصميم هذه الأقسام لو تم تنفيذها ككتل داخل محرر جوتنبرج.

حتى النهاية

يجب أن يمتد تعريف القسم (والتنفيذ النهائي) إلى حد كافٍ فقط للتعامل مع احتياجات أنماط تصميم السمة لأنها تتعلق بـ the_content() .

يجب التعامل مع أي شيء يندرج تحت "قالب" وليس "محتوى" خارج أي كتلة قسم وخارج محرر Gutenberg (في الوقت الحالي).

أريد أن يكون Gutenberg قادرًا على عمل قوالب مضمنة مع المحتوى تمامًا مثل أي شخص آخر ، ولكن لا يبدو أننا موجودون هناك حتى الآن ، ويجب علينا بالتأكيد تثبيت كتلة القسم هذه قبل أن نتمكن من التعامل مع القوالب بشكل مناسب.

قبل يومين كنت أرغب في إنشاء تخطيط أساسي واحتجت إلى ذلك. لذلك بدأت بتثبيت البرنامج المساعد أ ، وجربته ، وكان عربات التي تجرها الدواب. تم إلغاء التثبيت ، تم العثور على المكون الإضافي B ، مثبتًا ، جرب كتلة القسم الخاص به ، كان baaad. المكوّن الإضافي التالي C buggy ، أطلق عليه الملحق D اسم حاوية وكان meh. الإضافة التالية E، F .........
يمكنني أن أؤكد لكم أن "النظام البيئي" الحالي لـ Gutenberg محبط للغاية ، إذا كنت تريد إنشاء صفحة وكتابة محتوى.
حقيقة أن الناس هنا يستمرون في قول "انظر إلى المكون الإضافي X" ، "إذا كنت تريد هذا المكون الإضافي لتثبيت الميزة Y" وما إلى ذلك هو مؤشر واضح على أن الناس بحاجة إلى هذا. إنهم لا يريدون ذلك ، إنهم بحاجة إليه. يوجد الآن عشرات المكونات الإضافية مع تنفيذها الخاص للحاوية / القسم / أيًا كان ما تريده.
أنا لا أقول إن على جوتنبرج أن يضيف كل ميزة تحت الشمس ، لكن هذه ميزة أساسية. يجب أن يكون هناك. لا يحتاج إلى أن يكون لديه كل خيار يمكن تصوره ، ولكن يجب أن تكون الأساسيات موجودة ويمكن للمطورين التوسع إذا لزم الأمر.
لقد وصلنا إلى نقطة حيث سيكون هناك 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 ، والمنظر الخ ...) يجب أن يتم باستخدام الإضافات imo.

ويرجى إضافة وسيلة للموضوع (المطورين) للتحكم في عدد وأغلفة الأغلفة المستخدمة.
تحتاج بعض التصميمات إلى أكثر من عنصر واحد فقط. في الوقت الحالي ، يتعين علي استخدام مكون إضافي آخر لعنصر حاوية ثم تحليل المحتوى بالكامل باستخدام محلل PHP لتغليف محتويات الحاوية في عناصر غلاف إضافية للتصميم.

strarsis هذا بالتأكيد شيء كان يجب القيام به منذ البداية.

من أجل القيام بأي تصميم لائق لمحتوى المنشور ، يجب وضع كل طفل على مستوى الجذر في صف / قسم ثابت.

على سبيل المثال ، من دون التفاف كل صف ، من الصعب ومن الصعب عمل أقسام ذات عروض مختلفة (خاصة أقسام العرض الكامل).

لقد فكرت أيضًا في خيار تحليل PHP ، لكنني أدركت أنه لا يمنح محرر المحتوى أي تحكم في نوع القسم الموجود فيه جزء معين من المحتوى.

بدلاً من ذلك ، في الإعداد الخاص بنا ، نجبر جميع مثيلات محرر Gutenberg على السماح فقط بكتلة حاوية واحدة على مستوى الجذر لأي منشور / صفحة / نوع منشور.

تفرض كتلة حاوية الجذر مجموعة فرعية محدودة من الكتل التي يمكن إضافتها داخلها.

من أجل إضافة أي نص أو كتل غير كاملة العرض ، يلزمك أولاً إدراج تخطيط صف Kadence ، والذي يعمل في هذه الحالة كعنصر غلاف للقسم الرئيسي.

كتلة الحاوية البسيطة القابلة للتمديد هي كل ما يجب أن يكون مطلوبًا داخل اللب. يجب ترك تمديد هذه الكتلة فيما يتعلق بالتصميم لمطوري المكونات الإضافية / السمات. يجب أن يوفر أيضًا حالة تحويل احتياطي للمطورين الذين يرغبون في بناء كتل الحاويات الخاصة بهم.

تخضع جميع المكونات الإضافية الحالية للجهات الخارجية التي توفر الحاويات / الأقسام / الصفوف التي اختبرتها لمشكلة كبيرة فيما يتعلق بقفل المحتوى. عند إلغاء تنشيط هذه المكونات الإضافية ، لم يعد يمكن الوصول إلى محتوى الكتلة الداخلية من داخل المحرر وتحويلها يزيل HTML. شيء يجب أن يكون المستخدمون على دراية كاملة به.

نرى:
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

حسنا. لقد اختبرت Gutengerg ، إنه جيد ، لكن نعم ، إنه بالتأكيد يفتقر إلى قسم القسم.
لكي تكون صحيحًا ، تحتوي الكثير من الكتل على حاوياتها التي يمكننا إضافة فئة css إليها ونمطها. لكن المحتوى الرئيسي مكتوب بدون حاوية ، لذلك ولا أي فئة ، وبالتالي لا يمكننا تصميمه. ونظرًا لأن المحتوى الرئيسي مكتوب في نفس المرحلة مثل جميع الكتل الأخرى ، فإن هذا يجعل من الصعب للغاية وضعه بشكل مختلف عن الكتل الأخرى.

بمعنى آخر ، سأعود إلى الكلاسيكية وانتظر حتى تعطينا الأقسام.

شكرا لك تحياتي.

نعم ، هذا صحيح تمامًا. أعتقد أنه أكثر أهمية من جميع الكتل الأخرى التي يتم تطويرها حاليًا. youknowriad ألا يمكنك إعطائها أولوية أكبر؟

إنه موجود بالفعل في نطاق المرحلة 2 https://github.com/WordPress/gutenberg/issues/13113 إذا كان هناك شخص ما على استعداد للتجربة ، فيرجى القيام بذلك.

youknowriad أخشى أنني لست مطورًا. لكنني أتذكر أن التطوير كان قيد التقدم بالفعل. قبل وقت قصير من إصدار Wordpress 5 ، كان هناك علاقات عامة متقدمة جدًا بالفعل. لا تزال هناك تفاصيل تحتاج إلى توضيح ، لكنها كانت جاهزة تقريبًا. للأسف لا يمكنني العثور على العلاقات العامة بعد الآن. هل لدى أي شخص فكرة أين هذا؟

نعم ، لا تقلق فهمت.

ها هي العلاقات العامة. https://github.com/WordPress/gutenberg/pull/10562

أردت أن أوضح أنه مشروع مفتوح المصدر ويعتمد على التطوع. يمكنني إعطاء اتجاه عالمي ، طلب المساعدة ولكن لا يمكنني تعيين أشخاص. يميل الناس إلى التفكير بطريقة أخرى.

أكرر أنه إذا كان هناك مطورون يرغبون في رؤية هذا يحدث بسرعة أكبر ويرغبون في المساعدة ، فنحن نرحب بهم في الاجتماعات الأسبوعية في قناة Core Slack # core-editor (والاجتماعات) ومناقشة / تعاون / طلب المساعدة.

آه نعم هذا كل شيء! عظيم! لديك نظرة عامة !!!

نعم ، هذا صحيح ولا ينبغي أن يكون عتابًا. ما سألته لنفسي ببساطة: ألا توجد مهام أكثر أهمية وأكثر أهمية؟ إذا احتاج 50 شخصًا إلى كتلة RSS ، ولكن احتاج 1000 شخص إلى كتلة حاوية ، فمن المنطقي التركيز على الأمر برمته بشكل أكثر تحديدًا. كتلة الحاوية ليست غريبة الآن. أعتقد أن هذا هو _ الأساس لكل تصميم_.

من فضلك لا تسيء الفهم: أنت تقوم بعمل رائع. وأنت بصفتك قائد المرحلة الثانية تقوم بعمل من الدرجة الأولى. الأمر كله يتعلق بمسألة التركيز. سأخبز ذلك في محادثة Slack التالية ... ؛-)

شكرا جزيلا مرة أخرى!

شكرا وسعداء للتوضيح. أعطيهم شخصيًا نفس الأهمية. الخطوة الوسيطة للمرحلة 2 هي استخدام الكتل في شاشة الأدوات. لذا حتى إذا لم يطلب الأشخاص كتلة RSS ، فبمجرد أن تستخدم شاشة الأدوات (وهي خطوة مهمة للمرحلة 2) الكتل ، إذا لم يجد الأشخاص أداة RSS التي اعتادوا استخدامها ، يشكو منه.

هاتان المهمتان مهمتان "متوسطتان" من حيث التعقيد ، وهما سمة مهمة من حيث الحكمة ، لكنهما ليسا مهمين من حيث الإطار. إن أولويتي الشخصية العالية في الوقت الحالي هي أشياء إطار العمل التي من شأنها تمكين أهداف المرحلة 2 (الكتل في شاشة الأدوات ، والمحرر خارج post_content) لأن هذه المشكلات المتعلقة بالتواصل مهمة للتجربة والتوضيح عاجلاً وليس آجلاً.

حسنا. لقد اختبرت Gutengerg ، إنه جيد ، لكن نعم ، إنه بالتأكيد يفتقر إلى قسم القسم.
لكي تكون صحيحًا ، تحتوي الكثير من الكتل على حاوياتها التي يمكننا إضافة فئة css إليها ونمطها. لكن المحتوى الرئيسي مكتوب بدون حاوية ، لذلك ولا أي فئة ، وبالتالي لا يمكننا تصميمه. ونظرًا لأن المحتوى الرئيسي مكتوب في نفس المرحلة مثل جميع الكتل الأخرى ، فإن هذا يجعل من الصعب للغاية وضعه بشكل مختلف عن الكتل الأخرى.

بمعنى آخر ، سأعود إلى الكلاسيكية وانتظر حتى تعطينا الأقسام.

شكرا لك تحياتي.

هذا هو الموقف الذي أتخذه بشأن هذا وأوجه القصور الأخرى في محرر الكتلة الجديد حتى يتشكل. نأمل أن يحدث هذا لأن هناك بعض الجوانب الجيدة للمحرر الجديد.

ستكون كتلة القسم رائعة ، ما الذي يمكنني فعله للمساعدة على الرغم من أنني أفتقر إلى مهارات تطوير الخلفية.

هناك الكثير من المكونات الإضافية للكتل الآن ، ولكن الكتلة الوحيدة منها التي أريدها هي قسم أو كتلة حاوية ، لذا أود أن أرى واحدة مضافة.

يحتاج WordPress الأساسي إلى تضمين تنفيذه الخاص بهيكل تخطيط القسم والصف والأعمدة لمحرر الكتلة ، وهو أمر قياسي ويمكن استخدامه بواسطة جميع المكونات الإضافية والقوالب وبناة الصفحات. يجب توفير واجهة برمجة التطبيقات ، كما ذكرت عدة مرات من قبل ، حتى يتمكن هؤلاء من إضافة واجهاتهم وأجراسهم وصفاراتهم. قم بإيقاف تشغيل أي من حلول الجهات الخارجية هذه وستظل بنية صفحتك كما هي.

نظرًا لوجود حلول تابعة لجهات خارجية للأقسام / الصفوف القادمة من جميع الاتجاهات ، ولكن بمجرد بدء الاختلاط في الكتل الأساسية الأصلية وكتل الطرف الثالث ، تبدأ في رؤية العديد من التناقضات والكتل التي تتعطل وتحتاج إلى حل. لا يعني ذلك أنني أريد انتقاد جهود أولئك الذين يقدمون هذه الحلول للتخطيط ، فهم يملئون ميزة تشتد الحاجة إليها. الكثير منهم جيد لكن شيئًا ما ليس صحيحًا تمامًا بشأن التجربة الكلية.

أنا أؤيد جميعًا الحفاظ على محرر الكتلة الأساسية بسيطًا ، مما يسمح للأطراف الثالثة بإضافة وظائف إضافية وتطور ، ولكن يجب بالفعل تشديدها ، وإلا فإن الحصول على بعض الجر على قبولها لن يتحقق بسهولة بالغة.

السؤال الكبير هنا هو من يعتني بها. ألا يوجد عدد قليل من المطورين الذين لديهم الوقت والطاقة للقيام بذلك؟

نعم نعم نعم! أعتقد أن كتلة المقطع المرنة هي أكبر ميزة مفقودة من Gutenberg.

لا أستطيع حتى أن أصدق أنه غير موجود بعد ...

سيكون البديل هو السماح لكتلة الأعمدة بأن يكون لها عمود واحد فقط والسماح أيضًا بتعيين ألوان الخلفية للأعمدة. TA-DA: كتلة القسم.

حسنًا ، إذا كان ذلك يساعد أي شخص: لقد كتبنا قسمًا Block لمشاريعنا منذ بعض الوقت. أنا متأكد من أنه يمكن تجميلها في بعض النقاط ، لكنها قد تكون نقطة انطلاق جيدة:

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;
}

talldan هل تمانع في إلقاء نظرة على هذه المشكلة - سيكون من الجيد الحصول على
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

ستكون كتل الأقسام رائعة ، لكن من فضلك اجعلها ترميزًا دلاليًا فقط! قد يؤدي الاحتفاظ بالأشياء في بنية HTML الدلالية إلى إنشاء قاعدة التعليمات البرمجية الأكثر حيادًا.
<section>, <article>, <header> أفضل طريقة <div class="wp-section"> أو أيًا كان.

talldan آسف لقد فاتني تعليقك ، لكنني موافق 100٪ على قيامك بهذا الأمر 🙌 أنا متأكد من أنك ستهزّه!

سيكون من الرائع أيضًا أن تكون قادرًا على استخدام النقطة المحورية في كتلة النص والوسائط # 10925. بالطبع هذا منطقي فقط إذا كان لديك خلفية صورة.

شيء رائع ، بالمناسبة ، يمتلكه أيضًا الكثير من منشئي الصفحات. أو على الأقل شيء من هذا القبيل:

تم الاتفاق على أن منتقي نقطة الاتصال سيكون رائعًا هنا. إنه يعمل بشكل جيد في قالب الغطاء!

مع وضع ذلك في الاعتبار ، قمت بتحديث نماذجي السابقة بالأحجام الطبيعية لكتلة قسم. إنه يعمل فقط كعنصر حاوية مع لون وصورة خلفية قابلين للتعديل.

معاينة :

يمكنك التحقق من النموذج الأولي هنا .

بعض الملاحظات الإضافية:

• أعتقد أننا يجب أن نطلقه بدون صورة الخلفية للبدء ، فقط لون الخلفية / النص. بمجرد دفع ذلك ، يمكننا بناء صورة الخلفية بعد ذلك. هذا يخرجها بسرعة ، باستخدام الأنماط الحالية ، ويجب أن تظل تغطي عددًا كبيرًا من حالات الاستخدام.
  
  
  
  • بمجرد دمج الإصدار الأول ، من المحتمل أن نهمل لون الخلفية والنص من كتلة النص. بدلاً من ذلك ، يمكن أن يكون لدينا خيارات ألوان مضمنة / خيارات تمييز في كتلة الفقرة. يبدو أن هذا نمط أفضل بشكل عام للفقرة.
  
  
• لن تحتوي هذه الكتلة على أي إعدادات سريعة الاستجابة ، لأنها ستكون دائمًا مجرد حاوية. سيوفر المحتوى الموجود داخل الحاوية (مثل كتلة العمود) السلوك سريع الاستجابة.

أوافق ، يمكن إضافة صورة الخلفية باستخدام css إذا لزم الأمر في الوقت الحالي: +1:

بمجرد دمج الإصدار الأول ، من المحتمل أن نهمل لون الخلفية والنص من كتلة النص. بدلاً من ذلك ، يمكن أن يكون لدينا خيارات ألوان مضمنة / خيارات تمييز في كتلة الفقرة. يبدو أن هذا نمط أفضل بشكل عام للفقرة.

أحد أسباب اعتبار القسم هو المكان المناسب لألوان مستوى الكتلة هو أنه بخلاف ذلك يتعين علينا الإجابة عن سبب عدم توفر خيارات الألوان هذه في القائمة والعنوان وكتل النص الأساسية الأخرى. ونظرًا لأن هذه العناصر مقسمة على مستوى الكتلة ، فلن تتمكن أبدًا من الحصول على صورة خلفية تغطي كل هؤلاء بشكل مستمر ، بينما تعمل كتلة القسم على إصلاح ذلك.

من المحتمل أن تكون طريقة إهمال هذه الألوان هي إزالة واجهة المستخدم الخاصة بها فقط ، ولكن دع الكتل الحالية تظل كما هي.

لطيف! سيكون من المفيد وجود فئات صغيرة / متوسطة / كبيرة للحشو الرأسي.

لطيف! سيكون من المفيد وجود فئات صغيرة / متوسطة / كبيرة للحشو الرأسي.

يتراجع هذا إلى مستوى المظهر / الإطار ، ولست متأكدًا مما إذا كان Core له مكان لأي شيء مثل https://cdn.vaadin.com/vaadin-lumo-styles/1.4.1/demo/sizing-and-spacing .لغة البرمجة

أعتقد أننا يجب أن نطلقه بدون صورة الخلفية للبدء

لا يمكن أن نتفق أكثر. احصل على v1 out ثم v2 يمكن أن يضيف وظائف أكثر تعقيدًا.

لن يحتوي هذا الحظر على أي إعدادات سريعة الاستجابة

متفق عليه - يجب أن تكون هذه المجموعة بسيطة وغير معلن عنها قدر الإمكان.

أعتقد أننا يجب أن ندمج هذا العلاقات العامة إن أمكن.

لقد تعرضت لضربة في شيء كهذا ... تم إصداره كمكوِّن إضافي:

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

من فضلك ، لا مزيد من المكونات الإضافية التي ستترك الناس يعتمدون عليها. فقط حرر الكتلة اللعينة بالفعل.

webdados أنا ثاني هذا.

لا للتقليل من عمل أي شخص ، لكننا نحتاج حقًا إلى أن يكون هذا مدمجًا على مستوى ما.

خاصة في عالم توجد فيه هذه المشكلة .

إذا تم العثور على حل مناسب لـ # 13391 ، فمن المحتمل أن يكون وجود عدد لا يحصى من تطبيقات كتلة الحاوية أمرًا جيدًا.

إلى أن يتصدى مُنشئ الكتل الجديد لوجود أساس قياسي لعناصر التخطيط (الحاويات ، والأقسام ، وأعمدة الصفوف) التي يمكن أن تمتد إضافات الطرف الثالث ، فلن يكون هناك أي شيء ويؤدي إلى استمرار فوضى تشغيل وإيقاف كتل الجهات الخارجية والسمات والبناة ( أولئك الذين يحاولون معالجة مشكلة التنسيق) وينتهي بهم الأمر بفقدان المحتوى وتخطيط الصفحة.

متى نتوقع هذه الميزة؟

يجب أن يكون بالفعل في أحدث إصدار:
https://github.com/WordPress/gutenberg/releases/tag/v5.5.0

ksere : فاتني ذلك ربما لأن سجل التغيير للإصدار v5.5.0 من البرنامج المساعد فارغ .

حقا حفر التنفيذ على هذا حتى الآن. أفهم أنه تم إصداره للتو في الإصدار 5.5 ، لكنني أتساءل متى نتوقع إضافات لصور الخلفية (وتحديد موضعها) ، وشفافية لون الخلفية ، وما إلى ذلك. هل هذا شيء يجب أن نتوقعه قبل أواخر عام 2019 ، أم أننا نتحدث لفترة أطول -مدة من ذلك؟

nathansnelgrove شكرًا على ملاحظاتك. هناك بالتأكيد بعض التحسينات القادمة على مجموعة المجموعة ، وهنا اثنان قيد التقدم بالفعل:

• إضافة حاوية داخلية لتسهيل التصفيف - https://github.com/WordPress/gutenberg/pull/15210
• إضافة خيارات محرر لتجميع / فك تجميع مجموعة مختارة من الكتل - https://github.com/WordPress/gutenberg/pull/14908

لم أر المشكلات التي ذكرتها حول صور الخلفية والتعتيم الذي يتم تتبعه في أي مكان ، فقد يكون من المفيد إنشاء مشكلة منفصلة لذلك إذا كان لديك الوقت لأن هذه المشكلة مغلقة الآن.

صور الخلفية / الألوان / التعتيم من الاقتراح الأصلي - سأقوم بإصدار مشكلة جديدة لهم.

لقد قمت للتو بتثبيت WordPress 5.2.4 ، ولا يمكنني العثور على أي كتلة "قسم" أو "مجموعة". ماذا يحدث هنا؟

patrikhuber : سيتم تضمين هذا في WordPress 5.3 والذي من المقرر حاليًا إصداره في 12 نوفمبر.

noisysocks أرى ، شكرًا جزيلاً!