Gutenberg: Block hinzufügen: Abschnitt

Diese Idee gefällt mir sehr gut! Ich mag auch die Tatsache, dass es eine Hintergrundeinstellung hat.

Nett! Was ist, wenn der Block die drei folgenden "erweiterten" Einstellungen zulässt:

• Definieren Sie einen Klassennamen, der auf die untergeordneten .child_class, .child_class_1 serialisiert werden soll
• Fügen Sie eine optionale erste untergeordnete Klasse .child_class, .child_class_1, .child_class_first
• Fügen Sie eine optionale letzte untergeordnete Klasse .child_class, .child_class_n, .child_class_last

:nth-child Selektoren können möglicherweise die letzten beiden kompensieren, aber ich denke, dass das Hinzufügen einer Klasse zu allen Kindern in bestimmten Kontexten nützlich sein kann.

Ich liebe diese Idee. Wenn Hintergrund- und Textfarben geändert werden können, ist es möglicherweise sinnvoll, auch Linkfarben hinzuzufügen.

Exzellente Idee. Dies wird dem Gutenberg Editor buchstäblich viel Wert verleihen.

Viel besser als nur der Spaltenblock, der viele Probleme hat. Cool!

Dies ist das erste, was ich erstellen wollte, als ich sah, dass Verschachtelung verfügbar war. Meine Version ist ähnlich, außer dass ich mir vorgestellt habe, dass Sie den Spaltenblock hinzufügen würden.

Haben Sie Code dafür zur Verfügung?

Wenn dieser Block "Spalten" hat, sollten wir nur den Block "Spalten" aktualisieren. Es ist jedoch weiterhin möglich, einen Spaltenblock innerhalb eines Abschnittsblocks zu verwenden und den Abschnittsblock spaltenlos zu halten.

Solange Sie keine Spaltenblöcke in Spaltenblöcke einfügen können 😉

Viele Websiteseiten sind in Abschnitte unterteilt, die gemischten Inhalt mit mehreren Spaltenzeilen und häufig in größeren Spalten verschachtelten Spalten enthalten. Dies ist ein kurzes Beispiel:

Ein Abschnittsblock, der sich wie ein nackter Wrapper verhält, wäre meiner Meinung nach am flexibelsten. (als würde man Spaltenblöcke verschachteln können!)

Wir haben diese Woche ein neues Site-Projekt gestartet. Normalerweise wird es mit flexiblen Inhaltslayouts für erweiterte benutzerdefinierte Felder erstellt, aber ich werde sehen, wie weit wir mit Gutenberg allein kommen können.

Ja, ich denke, mehrspaltige Abschnitte wie das obige Beispiel von @jvisick sind keine Seltenheit. Ein Container mit Hintergrund- / Textoptionen, der Blöcke verschachtelt, wäre der flexibelste Ansatz. Da wir jetzt einen funktionierenden Spaltenblock haben, könnten wir sogar in Betracht ziehen, die Spaltenoption daraus zu entfernen.

Es wäre großartig, wenn sich in diesem Block ein innerer Container (div) befindet, der dann alle untergeordneten Blöcke enthält. Dieser Container könnte dann mit maximaler Breite und Rand-Links / Rechts gestaltet werden: Auto, um die untergeordneten Blöcke zu zentrieren und einen Hintergrund in voller Breite zu haben.

Ein Abschnitt mit voller Breite, dessen Inhalt in einem engeren Layout enthalten ist, ist ein gängiges Entwurfsmuster. Ich frage mich, ob es am besten von den verschachtelten Blöcken gesteuert werden kann, anstatt in den übergeordneten Abschnittsblock eingebrannt zu werden.

Ich denke, ein Abschnittsblock wäre sehr nützlich für ... nun, Abschnitte auf einer Seite, und ich stimme zu, dass Spalten ein separater Block sein sollten (wie der jetzt existierende), der in einem Abschnittsblock verschachtelt werden kann. Ich denke, dies sollte zusammen mit dem Columns-Block in der Version von Gutenberg enthalten sein, die in WordPress 5.0 zusammengeführt wird. Wenn Sie sich vorhandene Plugins für den Seitenersteller ansehen, werden Abschnitte häufig verwendet, ebenso wie Spalten (offensichtlich). Daher ist es meiner Meinung nach wichtig, sie in die erste Kernversion aufzunehmen.

(Ich denke auch, dass es wichtig ist, dass der Spaltenblock Funktionen wie Spalten mit variabler Breite und reaktionsfähige Spalten erhält, sowohl aus Gründen der Kernerfahrung als auch um es bestehenden Seitenerstellern zu erleichtern, sich auf Gutenberg zu stützen, aber das ist ein separates Thema.)

Nachdem ich noch etwas darüber nachgedacht habe, denke ich, dass es sinnvoller wäre, wenn nur der Block "Abschnitt" und "Spalten" dasselbe wäre. Fügen Sie einfach die Möglichkeit hinzu, nur eine Spalte im Spaltenblock zu haben, anstatt mindestens zwei. Fügen Sie dann die Hintergrundeinstellungen dieses vorgeschlagenen Abschnittsblocks zum Spaltenblock hinzu.

Ich denke, ein einzelner Abschnitt / Spalten-Block würde die Verschachtelung reduzieren, die Sie durchführen müssten. Im Moment ist der vorgeschlagene Abschnittsblock wirklich nichts anderes als ein Bereich mit Hintergrund- und Breitenoptionen. Beide könnten dem Spaltenblock hinzugefügt werden, und wenn der Spaltenblock nur eine Spalte enthalten würde, wäre kein Abschnittsblock erforderlich.

Wenn Sie einen Abschnitt voller Breite mit Standardbreiteninhalt wünschen, können Sie dies erreichen, indem Sie entweder einen anderen Abschnitt- / Spaltenblock in einen anderen verschachteln, der auf volle Breite eingestellt ist. Mit einer Einstellung im Inspektor kann die Breite des Blockinhalts unabhängig von der Breite des gesamten Blocks geändert werden.; Dies kann auch als sichtbare Größenänderungshandles hinzugefügt werden, ähnlich wie Beaver Builder-Zeilen / -Spalten oder wie der Image-Block in Gutenberg funktioniert.

Was Sie diesen kombinierten Block nennen würden, denke ich, dass es funktioniert, nur den Namen "Columns" beizubehalten, da dies die offensichtlichste Funktion ist, nach der die Leute suchen würden. Es sollte nicht schwierig sein, die Hintergrundeinstellungen im Inspektor zu finden (und ich kann mir vorstellen, dass einige Leute dort sowieso zuerst suchen würden, wenn es einen separaten Abschnittsblock gäbe und sie sich dessen nicht bewusst wären) und die Spalten verwenden Block als einspaltiger Container sollte nicht schwer zu entdecken sein, da der Schieberegler zum Ändern der Anzahl der Spalten ziemlich offensichtlich machen sollte, wie es geht ... ziehen Sie ihn einfach ganz nach links.

Ich habe meine Meinung über das Zusammenführen der Blöcke "Abschnitt" und "Spalten" geändert. Um die größtmögliche Flexibilität bei Spalten zu erzielen, ist es am sinnvollsten, wenn jede Spalte ein eigener Block ist: ein Spaltenblock. Dies würde es ermöglichen, die Einstellungen einer einzelnen Spalte einfach zu steuern und eine Spalte von einer Zeile in eine andere zu ziehen. Da Spalten von links nach rechts verlaufen (und in den meisten Layoutsystemen umbrochen werden), muss der übergeordnete Block ein Inhalt sein, der Inhalte in dieser horizontalen Richtung einfügt und umbrochen wird (anstelle der vertikalen Standardrichtung) Der übergeordnete Block würde wahrscheinlich nur das Einfügen von Spaltenblöcken ermöglichen. Dieser Block wäre eine Zeile. Diese 2 Blöcke würden den Spaltenblock ersetzen. Sie decken jedoch nicht die Situation ab, in der sich mehrere Zeilen (häufig mit unterschiedlicher Anzahl von Spalten) im selben Hintergrund / Container befinden sollen, wie dies der Abschnittsblock tun würde. Natürlich wäre der Abschnittsblock nichts anderes als ein Container mit Hintergrund-, Auffüll- und Breitenoptionen, in den jeder Block eingefügt werden könnte. Bei komplexeren Layouts können Abschnittsblöcke in Spaltenblöcke eingefügt werden.

Siehe # 6461.

Ich denke tatsächlich, dass die Idee mit mindestens 1 Spalte keine schlechte Lösung ist. Wenn Sie mit Ihrem Inspektor das Attribut "min" des Schiebereglers in 1 ändern und eines auswählen, funktioniert es tatsächlich so, wie Sie es erwarten würden.

Semantisch gesehen ist ein Abschnittsblock jedoch sowieso sinnvoller. Der innere Inhalt (dh ein Abschnitt mit maximaler Breite innerhalb eines Abschnitts mit voller Breite) könnte erreicht werden, indem zwei Abschnitte verschachtelt werden - eine Inhaltsbreite innerhalb einer vollen Breite.

Die Idee mit der Hintergrundfarbe ist nett, aber ... vielleicht ein paar zwei spezifische. Ich denke, ein allgemeinerer Ansatz wäre, nur benutzerdefinierte Klassen für den Abschnitt zu verwenden. Das Front-End-CSS könnte das und alle Kinder direkt erfassen.

Nach einigen Diskussionen in # 6461 habe ich entschieden, dass meine Idee mit Zeilenblock + Spaltenblock nicht der richtige Weg ist. Ein Layoutblock ähnlich dem in # 5351 (Kommentar) wäre wahrscheinlich weitaus weniger verwirrend und weitaus flexibler. In jedem Fall sollte es definitiv einen Abschnittsblock geben, und ich denke, er sollte definitiv vor der Veröffentlichung von WordPress 5.0 hinzugefügt werden.

Was die Hintergrundfarben angeht, halte ich es für absolut sinnvoll, Hintergrundoptionen für einen Abschnitt zu haben. Nur Klassenoptionen zu haben, scheint ein bisschen restriktiv zu sein. Oft besteht der Sinn des Verschachtelns in einem Abschnittsblock darin, dass mehrere Dinge einen gemeinsamen Hintergrund haben. Außerdem würde ich es vorziehen, wenn andere Hintergrundoptionen wie Hintergrundbilder und Verlaufshintergründe implementiert würden, da diese häufig anstelle von einfarbigen Hintergründen gewünscht werden. Verschachtelte Abschnittsblöcke würden sogar das Anwenden von Hintergrundfarben auf einen einzelnen Block ermöglichen, was bedeutet, dass die Hintergrundfarbenoptionen im Absatzblock möglicherweise nicht mehr erforderlich sind.

Ich denke, dass das Verschachteln von Abschnittsblöcken anstelle von zwei separaten Breiteneinstellungen funktionieren könnte. Die größte Sorge, die ich hätte, ist die Menge an zusätzlicher Polsterung, die durch das Verschachteln von Abschnittsblöcken hinzugefügt würde, was zu Polsterungsoptionen führt.

Ich denke, es ist wichtig, dass der Abschnittsblock die Möglichkeit hat, die Menge der verwendeten Auffüllung anzupassen oder zumindest die Standardauffüllung zu entfernen. Dies wirft natürlich Fragen auf, wie Sie den Abschnittsblock auswählen würden, wenn ein anderer Block darin verschachtelt ist. Ich denke, dieses Problem wird durch Verbesserungen wie # 6471 und die Dinge, an denen in der try/alternate-hover-approach -Zweig gearbeitet wird, behoben.

: +1:

Wir brauchen wirklich einen generischen Zeilen- / Containerblock, insbesondere mit Breiteneinstellungen.

Im Idealfall sollten andere Einstellungen wie "Hintergrundfarbe" und "Textfarbe" in jedem Block unter einer Registerkarte " Zusätzliche

In Bezug auf die Reaktionsfähigkeit denke ich, dass wir einen "Responsive" -Block hinzufügen sollten.

Das Problem mit Hintergrundfarbe und Textfarbe ist einfach: Wo endet es? Bereits in diesem Thread gibt es jemanden, der eine Linkfarbe vorschlägt. Warum nicht Farbe, Dicke und Stil umrahmen? Polsterung und Rand sind am sinnvollsten, um ehrlich zu sein. Was ist mit Schlagschatten, Hintergrundbildern, Positionierungsoptionen und Anzeigemodi? Schriftstil und -größe, Zeilenhöhe und Mindesthöhe? Es gibt Hunderte von CSS-Eigenschaften, und welche Sie benötigen, hängt von Ihrem Design ab.

Es sollte entweder eine Klasse sein, mit der Sie dann alles formatieren

@tmdesigned Es endet mit der vollständigen und intuitiven WYSYWIG-Steuerung über Stil, Formatierung und Layout einer Webseite. Ist das nicht das Ziel von Gutenberg?

Gutenberg bietet der Welt einen frischen, gut geplanten, topaktuellen, vorlagen- und erweiterbaren Webinhalt WYSYWIG ... wir sollten herausfinden, wie viel wir das jetzt nutzen wollen, sonst werden wir das Boot verpassen.

Am Ende geht es darum, den Arbeitsaufwand zu reduzieren, unabhängig davon, ob wir CSS schreiben, hackige CSS-Überschreibungen schreiben oder sich wiederholende Inhaltsaufgaben ausführen.

Nicht alles kann oder sollte mit Klassen definiert werden, insbesondere wenn es sich um schlecht ausgerichtete Klassen oder nicht überschreibbare Attribute handelt.

Nehmen Sie zum Beispiel eine benutzerdefinierte numerische Einstellung. Es wäre mühsam, eine Klasse für jeden Wert zu definieren, und ein Blockentwickler könnte versucht sein, den Wert direkt in das Attribut style einzufügen.

Wenn es als Block vorhanden ist und benutzerdefinierte CSS-Stile angewendet werden können, sollte es idealerweise ein einheitliches und standardisiertes Mittel dafür geben, selbst wenn es sich um ein Feld mit Textfeldern für Schlüssel / Wert-Paare handelt.

Wenn Sie möchten, können Sie meine vorgeschlagene Methode lesen , um Ihre Bedenken auszuräumen.

Ich habe Ihren Vorschlag für eine API gelesen und es ist nicht weit von dem entfernt, was ich über einen hinzugefügten Hook gesagt habe, damit Schlüsselwertpaare hinzugefügt werden können.

Ich denke jedoch, dass mein ursprünglicher Punkt immer noch gültig ist. Wie ich bereits sagte, gibt es Hunderte von Immobilien, und während einige häufiger vorkommen, wird eine solche Liste schnell wachsen. Wir können diesen Weg gehen und versuchen, einen "guten Kompromiss" zu finden, wie bei den TinyMCE-Funktionen, die in Classic enthalten oder entfernt wurden. Aber hier sind viel mehr Eigenschaften im Spiel, also wäre es eine Herausforderung.

Noch wichtiger ist jedoch, dass die Idee, direktes Styling auf Blockebene hinzuzufügen, zusammenbricht, wenn Sie etwas verkleinern und nicht nur einen einzelnen Block berücksichtigen. Wenn Sie mehrere ähnliche Blöcke auf einer Seite oder über mehrere Seiten hinweg haben, möchten Sie nicht alle diese Werte erneut eingeben. Sie wollen eine Abstraktion ... wie eine CSS-Klasse.

Das Zulassen oder Ermutigen von individuellem Styling auf Blockebene ist nicht ideal, da es nicht wiederverwendbar ist. Sie haben Recht zu sagen, dass nicht alles in eine Klasse abstrahiert werden sollte, sondern dass CSS aus einem bestimmten Grund entwickelt wurde und nicht so schnell in den Wind geworfen werden sollte.

@tmdesigned Ich

Das Ziel ist nicht, die Anzahl der CSS-Klassen zu eliminieren oder sogar zu reduzieren.

Das Ziel besteht insbesondere darin, benutzerdefinierte Blockstileinstellungen in einer einzigen Benutzeroberfläche oder zumindest einer einzigen API zu vereinheitlichen.

Webentwickler, Blockentwickler und Themenentwickler schreiben weiterhin CSS-Code, um Blöcke zu formatieren, und Blöcke verfügen weiterhin über Klassen, Attribute und IDs, damit Entwickler sie formatieren können.

Sie haben genau die gleichen Klassen wie jetzt und genau das gleiche Layout wie jetzt.

ABER

In dem Moment, in dem der Blockentwickler erkennt, dass er über CSS-Eigenschaften verfügt, die vom Benutzer konfiguriert

Dies führt zu einer einzigen gemeinsamen Oberfläche (sowohl für Entwickler als auch für Benutzer), wenn es darum geht, gemeinsame stilbasierte Konfigurationen von Webseiteninhalten

Dies bietet sowohl Benutzern als auch Entwicklern eine einheitliche Möglichkeit zum Anzeigen, Hinzufügen, Entfernen, Ändern und Überschreiben von Blockstilen, die sich letztendlich auf einfache CSS-Eigenschaften beschränken.

Tut mir leid, dass ich so viel Lärm in diesem Thread verursacht habe. Wir sollten wahrscheinlich die weitere Diskussion auf das verwandte Thema verlagern.

Notiz bearbeiten:

Ich habe vergessen, den Punkt der Abstraktion anzusprechen.

Die Minute, in der der Benutzer genau denselben Stil zweimal auf genau denselben Block anwenden muss, ist der genaue Moment, in dem benutzerdefinierte Stileinstellungen für CSS-Klassen (für diesen Block) aufgegeben werden sollten .

Mit anderen Worten, benutzerdefinierte Stileinstellungen bieten dem Benutzer einen konsistenten Mechanismus, mit dem er Blöcke nach seinen Wünschen anpassen kann, unabhängig davon, ob es sich um eine einmalige Sache (wie es sein sollte) oder um 100 Mal auf jeder einzelnen Seite handelt und wie Sie sich für die Strukturierung entscheiden es liegt immer noch ganz bei dir.

Ich denke, wir sind uns größtenteils einig. Mein Vorschlag im ersten Beitrag war, einen Haken zum Hinzufügen / Entfernen von Steuerelementen zu haben. Ich bin nicht gegen eine Benutzeranpassung von Stilen auf Blockebene. Es ist nur schwierig, "diejenigen auszuwählen, die es wert sind, standardmäßig für einen generischen Abschnittsblock verwendet zu werden", ohne dass die Liste exponentiell wächst. Es ist in Ordnung, nur wenige zu haben, insbesondere wenn andere Steuerelemente hinzugefügt werden können. Auf jeden Fall bin ich überrascht, dass Rand und Polsterung für einen Abschnittsblock nicht allgemeiner hilfreich sind als die Hintergrundfarbe.

FWIW, ich mag Ihre Idee, Klassen als Ausgabe generiert zu haben, so dass sie immer noch überschreibbar sind, ohne dass sie verwendet werden müssen! Wichtig.

@rchipka @tmdesigned Ich weiß, dass dies vor über zwei Wochen war, aber wären Sie daran interessiert, einige dieser Details in einer anderen Ausgabe herauszuarbeiten? Ich denke, es wäre vorteilhaft, mehr Augen auf diese Convo zu haben.

Wir haben uns diesen Block anhand der vorherigen Gespräche noch einmal angesehen.

Der einfachste Weg, meine Ideen zu teilen, ist ein Prototyp: https://wp.invisionapp.com/share/PQJPPAX4JZW

Einige Notizen:

• Basierend auf einer kurzen Umfrage: https://wordpress.slack.com/archives/C02QB2JS7/p1527283199000343 Ich habe den Namen von _Section_ in _Container_ geändert.
• Ich habe die Spalteneinstellungen entfernt, da es vernünftig ist, dass Benutzer Spaltenlayouts innerhalb eines bestimmten Abschnitts mischen und anpassen möchten, wie von @jvisick veranschaulicht.
• Zusätzlich zur Hintergrundfarbe habe ich Hintergrundbildunterstützung hinzugefügt. Die Einstellungen basieren auf der vorhandenen Hintergrundbildfunktion des Kerns.
• Sollten wir Leute einen Containerblock in einem Containerblock verschachteln lassen?

@melchoyce Sieht gut aus!

Eine nette Funktion, die ich gerne sehen würde, ist eine Auswahl im Inspektor, um das HTML-Element des Blocks zwischen <aside> , <div> und <section> umzuschalten.

Die Möglichkeit, Container zu verschachteln, sollte meiner Meinung nach auf jeden Fall erlaubt sein. Dies wäre nicht nur nützlich, wenn innerhalb eines einzelnen semantischen Abschnitts verschiedenfarbige Bereiche mit dem oben vorgeschlagenen Vorschlag für HTML-Elemente verwendet werden sollen, sondern auch in Situationen, in denen Sie einem einzelnen Block einen Hintergrund geben möchten, wenn er keinen hat Hintergrundfarboption selbst.

Ein weiteres nettes Feature wären Verlaufshintergründe, da diese in einigen Designs sehr beliebt zu sein scheinen.

@melchoyce +1 für das

@SuperGeniusZeb , das HTML-Element

@jvisick Ja, daran habe ich gedacht. Beaver Builder und Elementor haben beide solche Einstellungen für ihre Zeilen / Abschnitte.

@melchoyce Ich denke, Container sollten unendlich verschachtelbar sein. Auf diese Weise können Benutzer eine benutzerdefinierte Klasse (oder ein benutzerdefiniertes CSS) um jeden Block, einschließlich anderer Container, wickeln.

Es gibt keinen Grund, einem generischen Containerblock Verschachtelungsbeschränkungen hinzuzufügen.

Ich verstehe den Wert der semantischen HTML-Elemente, frage mich aber auch, ob es eine Möglichkeit gibt, diese Funktionalität an Plugins zu delegieren, damit sie als Option für fortgeschrittene Benutzer verfügbar ist, aber durchschnittliche Benutzer müssen nicht darüber nachdenken. Denn sobald Sie das hinzufügen, übernehmen Sie nicht nur die Verantwortung für die Bereitstellung der Funktionalität, sondern auch die Verantwortung für die Aufklärung der Benutzer über die semantischen Implikationen… die oft sehr situativ sind.

@chriskmnds Guter Punkt. Ich denke, dies ist der falsche Ort zum Setzen von Container-Tags.

Der Containerblock sollte als generischer Container ohne semantische Bedeutung fungieren.

Semantische Bedeutung sollte von (zukünftiger) Blockvorlage Funktionalität zur Verfügung gestellt werden, so dass die <aside> Inhalt ein Teil einer Vorlage sein könnte und <section> ein anderes.

Auf diese Weise können Benutzer Inhalte in Containern organisieren, wie sie möchten (auf jeder Tiefenebene), ohne die semantische Bedeutung zu beeinflussen.

Ich bin damit einverstanden, dass die Möglichkeit, HTML-Elemente auszutauschen, für die meisten Leute etwas fortgeschritten erscheint und wahrscheinlich nicht als Basis-Gutenberg-Einstellung gehört.

Die semantische Bedeutung sollte durch (zukünftige) Blockvorlagenfunktionen bereitgestellt werden, damit der Inhalt von <aside> ein Teil einer Vorlage und <section> anderer sein kann.

Dies wäre auf jeden Fall gut zu erkunden.

Ich bin nicht anderer Meinung als die Punkte, die gemacht wurden, um die Basis-UX einfach zu halten, aber ich würde dann fragen, wo Sie <section> , <nav> , <header> usw. hinzufügen würden. Ein generischer Containerblock, der im Wesentlichen ein Wrapper-Element ist, scheint eine natürliche Wahl zu sein. Dies kann für jeden dieser Fälle einem doppelten Block vorgezogen werden. Der Standardwert kann <div> und ein Benutzer muss die Einstellung nur berühren, wenn dies erforderlich ist.

Was wäre, wenn die Optionen für HTML-Elemente ähnlich wie die Einstellungen für Alignwide / Full funktionieren würden, bei denen ein Array unterstützter Elemente über das Thema oder das Plugin festgelegt werden kann?

@jvisick Idealerweise werden diese Wrapping-Elemente mit der " Posts erstellt.

Mithilfe einer Blocklayoutvorlage können Sie eine Reihe von Standardcontainerblöcken einrichten und eine Einstellung (im Code) für den generierten Tag-Namen des Containerblocks angeben.

@rchipka Ich sehe, woher Sie kommen, wenn Sie Layoutvorlagen verwenden, die Benutzern vordefinierte Bereiche zum Verwalten von Inhalten bieten. Ich betrachte dies eher aus der Perspektive, Gutenberg als Seitenersteller für Seiten zu verwenden, die nicht definiert sind und in denen es hilfreich wäre, festzulegen, welche Art von HTML-Element vom Editor verwendet wird. Ich denke, beide Szenarien sind wichtig.

Trotzdem stimme ich

Abschnitte sind im Wesentlichen 1-spaltig. Nun, Spalten.

Ich stelle fest, dass der 3.0.0 Columns (Beta) -Block keine 1-Spalte auf seinem Schieberegler zulässt.

Ich bin mir nicht sicher, ob es besser wäre, nur den Spaltenblock ringsum zu verwenden und diese Implementierungen zu kombinieren. Was ist der Nachteil?

Eine Sache, die hinzugefügt werden sollte, ist das Umschalten, ob der Container (Abschnitt) die volle Breite haben oder enthalten sein soll. Wenn es enthalten ist, sollte es die im Thema (# 5650) festgelegten content_width berücksichtigen, andernfalls sollte es die volle Breite haben. Ich denke, die Mehrheit der Seitenersteller hat diese Funktion.

Ja, das ist in der Quick Toolbar in meinem letzten Modell enthalten.

@melchoyce Beachten Sie, dass es Situationen geben kann, in denen der Abschnitt / Containerblock selbst die volle Breite haben sollte, der Inhalt im Abschnitt / Containerblock jedoch nicht. Wie würde das gehandhabt werden?

Ich dachte mir, dass der Container selbst standardmäßig die volle Breite haben könnte, aber jeder Inhalt darin, der die volle Breite nicht nativ unterstützt (wie Bilder / Deckblöcke), würde immer noch auf die Breite des Editors beschränkt sein.

@melchoyce Angenommen, ich verstehe Sie richtig, bedeutet dies, dass die

Ja, das denke ich mir!

Ich bin mir nicht sicher, ob es besprochen wurde, aber ein Abschnitt könnte ein HTML-Element "Abschnitt" und auch ein "Artikel", "Div" oder etwas anderes sein, oder? Wäre schön es als wählbar zu haben
Dies könnte auch den "Zeilen" -Block unnötig machen, denke ich

Implementiert dies in einem Plugin

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 Dies wurde diskutiert: https://github.com/WordPress/gutenberg/issues/4900#issuecomment -392925877

Ich halte ein Dropdown-Menü zur Auswahl des verwendeten HTML-Tags immer noch für eine gute Idee. Es scheint der einfachste Weg zu sein, semantische HTML-Elemente wie <aside> und <section> ohne eine ganze Reihe übermäßig ähnlicher Blöcke zu erstellen.

@nbrummerstedt Schöne anfängliche jetzt Containerblock und sollte ein <div> als Element verwenden, obwohl Sie im Idealfall (wie oben und in früheren Kommentaren erwähnt) den HTML-Code ändern können Element verwendet von <div> bis <section> , <aside> und vielleicht sogar <article> .

Hier ist eine überarbeitete Version Ihrer Implementierung:

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

Warum wurde dies aus dem Meilenstein von WordPress 5.0, @mtias, entfernt? Dies scheint etwas zu sein, das es wahrscheinlich in die erste Version schaffen sollte, einfach weil es nützlich und einfach ist. Viele Blöcke haben keine Hintergrundeinstellungen, da davon ausgegangen wurde, dass Sie den Containerblock dafür verwenden würden. Es ist nicht einmal so schwer, diesen Block zu implementieren, oder? Ich verstehe nicht, warum dies auf eine Post-WordPress 5.0-Version zurückgeschoben werden sollte.

Außerdem habe ich kürzlich Oxygen getestet und war beeindruckt von seinem Flexbox-basierten Layoutsystem. Was ist, wenn der Containerblock einige dieser Funktionen implementiert hat? Ich wette, es könnte wirklich mächtig sein und eine alternative Möglichkeit bieten, andere Layouts als den Spaltenblock zu haben ... Vielleicht könnte es sogar den Spaltenblock unnötig machen?

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

Ich empfehle dringend, dies zu überprüfen. Eigentlich empfehle ich, nur einen großen Blick auf Oxygen zu werfen. Es unterscheidet sich sehr von allen anderen Plugins für den Seitenersteller, und ich denke, es gibt viele gute Ideen, die Gutenberg verwenden könnte.

Ich stimme definitiv zu, dies sollte in Version 5.0 sein. Sie benötigen einen Container, um hackige Lösungen mit Spaltenblöcken zu vermeiden.

Ich denke auch, dass dieser Block bald als später verfügbar sein muss. Viele WordPress-Entwicklungsagenturen warten auf diesen Block, bevor sie mit Gutenberg bauen.

@ dingo-d und @ericvalois Ja, ich habe es unterlassen, Gutenberg für alles andere als Blog-Posts zu verwenden, gerade weil drei Dinge fehlen: reaktionsfähige Spalten, Spalten ungleicher Breite und ein Containerblock.

Um näher auf das einzugehen, was ich zuvor über den Containerblock gesagt habe, der Dinge übernimmt, die Sauerstoff tut, denke ich, dass der Containerblock eine Option haben könnte, die Flussrichtung seiner verschachtelten Blöcke von vertikal auf horizontal zu ändern. Es kann auch vertikale und horizontale Ausrichtungsoptionen geben, wie sie Sauerstoff bietet. Diese wären sehr leistungsfähig - insbesondere in Kombination mit der Möglichkeit, diese Optionen reaktionsschnell zu ändern, wie es die meisten Plugins für den Seitenersteller zulassen.

Natürlich gibt es das bemerkenswerte Problem, dass ein Containerblock mit Flexbox-basierter Ausrichtung / Layout nicht zulässt, dass Float-ausgerichtete Blöcke direkt darin verschachtelt werden. Ich denke jedoch, dass es dafür eine einfache Lösung gibt: Fügen Sie die Möglichkeit hinzu, dass ein Container entweder das Standard-CSS-Layout display: block oder das Flexbox-Layout verwendet. Der Standardmodus display: block wäre der Standardmodus, da dies das Stammdokument verwenden würde. Durch Aktivieren des Flexbox-Anzeigemodus werden alle übersichtlichen Ausrichtungsoptionen im Inspektor angezeigt. Außerdem möchten Sie den beiden Layoutmodi im Inspektor natürlich einen anderen Namen geben, um sie benutzerfreundlicher zu gestalten. Ich bin mir jedoch nicht sicher, wie Sie sie nennen würden. Vielleicht "Standard" und "Flexibel"?

Es wäre sehr nützlich, Containerblöcken zu erlauben, entweder den Modus zu verwenden, der Floats unterstützt, oder den Modus mit den besseren Ausrichtungs- / Layoutoptionen. Sie können Containerblöcke verschachteln, um bei Bedarf beide Arten von Layouts zu verwenden. Fügen Sie dies zu den anderen Fähigkeiten hinzu, die der Containerblock haben könnte (Hintergrundoptionen, Möglichkeit, ein HTML-Tag für zusätzliche semantische Bedeutung auszuwählen, ohne auf benutzerdefinierte HTML-Blöcke zurückgreifen zu müssen usw.), und der Containerblock wäre am Ende eine der wichtigsten und nützliche Blöcke in Kern WordPress.

Insbesondere wenn der Containerblock mit zwei Layoutmodi nach zu vielen Funktionen klingt (und ich glaube nicht, dass dies ein Problem wäre), könnte es nur zwei separate Blöcke geben:

• Ein Standard-Containerblock, der Floats unterstützt, jedoch nicht alle erweiterten Ausrichtungs- / Layoutoptionen bietet
• Ein erweiterter Containerblock (oder ein erweitertes Layout oder ein flexibles Layout oder wie auch immer Sie es nennen), der das Flexbox-Layout verwendet und alle übersichtlichen Optionen bietet

Ich empfehle, dieses Video zur Sauerstoffdokumentation zu lesen, um zu sehen, wie das Layoutsystem funktioniert. Es ist wirklich beeindruckend:

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

Ich denke, hier gibt es viel Potenzial, um Gutenberg sehr mächtig zu machen. Für eine erste Implementierung würde ich natürlich nur erwarten, dass der Containerblock Hintergrundoptionen, die Möglichkeit zum Ändern des verwendeten HTML-Elements und die Option zum Festlegen des Containers in voller Breite (aber nicht des darin enthaltenen Inhalts) enthält. Vielleicht sogar nur die Hintergrundoptionen.

Tatsächlich ist es immer noch nützlich, nur einen Containerblock zu haben, der nicht einmal über Optionen verfügt, da dies das Formatieren einer Gruppe von Blöcken über CSS erleichtert.

Es ist wichtig, an Gutenberg zu denken, nicht nur daran, nach 5.0 anzuhalten. Dies ist ein wirklich nützlicher Block, der untersucht wird, aber für die erste Phase ist es nicht wirklich erforderlich, sich auf die Bearbeitung zu konzentrieren. Wenn das Projekt über die einfache Bearbeitung hinaus in das Layout erweitert wird, ist dort zweifellos eine Lösung erforderlich. Niemand sagt, dass dies nicht erstellt wird. Es geht darum, Prioritäten zu setzen, was Editor ist und was dann in Phase zwei aufgenommen wird.

Aber die Sache ist, dass die Mehrheit der Leute Gutenberg für Layoutzwecke verwendet, nicht zum Schreiben von Posts.

Die Leute sind es gewohnt, Posts wie ein Word-Dokument zu schreiben, daher deaktivieren sie den Gutenberg auf den Post-Seiten.

Aber die Sache ist, dass die Mehrheit der Leute Gutenberg für Layoutzwecke verwendet, nicht zum Schreiben von Posts.

Auf welcher Datenquelle basiert diese Annahme?

Ich habe während der WCEU in Belgrad mit mehreren Leuten gesprochen. Sie sind sich alle einig, dass es seltsam ist, Beiträge mit Gutenberg zu schreiben, und deaktivieren sie daher für Beiträge.

Im Gegensatz zu dem, was @ dingo-d gesehen hat, verwende ich Gutenberg nur für Posts. Ich finde die Erfahrung für das Post-Making in Gutenberg viel schöner als im Classic Editor. Teilweise wegen der modulareren Natur und der kontextbezogenen Steuerung, und teilweise, weil überall keine störenden unsichtbaren <p> -Tags mehr eingefügt werden. Das hat mich immer geärgert.

Ich benötige einen Containerblock (auch einen ohne Optionen) und einen anständigen Spaltenblock (oder einen anderen Layoutblock), um Gutenberg für eine gleichmäßige Seitenerstellung verwenden zu können. Es sieht so aus, als würde der Columns-Block eine grundlegende Reaktionsfähigkeit erhalten (siehe # 6048). Das bedeutet, dass nur das Fehlen eines Container-Blocks mich daran hindert, Gutenberg in mehr Kontexten zu verwenden.

Ich weiß, dass der Containerblock offensichtlich irgendwann hinzugefügt wird (wahrscheinlich nicht später als WordPress 5.1), aber ich bin fest davon überzeugt, dass er hinzugefügt werden sollte, bevor WordPress 5.0 veröffentlicht wird. Selbst im Zusammenhang mit dem Schreiben von Posts kann ein Container für etwas wie <aside> (wenn er die Dropdown-Funktion zur Auswahl von HTML-Elementen enthält) für zusätzliche Semantik nützlich sein. Wenn Sie zur weiteren Semantik etwas in ein anderes HTML-Element einschließen möchten, müssen Sie den benutzerdefinierten HTML-Block verwenden. Dies bedeutet, dass Sie die Funktionen des Absatzblocks nicht für Absätze in diesem benutzerdefinierten HTML-Block nutzen können Alle Funktionen des Bildblocks für Bilder in diesem benutzerdefinierten HTML-Block usw.

@ karmatosed

Niemand sagt, dass dies nicht erstellt wird. Es geht darum, Prioritäten zu setzen, was Editor ist und was dann in Phase zwei aufgenommen wird.

Meiner Meinung nach gehört der Containerblock absolut zur ersten Phase.

Was ich irgendwie komisch finde, ist, dass der Columns-Block so aussieht, als würde er es in WordPress 5.0 schaffen (möglicherweise immer noch mit dem Label „(Beta)“, der Container-Block jedoch möglicherweise nicht? Wenn der Fokus im Moment auf dem Schreiben liegen soll Posts, warum wurde dann ein Columns-Block hinzugefügt, aber kein Container-Block? Der Container-Block ist meiner Meinung nach im Kontext von Posts weitaus nützlicher als der Columns-Block. Und natürlich hat er auch viele Vorteile im Kontext der Seitenerstellung auch.

Wenn der Container-Block es nicht in WordPress 5.0 schafft, bedeutet dies, dass er erst in 5.1 veröffentlicht wird, was die Verwendung durch die meisten Benutzer für Monate verzögert. Ich möchte, dass Gutenberg erfolgreich ist, und ich habe das Gefühl, dass es keinen Grund gibt, die Veröffentlichung von etwas Grundlegendem wie einem Containerblock bis WordPress 5.1 zurückzuhalten. Für einen guten ersten Eindruck würde ich sogar empfehlen, ihn vor dem WordPress 4.9.8-Callout hinzuzufügen.

Ich erwarte nicht, dass es alle Funktionen enthält, die die Leute vorgeschlagen haben. Die bloße Existenz reicht aus, um viele gängige Anwendungsfälle zu lösen, die derzeit nur durch eine ziemlich hackige Lösung der Verwendung eines Spaltenblocks mit dem manuell auf 1 eingestellten Spaltenschieberegler behandelt werden. Und dann nur eine Option wie Hintergrundfarbenoptionen würde es viel nützlicher machen.

Ich bin damit einverstanden, dass dies ein cooler und nützlicher Block ist, aber es ging immer mehr um Phase 2 des Projekts und wir müssen uns wirklich konzentrieren, sonst werden wir nie versenden. Wir haben die verschachtelte Blockinfrastruktur erstellt, da es wichtig war, die richtigen Abstraktionen zu erstellen und den Benutzern das Erstellen ihrer benutzerdefinierten Layoutblöcke zu ermöglichen, sodass ein tatsächlicher Kernblock wie dieser weniger kritisch ist. Der Fokus liegt darauf, die verschachtelte und untergeordnete Benutzeroberfläche im Allgemeinen richtig zu machen (unter Verwendung von _Columns_ als Versuchskaninchen).

Diese Ausgabe ist seit fünf Monaten ebenfalls offen und es gibt keine soliden Implementierungsvorschläge, die Dinge wie Farben, Breiten, Richtung der Blöcke gegenüber Verschachtelungsspalten, Überlappung mit dem Titelbild usw. enthalten. So wie es aussieht, können wir Priorisieren Sie es nicht vor anderen Allzweckarbeiten, die wir ausführen müssen, und dem bevorstehenden "Versuch" in WordPress. Das bedeutet nicht, dass es den Schnitt nicht schafft, besonders wenn jemand Vorschläge im Code machen möchte.

Das größte Problem für mich ist auch, dass nicht klar ist - nur aus dem Gespräch hier ersichtlich -, wie die ideale Benutzererfahrung aussehen sollte, um sich auf eine Implementierung festzulegen. Dinge wie das Offenlegen von HTML-Tags scheinen für einen normalen Benutzer offensichtlich komplex und nicht intuitiv zu sein. Die Vorstellung eines Containers muss eingehender getestet werden, um festzustellen, ob es sich um die beste Layout-Abstraktion handelt, die in der nächsten Fokusphase ebenfalls herausgefunden werden sollte. Es gibt auch einige Unbekannte, wie ein solcher Block Stile in beliebige Blöcke innerhalb kaskadieren würde - es ist relativ einfach, Kernblöcke zu berücksichtigen, aber keinen beliebigen Block.

Gleichzeitig sollte es einem Entwickler, der einen benutzerdefinierten Block anbieten möchte, leicht fallen, ihn (wie das oben gezeigte Snippet) mit einem beliebigen Tag zusammenzusetzen, indem er InnerBlocks und Benutzerfeedback sammelt. Es gibt also weniger Druck auf den Kern, einen solchen Block zu haben (und ihn warten zu müssen). Trotzdem sollte sich jeder frei fühlen, einen Vorschlag über PR zu machen und beim Testen durch den Benutzer zu helfen. Ich wäre in Ordnung, wenn ich es dem Plugin als "experimentell" hinzufügen würde, mit der Vorstellung, dass es für 5.0 weggezogen werden könnte.

@ SuperGeniusZeb Sauerstoff ist ziemlich cool! Sollte auf jeden Fall für einige dieser Erkundungen angesehen werden.

Was passiert aus Neugier, wenn Themen und Plugins ihre eigenen Abschnittsblöcke hinzufügen und der Benutzer das Plugin deaktiviert oder Themen ändert? Gibt es eine Art Fallback? Oder verliert der Benutzer seinen Inhalt?

@tomusborne Es gibt ein Problem mit dieser Art von Situation: # 7811.

Ah! Ich wusste nicht, dass dies hier diskutiert wurde. Also habe ich auch ein Plugin gemacht, als ich das brauchte.

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

Ich habe diesen Thread gesehen und schätze all die Gedanken, die in ihn eingeflossen sind. Ich habe kürzlich einen Containerblock im Atomic Blocks-Plugin veröffentlicht , der Ränder, Auffüllungen, Containerbreite sowie Hintergrundbild- und Farboptionen enthält. Ich hoffe, das ist hilfreich und kann uns aufhalten, bis ein Kernblock zu einem späteren Zeitpunkt eintrifft!

Nach diesem Problem habe ich einen Block "Container" erstellt, mit dem Sie die Struktur der Spalten und andere Optionen auswählen können.
Wenn dies dazu beitragen kann, den Block "Spalten" zu verbessern oder einen neuen im Kern zu erstellen, finden Sie ihn hier: https://github.com/MarieComet/WP-container-block/

@MarieComet Das ist ordentlich, aber ich denke, dein Block sollte in 2 verschiedene Blöcke aufgeteilt werden. Der erste sollte ein Spaltenblock mit allen spaltenbasierten Strukturlayoutoptionen sein. Der zweite wäre ein Containerblock mit Hintergrundoptionen und Layoutoptionen, die nicht spaltenbasiert sind, z. B. die Möglichkeit, Kinder mithilfe von Flex horizontal und nicht vertikal zu gestalten und sie mithilfe von Optionen auszurichten und zu begründen, die den CSS Flex-Eigenschaften entsprechen.

Sie könnten wahrscheinlich auch den Containerblock verwenden, um die einzelnen Spaltenblöcke zu ersetzen, obwohl es möglicherweise einige Optionen gibt, die Sie für eine Spalte haben möchten, die für einen Abschnitt keinen Sinn ergeben.

Mir ist klar geworden, dass die Zukunft beim Erstellen von Layouts mit HTML und CSS nicht immer darin besteht, Spalten wie bei den meisten Seitenerstellern zu verwenden, sondern auch CSS Flex und Grid zu verwenden, um Inhalte mit weniger <div> s anzuzeigen das Markup und haben flexibleres und saubereres Styling. Ich bin hauptsächlich von dem inspiriert, was Oxygen tut. Ich habe in diesem Kommentar über Sauerstoff gesprochen.

In diesem Problem geht es derzeit nicht darum, den Spaltenblock zu ersetzen. Es ist wichtig, sich auf das zu konzentrieren, worum es in diesem Thema geht, einen Abschnittsblock.

@karmatosed @melchoyce Apropos, sollte dieses Problem nicht umbenannt werden? Wir haben aufgehört, es "Section" zu nennen und sind zu "Container" gewechselt, um Verwechslungen mit <section> -Elementen zu vermeiden.

Der Name ist noch nicht entschieden, also gehen wir alle gut weg, so wie es ist.

Im Moment versuche ich zusammen mit dem Gutenberg-Editor ein Thema zu implementieren.

Das Layout der Website hat verschiedene Bereiche mit unterschiedlichen Hintergründen, die mehrere Elemente wie Absätze oder Listen enthalten. Dies dient Layout- und Navigationszwecken. Die Abschnitts- / Containerblöcke sollten als Anker fungieren / eindeutige CSS-IDs haben.

Ich kann dieses Thema nicht beenden, ohne mich in Gutenberg zu hacken, indem ich eigene Blöcke erstelle. Es könnte stattdessen mit diesem als Kernblock gemacht werden. Ich würde den Gutenberg-Editor nicht nur für einfachen Text und einfache Layouts verwenden - mein zukünftiges Layout / Design sollte zusammen mit dem Thema und dem Blocksystem von Gutenberg erstellt werden.

Ich hoffe sehr, dass diesem Thema eine höhere Priorität eingeräumt wird.

Ich verwende überall Containerblöcke von Drittanbietern (z. B. Atomblöcke) in Kombination mit dem Spaltenblock. Sie waren super nützlich und mein beliebtester Block. Ich finde es seltsam, dass es später in der Zukunft oder als Add-On in Betracht gezogen wird. muss im Kern sein.

Andernfalls würde ich die Container nur manuell in der HTML-Ansicht erstellen. Dies ist jedoch ärgerlich / ineffizient, da die HTML-Ansicht nur einen Klick vom Menü entfernt ist. Es gibt eine Tastenkombination für die HTML-Ansicht ... Umschalt + Option + cmd + M ... ja. Und es wechselt nicht einmal hin und her. Wenn Sie die Verknüpfung erneut drücken, geschieht nichts. Um zur WYSIWYG-Ansicht zurückzukehren, müssen Sie die Menüs durchgehen. Ein großer, klobiger Kippschalter in der Hauptsymbolleiste wäre großartig.

Hat jemand eine Liste der derzeit in freier Wildbahn befindlichen Implementierungen katalogisiert / geführt? Ich denke, es würde auch eine Art Parametermatrix von "richtig und falsch gemacht" brauchen. Zum Beispiel die Angabe von fest codierten Einheiten (px) für zugehörige Auffüllungen / Ränder (falsch), wenn Einheiten wahrscheinlich eine dem Benutzer überlassene Wahl sein sollten (rechts) usw.

https://editorblockswp.com/library/ hat einige im Katalog, aber um dieses Problem voranzutreiben, scheint etwas Spezielles für Abschnitte / Container zu passieren.

Meiner Meinung nach hätte ein einfacher Containerblock mindestens die folgenden Optionen:

• Hintergrundbild
• Hintergrundfarbe
• Möglichkeit, Hintergrundfarben auf das Bild zu legen und die Deckkraft zu steuern
• Auffüll- und Randoptionen für alle 4 Richtungen mit der Möglichkeit, die verwendeten Einheiten für jeden Wert einzeln zu wechseln
• Unterstützung für Float Left, Float Right, Wide und Full Alignments
• Fähigkeit, die maximale Breite der enthaltenen Blöcke irgendwie zu steuern
• Möglichkeit, das vom Container verwendete HTML-Element auszuwählen

Außerdem hätte ich lieber folgendes:

• CSS-Flex-Layoutoptionen: Möglichkeit, die Richtung des Inhaltsflusses von oben nach unten nach links nach rechts, rechts nach links und unten nach oben festzulegen. und die Fähigkeit, die vertikale und horizontale Ausrichtung des Inhalts festzulegen
• Die Verwendung von Flex-Optionen ist natürlich nicht mit Float-Ausrichtungen kompatibel, sodass der Block mindestens zwei Layoutmodi haben muss: Standard und Flex, oder es muss ein separater Flex-Container-Block vorhanden sein
• Optionen für Schriftgröße und Farbe, um die Standardeinstellungen für den Inhalt im Container festzulegen und zu vermeiden, dass diese für jeden enthaltenen Block einzeln festgelegt werden müssen

Felix Arntz hat gerade einen Blog-Beitrag über seine Implementierung von Abschnittsblöcken veröffentlicht.
Ich mag das reaktionsschnelle Hintergrundbild.
https://felix-arntz.me/blog/building-a-reusable-gutenberg-section-block/

In den letzten Wochen habe ich mit der Implementierung von Marc Lacroix experimentiert, die in Ordnung funktioniert, aber in gutenberg 3.9.0 https://github.com/marcusig/gutenberg-section-block zu brechen scheint

Ich habe einige Zeit darüber nachgedacht. Die Tatsache, dass so viele Implementierungen dafür entstanden sind, bedeutet, dass es ziemlich wertvoll ist und es für den Kern wahrscheinlich besser ist, einen konsistenten Mechanismus anzubieten, um eine Fragmentierung zu vermeiden. Meine Hauptsorge ist die Komplexität eines "Abschnitts" -Blocks für einen Benutzer.

Ich schlage vor, sehr einfach zu beginnen, mit nur einem Container (einem einzelnen InnerBlocks-Bereich), breiten und vollständigen Ausrichtungen und einer Einstellung für die Hintergrundfarbe (kein Bild usw. - dafür haben wir "Cover").

Wir haben nicht viel Zeit dafür, wenn wir es in 5.0 wollen.

@mtias Wenn es verfügbar zu machen , sollte möglicherweise jeder Block standardmäßig nur über Container- oder Containereinstellungen verfügen.

Dann müssen wir uns nicht darum kümmern, dem Endbenutzer beizubringen, dass er etwas in einen Container einwickeln muss, damit er bestimmte Dinge wie ein Hintergrundbild hat.

Ich denke, dies ist eigentlich eine gute Idee, da dann Leute, die beliebige Blöcke erweitern oder umschließen möchten, einen klaren Platz dafür haben und Endbenutzer damit vertraut sind, weil es sich auf jedem Block befindet.

Möglicherweise könnte "Containereinstellungen" eine Registerkarte neben "Blockeinstellungen" sein. Dies wäre ein (erweiterbarer) Ort, an dem Entwickler Dinge wie Hintergrundbildeinstellungen, Breiteneinstellungen usw. einfügen (oder herausfiltern) können.

Dies würde Entwicklern auch die Möglichkeit geben, komplexere Einstellungen vorzunehmen, die auf so ziemlich jeden Block angewendet werden können, wie z. B. Responsive / Breakpoint-Steuerelemente.

@rchipka Technisch gesehen sind die meisten Blöcke mit einem übergeordneten Div

Die Leistung eines Containers liegt nicht genau in einem einzelnen Block, sondern Sie können andere Blöcke innerhalb des Containers hinzufügen und so komplexere Layouts, Abschnitte und Seitenstrukturen erstellen.

@mikemcalister Guter Punkt, der Endbenutzer würde immer noch eine Möglichkeit benötigen, den Blockbaum visuell zu gruppieren / zu organisieren.

Ich denke, die Philosophie bleibt jedoch dieselbe. Wenn der Editor einen Blockgruppierungsmechanismus im Baumstil hätte (dh ohne eine "Containerblock" -Schnittstelle), würden die "Containereinstellungen" für jeden untergeordneten Block die Einstellungen dieser Gruppe (dh diese Ebene im Baum) widerspiegeln.

Wiederum besteht der einzige Punkt dieser Idee darin, die Anzahl der Schritte für den Endbenutzer zu verringern und daher auch die Lernkurve zu verringern und die Auffindbarkeit zu erhöhen.

Ich denke, das Hauptproblem ist, dass Gutenberg derzeit sehr auf Standard-Post- / Seiteninhalte beschränkt ist. Ohne einen Abschnitt / Container-Block können Benutzer keine Titelseiten mit Abschnitten voller Breite (mit Hintergrund- / Verlaufsfarbe im Hintergrund oder Hintergrundbild voller Breite) mit allen Arten von Inhalten (hoffentlich über verschachtelte Blöcke) erstellen.

Ein Abschnitt / Containerblock wäre hier perfekt. Sogar eine grundlegende, die mit mehr Steuerelementen durch Themen / Plugins erweitert werden könnte. Ich würde gerne auch mehr Ausrichtungseinstellungen bekommen. Wir machen bereits etwas mit CMB, um einen Pseudo-Seiten-Builder direkt auf den Seiten zu haben, hoffen aber wirklich, dass Gutenberg dies alles für alle flexibler machen kann.

@JiveDig Ich glaube nicht, dass irgendjemand, einschließlich des Gutenberg-Teams, gegen eine Art

Das Hauptzögern des Gutenberg-Teams (in diesem Fall und in vielen anderen Fällen) besteht darin, die Kernschnittstelle unter UI / UX-Gesichtspunkten auf einem Squarespace-Komplexitätsniveau zu halten.

Um dies im Kern umzusetzen, scheint es das Hauptproblem zu sein, einen Weg zu finden, wie dies dargestellt werden kann, ohne die Endbenutzer zusätzlich zu belasten.

Obwohl, meiner Meinung nach , ist es nicht wie eine große Sache scheint, ein „Container Block“ nicht legen Sie eine kleine Belastung für den Endbenutzer durch , die Kenntnisse über seinen Zweck und seine Nutzung.

Aus diesem Grund habe ich das Konzept der "Gruppierung" als eine zugänglichere Analogie zu "Containern" für Endbenutzer vorgeschlagen.

Der Endbenutzer würde nicht daran denken, Blöcke in Container zu verpacken, sondern an die Gruppierung von Blöcken, was intuitiver erscheint.

Auf diese Weise muss der Endbenutzer nichts im Voraus wissen, um Blöcke zu gruppieren und Einstellungen auf diese Gruppe anzuwenden.

Natürlich würden diese "Gruppen" intern genau wie ein Containerblock funktionieren, es ist nur eine integriertere und intuitivere Front-End-Oberfläche.

@rchipka Eine sehr einfache Möglichkeit, dies zu erreichen, ist die Möglichkeit, einen oder mehrere Blöcke auszuwählen und im Menü "Mehr" auf die Option "Ausgewählte Blöcke in Containerblock verschieben" zu klicken. Auf diese Weise benötigen Blöcke kein zusätzliches Einstellungsfeld.

Ja, ein Abschnittsblock sollte sich im Kern befinden. Das Rendern eines einfachen Divs im HTML ist ausreichend. Da jedoch buchstäblich Hunderte von Attributen angeboten werden könnten, empfehle ich dringend, stattdessen die beiden Attribute CLASS und ID (wobei ID am wenigsten kritisch ist) anzubieten. Auf diese Weise können die Elemente in CSS dort gestaltet werden, wo sie sein sollten.

- -
Wes-Modi
Eine geheime Geschichte der amerikanischen Flussmenschen
http://peoplesriverhistory.us

Von meinem Apple gesendet] [e

Am 12. Oktober 2018, um 8:09 Uhr, schrieb Matias Ventura [email protected] :

Ich habe einige Zeit darüber nachgedacht. Die Tatsache, dass so viele Implementierungen dafür entstanden sind, bedeutet, dass es ziemlich wertvoll ist und es für den Kern wahrscheinlich besser ist, einen konsistenten Mechanismus anzubieten, um eine Fragmentierung zu vermeiden. Meine Hauptsorge ist die Komplexität eines "Abschnitts" -Blocks für einen Benutzer.

Ich schlage vor, sehr einfach zu beginnen, mit nur einem Container und einer Einstellung für die Hintergrundfarbe (kein Bild usw. - dafür haben wir "Cover").

Wir haben nicht viel Zeit dafür, wenn wir es in 5.0 wollen.

- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

Auch hier sollte jeder Block die Möglichkeit haben, sein Klassenattribut festzulegen. Unabhängig vom Typ.

- -
Wes-Modi
Eine geheime Geschichte der amerikanischen Flussmenschen
http://peoplesriverhistory.us

Von meinem Apple gesendet] [e

Am 12. Oktober 2018, um 8:40 Uhr, schrieb Robbie Chipka [email protected] :

@mtias Wenn es verfügbar zu machen , sollte möglicherweise jeder Block standardmäßig nur über Container- oder Containereinstellungen verfügen.

Dann müssen wir uns nicht darum kümmern, dem Endbenutzer beizubringen, dass er etwas in einen Container einwickeln muss, damit er bestimmte Dinge wie ein Hintergrundbild hat.

Ich denke, dies ist eigentlich eine gute Idee, da dann Leute, die beliebige Blöcke erweitern oder umschließen möchten, einen klaren Platz dafür haben und Endbenutzer damit vertraut sind, weil es sich auf jedem Block befindet.

Möglicherweise könnte "Containereinstellungen" eine Registerkarte neben "Blockeinstellungen" sein. Dies wäre ein (erweiterbarer) Ort, an dem Entwickler Dinge wie Hintergrundbildeinstellungen, Breiteneinstellungen usw. einfügen (oder herausfiltern) können.

Dies würde Entwicklern auch die Möglichkeit geben, komplexere Einstellungen vorzunehmen, die auf so ziemlich jeden Block angewendet werden können, wie z. B. Responsive / Breakpoint-Steuerelemente.

- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

Ich lehne die Gruppierungsmethode nicht ab (solange ich Klassenattribute zuweisen kann), obwohl es erfreulich wäre, wenn es AUCH einen Containerblock gäbe, wenn Sie auf diese Weise erstellen möchten.

- -
Wes-Modi
Eine geheime Geschichte der amerikanischen Flussmenschen
http://peoplesriverhistory.us

Von meinem Apple gesendet] [e

Am 12. Oktober 2018, um 10:50 Uhr, schrieb Chris Van Patten [email protected] :

@rchipka Eine sehr einfache Möglichkeit, dies zu erreichen, ist die Möglichkeit, einen oder mehrere Blöcke auszuwählen und im Menü "Mehr" auf die Option "Ausgewählte Blöcke in Containerblock verschieben" zu klicken. Auf diese Weise benötigen Blöcke kein zusätzliches Einstellungsfeld.

- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

@chrisvanpatten Ich stimme zu, aber diese Lösung geht nicht angemessen auf das ursprüngliche Anliegen von @mtias ein , das Konzept eines Containers oder Abschnitts dem Endbenutzer

Wie von @mtias angesprochen , geht es nicht um die Logistik des

Die Diskussion "Wie wir Blöcke in einen Container bekommen" ist notwendig. Ich sehe es jedoch nicht unbedingt als zu komplex für einen Benutzer an. Viele Benutzer werden es nicht oder zumindest nicht außerhalb ihrer Homepage verwenden. Viele unserer Kunden und Themenkunden drücken die Wünsche / Bedürfnisse ihrer Websites visuell aus, passend für einen Abschnittsblock. Sie sagen Dinge wie "Ich möchte eine große Breite {Balken / Bereich / Abschnitt / Block / Panel / Bereich} mit einem hübschen Bild" gefolgt von "und {Inhaltsanfragen hier einfügen} in diesem Abschnitt". Sie verstehen visuell, dass der Abschnitt selbst (der Container) vom Inhalt darin getrennt ist.

Zugegeben, wie es über die Benutzeroberfläche gemacht wird, muss geklärt werden, aber hoffentlich macht mein oben genannter Punkt Sinn.

@chrisvanpatten Meine vorherige Anweisung basiert ausschließlich auf der Semantik der Blocktypen.

Der einzige Grund, warum ich hier über Semantik argumentiere, ist im Namen von @mtias , da ein Problem mit der Komplexität aufgeworfen wurde, die diese Semantik überhaupt

Ich mag Ihren Vorschlag, aber wenn ich meiner Analogie folge, würde ich vielleicht die Semantik "Gruppe ausgewählte Blöcke gruppieren" ändern.

@rchipka so habe ich seinen Kommentar nicht interpretiert - ich habe damit gemeint, dass der vorgeschlagene Block einfach sein müsste, aber dennoch selbst ein Block sein müsste (wenn es sich um einen InnerBlocks-Bereich handeln soll, der eingeschlossen werden muss Ein Block). Vielleicht gibt es eine Möglichkeit, es vor dem Inserter zu verbergen und nur Containerblöcke zu erstellen, indem mehrere Blöcke ausgewählt und eine Option "Platz im Container" bereitgestellt werden, aber basierend auf meinem Verständnis des Systems, das immer noch einen dedizierten Block bedeuten würde.

Das heißt, ich bin mehr als glücklich, falsch zu liegen :)

@ JiveDig Ich stimme sehr zu ....

Das Gutenberg-Team scheint jedoch sehr sensibel dafür zu sein, diese Dinge dem Endbenutzer im Gutenberg-Kern zugänglich zu machen.

Dies ist meine einzige Grundlage, um diese Argumente vorzubringen und diese Ideen zu präsentieren.

Wenn ich es wäre, hätten wir wieder nur den verdammten Containerblock.

Ich denke nicht, dass ein Containerblock wirklich Sinn macht, da er die Benutzeroberfläche überladen würde. Ich würde lieber so etwas wie die Markierung "Abschnittswechsel" sehen, die Sie in Microsoft Word inline sehen. Das Hinzufügen eines Abschnittswechsels bietet einige Stiloptionen im Inspektor, z. B. einen Klassennamen für den Abschnitt, Hintergrundfarbe, Textfarbe, Schlagschatten, was auch immer Ihren Abschnitt stilistisch definiert. Es kann wie jeder Block eingefügt und wie jeder Block verschoben werden.

@rwrobe Diese Idee funktioniert nicht für verschachtelte Container.

Ich baue gerade eine Site mit Gutenberg und habe eine modifizierte Version von Marcusigs Abschnittsblock stark genutzt . Folgendes habe ich aufgrund der Erfahrung gelernt:

• "Abschnitt" ist der beste Name für den Block. Die Bedeutung ist Entwicklern und Endbenutzern klar und es wird vermieden, das Markup / die Optionen durch die logische Verwendung des Blocks <section> zu komplizieren.

• Die einzigen Kontextmenüoptionen, die benötigt werden, sind alignnormal / wide / full (und tatsächlich verwende ich nur alignfull). Die Ausrichtung wirkt sich nicht auf die inneren Blöcke aus, die innerhalb der normalen Ausrichtung bleiben, es sei denn, sie haben ihre eigenen Ausrichtungsoptionen. Der primäre Anwendungsfall war das Erstellen einer ausrichtbaren Hintergrundfarbe, die einen normal ausgerichteten Textblock enthält - ein sehr häufiges Entwurfsmuster, das derzeit nicht möglich ist.

• Die einzigen Einstellungen für den Seitenleistenblock sind Hintergrundfarbe und Hintergrundbild (mit zugehörigen Optionen für Feste / Deckkraft). Jede zusätzliche Anpassung kann mit der benutzerdefinierten CSS-Klasse durchgeführt werden. (Das Einfügen der Option "Hintergrundbild" hat auch den Nebeneffekt, dass dies zu einer viel nützlicheren Version des Deckblocks wird.) (Wenn jedoch Sie diese Konversation vermeiden, indem Sie nur die Option "Hintergrundfarbe"

• Die Benutzerfreundlichkeit war einfach. Einfacher als Spalten, die es schon eine Weile gibt. Das einzige potenzielle Problem besteht darin, dass beim erstmaligen Hinzufügen des Abschnitts der Fokus auf einen Absatz innerhalb des Abschnitts verschoben wird. Daher kann es schwierig sein, zu erkennen, dass der Abschnitt gerade hinzugefügt wurde, bis Sie mit der Maus darüber fahren. Eine mögliche Lösung hierfür besteht darin, standardmäßig eine hellgraue Hintergrundfarbe zu verwenden.

@ZebulanStanphill Sprechen Sie über Spalten? Ich konnte sehen, dass "Abschnitts" -Blöcke die Arbeit für vertikal getrennte Inhalte erledigen - es könnte sogar einen Schalter zum Erben von Stilen aus dem vorherigen Abschnitt geben, mit dem Sie Stilvariationen innerhalb eines Abschnitts "verschachteln" können.

Die horizontale Komposition, wie in Spalten, scheint notwendigerweise schwieriger zu sein, da Gutenberg die Seite in Blöcken voller Breite von oben nach unten erstellt.

@mikedance Ich denke, das ist genau das, was benötigt wird. Eine Hintergrundbildoption wäre jedoch wichtig, IMO. Vielleicht könnte dieser Block dann den Cover-Block ersetzen, obwohl die Benennung für Personen, die nur ein Hintergrundbild mit einfachem Text darüber wünschen, möglicherweise nicht förderlich ist. Es gibt zwar einige Überschneidungen in der Funktionalität, aber es würde einen großen Prozentsatz der Anwendungsfälle für den Abschnittsblock wegnehmen, ohne die Unterstützung von BG-Bildern hinzuzufügen.

@rwrobe Es sollte beachtet werden, dass Sie horizontal angeordnete Blöcke haben können. Die Spaltenblöcke (beachten Sie das Fehlen von "s") sind genau das. Der Spaltenblock legt sie horizontal an. Die Benutzeroberfläche könnte wahrscheinlich in einigen Bereichen verbessert werden, aber Blöcke sind nicht darauf beschränkt, in voller Breite oder vertikal angeordnet zu sein.

@mikedance

"Abschnitt" ist der beste Name für den Block. Die Bedeutung ist Entwicklern und Endbenutzern klar und es wird vermieden, das Markup / die Optionen durch die logische Verwendung von zu komplizieren

Block.

Da dem Element <section> eine Semantik zugeordnet ist, ist es am besten, wenn Sie ein <div> anstelle eines <section> , da Sie in vielen Fällen einbrechen möchten mehrere Blöcke, aber sie sind nicht semantisch Teil eines Abschnitts. In der Tat wäre es sogar noch besser, wenn Sie auch Elemente wie <aside> oder <header> könnten. Letzteres ist besonders nützlich, um Überschriften mit Hintergrund beim Erstellen von Seiten Semantik hinzuzufügen.

In einem anderen Punkt denke ich, dass es sehr nützlich wäre, Hintergrundbildoptionen für einen Containerblock verfügbar zu haben. Natürlich wird die Überlappung mit dem Cover-Block-Konzept deutlich. Wenn Sie den Cover-Block flexibler gestalten, wird er ohnehin zu einem Container-Block. Vielleicht muss das Cover-Block-Konzept also nicht existieren? Ein Containerblock kann so ziemlich alles, was er tut. Das Cover-Konzept könnte nur eine wiederverwendbare Blockvorlage sein.

@ZebulanStanphill Ich stimme zu. Eine erweiterte Konfiguration, mit der Sie auswählen können, ob es sich um einen Abschnitt, eine Kopfzeile, eine Seite oder eine Div (Standard) handelt, wäre hilfreich. Ja, die meisten Benutzer verwenden diese Option möglicherweise nicht, aber sie unterstützt gute Webentwickler.

Wie kann ein Thema integriert werden? Kann ein Thema in diesem Fall einem Block "Variationen" hinzufügen?
Der Abschnittsblock und der Benutzer können direkt einen aus einer Weile auswählen und die resultierenden angewendeten Stile sehen.
Es kann auch sehr hilfreich sein, dem Abschnittsblock einen Filter oder Haken zum Vermieten hinzuzufügen
Ein Thema fügt Wrapper und andere Elemente hinzu, die manchmal für das Styling erforderlich sind.

@ZebulanStanphill @wmodes Ich bezweifle, dass eine Option zur Auswahl des enthaltenen Elements jemals über die Kernentwickler hinausgehen würde. Es ist eine Überkomplikation. Unter einem bestimmten Gesichtspunkt ist das <section> -Element so semantisch wie möglich, da der Benutzer es bereits durch Erstellen des Blocks als "Section" definiert. Es liegt an ihnen, verantwortungsbewusst damit umzugehen, genau wie Überschriften. Aber wenn es das semantische Argument vermeiden würde, habe ich kein Problem mit der Verwendung von <div>.

@mikedance Einverstanden, wir sollten wahrscheinlich nur <div> . Wenn das semantische Layout ein Problem darstellt, wird es am besten als Erweiterung des Containerblocks behandelt.

@strarsis Themes können die vorhandene

@mikedance

Aus einer bestimmten Sicht der

Element ist so semantisch wie es nur sein kann, weil der Benutzer es bereits als "Abschnitt" definiert, indem er den Block erstellt.

Ich glaube, ich verstehe, was Sie sagen, aber ich bin anderer Meinung. In vielen Fällen wird ein Containerblock einfach verwendet, um einem Paar oder sogar nur einem Block, der keine eigenen Hintergrundoptionen (oder andere Stiloptionen) hat, eine Hintergrundfarbe hinzuzufügen. Ein Listenblock, der in einen Container eingeschlossen ist, um ihm eine Hintergrundfarbe zu geben und ihn hervorzuheben, bedeutet nicht, dass sich die Liste in einem eigenen Abschnitt befindet.

Aber ja, <div> ist die neutralste Wahl, da sie keine semantische Bedeutung hat. Wenn es im Kern niemals eine Option zum Ändern des HTML-Elements gibt, ist <div> die beste Wahl.

Der Hauptgrund, warum ich das HTML-Tag auswählen möchte, ist, dass Sie damit einfacher semantische Seiten und Beiträge erstellen können, ohne auf den benutzerdefinierten HTML-Block oder Plugins zurückgreifen zu müssen, die benutzerdefinierte Blöcke hinzufügen. Wenn Sie jetzt ein <section> -Tag in Gutenberg verwenden möchten, müssen Sie am Ende alles in diesem Abschnitt in einen benutzerdefinierten HTML-Block einfügen, wodurch die visuellen Bearbeitungsfunktionen für Dinge wie Absätze, Listen usw., die Sie verwenden, verloren gehen hätte sonst. Vielleicht könnte der Tag-Umschalter im Inspektor unter der Gruppe "Erweitert" angezeigt werden?

@strarsis @ZebulanStanphill

Dokumente zum Hinzufügen von Block Styles im Handbuch finden Sie im Handbuch unter Erweiterbarkeit https://wordpress.org/gutenberg/handbook/extensibility/extending-blocks/#block -style-Variationen

@ajitbohra Danke! Ich habe diese Seite mehrmals überprüft, aber irgendwie habe ich diesen Abschnitt immer wieder verpasst. :Lachen:

@ajitbohra : Danke! Gibt es übrigens eine Demo für Variationen des Gutenberg-Blockstils?

@strarsis

Ja, überprüfen Sie den Kernblock button und quote

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

@strarsis Die pullquote , table und separator haben ebenfalls Stilvariationen:
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

Ich würde wirklich gerne sehen, dass ein Teil des Organisationsblocks erstellt wird. Das aktuelle Problem mit Spalten besteht darin, dass das Erstellen eines einzelnen Spaltenblocks zum Gruppieren von Inhalten (z. B. zum Zweck der gemeinsamen Hintergrundfarbe, des Videos oder des Bilds) nicht intuitiv ist. Ich würde, im Idealfall, wie der Editor , um zu sehen , die Stufe zu erreichen , wo es Inhalte zu schaffen , wie fähig war dies fast ausschließlich im Editor.

Verschieben Sie dies vorläufig für eine 5.1-Version, damit wir etwas mehr Zeit haben, um zu definieren, wie dieser Block dargestellt werden soll.

Während ich darüber nachdenke ... da es eine Überlappung zwischen diesem und dem Cover-Block gibt, was wäre, wenn der Cover-Block eher eine "Konfiguration" wäre, wenn Sie diesen Block hinzufügen, fügt er wirklich einen vorkonfigurierten Section-Bock mit einer Überschrift hinzu oder darin verschachtelter Text- / Absatzblock?

@ JiveDig

Was wäre, wenn der Cover-Block eher eine "Konfiguration" wäre, wenn er diesen Block hinzufügt, fügt er wirklich einen vorkonfigurierten Abschnittsblock hinzu, in dem ein Überschriften- oder Text- / Absatzblock verschachtelt ist?

Das klingt für mich sehr nach einem wiederverwendbaren Block, der als eigenständiger Block eingefügt wird. Möglicherweise könnte der Kern standardmäßig mehrere wiederverwendbare Blockvorlagen enthalten. Die Benutzeroberfläche müsste verbessert werden, um das Einfügen eines wiederverwendbaren Blocks als eigenständiges Element zu vereinfachen. Siehe # 8403.

Wird es eine Gabel zum Testen des neuen Abschnitts / Containerblocks geben? Ich bin daran interessiert, damit zu spielen und zu helfen, es zu testen.

Ein Container / Abschnittsblock ist sehr nützlich, ich musste den verwenden
Advanced Gutenberg Blocks Container Block für jetzt.
Und es ist wichtig, dass der Abschnitt / Containerblock gut sichtbar und auswählbar ist.

Zum Teil kommentieren, um festzustellen, dass ein Abschnittsblock für die Vorlagenentwicklung unglaublich nützlich wäre.

Wir haben gerade einen benutzerdefinierten Abschnittsblock anstelle dieses Kernblocks erstellt und ein Problem festgestellt, bei dem die Blockattribute nicht aktualisiert wurden, wenn der Block gleich blieb, sich die Attribute jedoch änderten.

Dies wurde in PR # 12406 (oben) behoben.

Wird der Abschnittsblock noch für 5.1 (geplant für den 21. Februar 2019) oder später berücksichtigt?

Ich habe ein Abschnittsblock-Plugin geschrieben, das ich für einige Projekte verwendet habe, und hoffe, es als etwas allgemeineres für das Plugin-Repository veröffentlichen zu können. Hiermit können Hintergrundfarben und Bilder oder Videos sowie eine nach Themen definierte Klasse festgelegt werden, um die im Bereich innerblocks enthaltenen Elemente zu formatieren.

In meinen Anwendungsfällen war es für den Client einfacher, vordefinierte (optionale) Titel- und Beschreibungsfelder über einem Innerblocks-Bereich zu haben, in denen sie "Elemente" stapeln konnten, die in meinem Anwendungsfall Pseudo-Widgets waren, die ich mit einem anderen Block erstellt hatte Art. Dies können aber genauso gut einfache verschachtelte Abschnitte sein, in denen der erste Abschnittsblock eine Überschrift, einen Absatz und dann einen weiteren Abschnittsblock enthielt, der wiederum die Elemente enthielt ...

Abschnitte bedeuten, dass gutenberg in der Lage sein muss, ordnungsgemäß mit Abschnitten umzugehen, deren Anzeige auf flex und die flex -Eigenschaften der unmittelbaren Kinder ordnungsgemäß wiederzugeben.

Ich rendere meine Abschnitte in JS, aber der Code enthält eine Reihe von Hacks, die ich für Hacks halte. Das Rendern in PHP wäre ein Kinderspiel ... außer dass das Senden von Innerblocks-Inhalten an PHP immer noch ungelöst ist, nicht wahr?

Spalten, wie sie durch den Spaltenblock implementiert werden, sind eine völlig nicht praktikable Lösung, da sie eine manuelle Kuratierung der Spalten erfordern, was nicht für Handys geeignet ist und das Hinzufügen oder Entfernen eines anderen Elements in einem Set zu einem großen und frustrierenden Problem macht.

"Spalten" in einem Abschnitt sind lediglich eine Flex-Basis-Deklaration und können und sollten ebenso leicht Zeilen sein. Sie sind keine tatsächlichen Container für Elemente, sondern lediglich eine Definition ihres Ablaufs. Bitte beeinträchtigen Sie das Konzept von Abschnitten nicht mit Spalten, die den Containern für darin enthaltene Elemente ähneln.

In einem Abschnitt festgelegte Eigenschaften sollten von Blöcken in diesem Abschnitt leicht erkannt werden können. Ich sollte in der Lage sein, einen Blocktyp zu erstellen, der auf intelligente Weise auf Entscheidungen reagieren kann, die im übergeordneten Element getroffen wurden, wenn es ein übergeordnetes Element hat. So wie es ist, ist es schwierig, etwas über die Attribute eines Elternteils herauszufinden, ohne 1400 Codezeilen zu schreiben.

Blöcke sind verschachtelt, da der übergeordnete / untergeordnete Kontext dieser Blöcke für die Anzeige und Bearbeitung wesentlich ist. Das Vorgeben, dass der Kontext nicht existiert, ist der schlimmste Idealismus.

Verschachtelte Blöcke sollten in der Lage sein, einfach und standardmäßig auf übergeordnete Attribute zu verweisen. Wenn Ihr Ziel darin besteht, Blöcke nur in seltenen Fällen serverseitig zu rendern, muss diese Weitergabe von Kontextinformationen erfolgen, andernfalls wird render() eine Einöde von return null als neu und nützlich sein aber komplizierte Blöcke erscheinen.

(Ich denke, der columns -Block wäre nützlicher, wenn er die [noch experimentelle] CSS columns -Eigenschaft implementieren würde. Es wäre im Wesentlichen eine spezielle Art von section , die alles in Anspruch nimmt die darin enthaltenen Elemente und deren Fluss über die im Inspektor definierten Spalteneigenschaften: column-width , column-count , column-rule usw.)

Gibt es ein Veröffentlichungsdatum für diesen Blocktyp (Block hinzufügen: Abschnitt)?

@JQOz Nein. Dieses Problem steht auf der Roadmap für die nächsten Bürgermeisterversionen, aber es gibt keine Open-Pull-Anfrage, an der die Leute arbeiten. Wenn Sie Ideen oder Funktionen für diesen Block haben, können Sie diese hier hinzufügen.

Hallo,

Ich denke nicht nur einmal darüber nach. Ein Abschnitt sollte ein Container voller Breite sein. Können wir dem Container innerhalb eines Abschnitts einfach eine Rinne hinzufügen und dafür sorgen, dass sie wie add_theme_support('alignwide') funktionieren oder nicht?

Für einen Fall:

https://tech.cornell.edu/

Wir haben viele verschiedene Abschnitte. Einige von ihnen leben in einem Container. Einige sind es nicht. Aber alle brauchen einen einzigen Container.

Die Gutenberg- Spaltenblöcke sind zu verschachtelt und helfen nicht viel. Es sollte einer Rasterstruktur folgen und die Klasse parent> child verwenden, damit sie weiter funktionieren.

Wenn ich eine https://www.luminasolar.com/-Entwicklung durchführe , muss ich sie in einen template -Schlüssel einschließen, um eine Struktur beizubehalten.

Ich schlage vor, dass im Rahmen der Strategie für das Seitenlayout einige Überlegungen angestellt werden, einen Hook / API für Theme- und Plugin-Entwickler von Seitenerstellern von Drittanbietern bereitzustellen, um ihre eigenen Schnittstellen und Schnickschnack hinzuzufügen.

Nach diesem Artikel in WPTavern scheinen Benutzer ein Problem mit der Standardisierung zu erkennen und sich auf bestimmte Blöcke für das Layout festzulegen, um zur alten Kastanie eines Problems zurückzukehren, das seit vielen Jahren ein Problem darstellt: Ändern Sie das Thema oder den Seitenersteller und das Layout verschwindet oder im Fall des neuen Blockeditors anscheinend Code, der nicht geändert werden kann, weil er in Stein gemeißelt ist.

Ein gemeinsames Standardlayout, das CoBlocks, Kadence (oder was auch immer Sie selbst haben) überschreiben können, würde dieses Problem lösen. Ändern Sie das Plugin oder das Thema, und zumindest Ihr Inhalt behält das gleiche Grundlayout bei.

Dies ist im Grunde die einzige fehlende Funktion, die mich dazu bringt, Elementor auf meinen Websites zu behalten ...

Nach diesem Artikel in WPTavern scheinen Benutzer ein Problem mit der Standardisierung zu erkennen und sich auf bestimmte Blöcke für das Layout festzulegen, um zur alten Kastanie eines Problems zurückzukehren, das seit vielen Jahren ein Problem darstellt: Ändern Sie das Thema oder den Seitenersteller und das Layout verschwindet oder im Fall des neuen Blockeditors anscheinend Code, der nicht geändert werden kann, weil er in Stein gemeißelt ist.

Ein gemeinsames Standardlayout, das CoBlocks, Kadence (oder was auch immer Sie selbst haben) überschreiben können, würde dieses Problem lösen. Ändern Sie das Plugin oder das Thema, und zumindest Ihr Inhalt behält das gleiche Grundlayout bei.

Ja Ja Ja! Ich glaube, dass ein flexibler Abschnittsblock das größte fehlende Merkmal von Gutenberg ist. Ich bin froh zu hören, dass es für eine zukünftige Veröffentlichung geplant ist, aber enttäuscht, dass derzeit niemand daran arbeitet. Ohne dies können Benutzer immer noch keine gängigen Seitenformate gestalten, und Themenentwickler müssen immer noch auf proprietäre Techniken zurückgreifen, um dahin zu gelangen, wo ein Benutzer tatsächlich ein einigermaßen allgemeines Seitenlayout erstellen kann.

Der Abschnittsblock MUSS sich im Kern von Gutenberg befinden (und durch Themen konfigurierbar und erweiterbar sein), um endlich die Probleme zu lösen, komplexere Seiten anlegen und trotzdem Themen wechseln zu können.

Klar, als Themendesigner werde ich meine eigene Farbpalette hinzufügen, Ränder und Auffüllungen so steuern, dass sie zu meinen Themen passen, Bilder passend formatieren und all diese Arten von themenspezifischen "Design" -Dingen ... aber ein Benutzer sollten in der Lage sein, zu einem beliebigen WordPress-Thema zu wechseln und zumindest deren Inhalt im Wesentlichen im gleichen Layout (gruppierte Abschnitte, Spalten usw.) beizubehalten und als Gutenberg-Block bearbeitbar zu sein (ohne zum benutzerdefinierten HTML-Block wechseln zu müssen).

Ich habe ein Abschnittsblock-Plugin, für das ich eine frühe Version der Arbeit habe, und hoffe, dass ich es später in dieser Woche aktualisieren und an das Repository senden kann. Es erlaubt eine unendliche Verschachtelung des Blocks (ich meine, im Rahmen der Vernunft, nehme ich an). Mit dem Plugin können Themen oder Plugins bei Bedarf auch ihre eigenen Abschnittsstile definieren, die dann vom Benutzer ausgewählt werden können. Ich habe vor, nur einige Standardstile aufzunehmen, die bei Bedarf durch Themen deaktiviert werden können.

Inspektorfelder

• _Background._ Mein Plugin ermöglicht das Einstellen der Hintergrundfarbe und / oder des Bildes, falls gewünscht, mit Steuerelementen zum Platzieren, Überblenden, Entsättigen und sogar Überlagern einer Farbe.
• _Dimensions, Padding, Margins._ Standardmäßig werden die Abschnitte automatisch auf den Inhalt angehoben und befolgen die vollständigen, breiten und mittleren Ausrichtungen, wobei links und rechts bei 45% liegen. Das heißt, ich werde Steuerelemente hinzufügen, um eine bestimmte Breite und / oder Höhe zuzulassen, und die InnerBlocks und den Rand um den Block herum auffüllen. Aber siehe unten für Probleme mit Gutenberg.
• _Columns ... and Rows._ Nach vielen Experimenten mit Flex ist CSS _grid_ für die unmittelbaren Kinder die beste Methode, wenn Sie ein spaltenbasiertes Layout suchen. Die Verwendung von Raster ist ein Umschalter. Ansonsten sind die Kinder nur normale Blöcke. (Ehrlich gesagt, obwohl Zeilen machbar sind, fügen sie der Bearbeitungsoberfläche eine Menge Komplexität hinzu, die am besten durch Hinzufügen eines neuen Abschnitts unter dem, an dem Sie arbeiten, wenn Sie eine neue Zeile beginnen müssen, behandelt werden kann.) Das Raster ist überlegen flex - auch wenn Sie nur Spalten ausführen - da flex eine bestimmte, nicht prozentuale Höhe erfordert, die entweder für den Container oder die untergeordneten Elemente festgelegt werden muss, wodurch viel Flexibilität verloren geht.

Handy, Mobiltelefon
Ein Problem bei jedem Abschnitts-Plugin, das Grid verwendet, ist, was mit dem Grid an definierten mobilen Haltepunkten passiert. Benutzer (oder Themenautoren) sollten in der Lage sein zu definieren, wann in einem Abschnitt 3 Elemente über 2 Elemente bis zu 1 Element angezeigt werden.

Die Haltepunkte müssen durch das Thema definiert werden können und nicht wirklich das Gefühl haben, zum Block selbst zu gehören, da dadurch eine weitere große Auswahl an Inspektoren hinzugefügt wird und Sie wahrscheinlich möchten, dass Ihre Haltepunkte über Beiträge und Seiten hinweg konsistent sind . Bei Verwendung der Rasteroption muss der Block jedoch über Haltepunkte Bescheid wissen und dem Benutzer (oder Thema) ermöglichen, anzugeben, wie sich das Abschnittslayout an diese anpasst.

Ich bin mir sicher, dass es einen eleganten Weg gibt, dies zu tun, aber der Zweckmäßigkeit halber erlaube ich dem Block einfach, über die Konfiguration über Haltepunkte zu "lernen" und dann eine durch Kommas getrennte Liste von Werten für die definierten zu verwenden Haltepunkte (stellen Sie sich hier einen Screenshot vor):

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

Usw. (Offensichtlich sind einzelne Spalten 100% und müssen nicht angegeben werden).

Überlegungen zu Themen und Plugins
Ein Thema (oder Plugin) kann einen Abschnitt mit all seinen Attributen definieren und all diese Attribute vor dem Benutzer verbergen, um sie vor möglicher Verwirrung zu bewahren, oder das Thema kann nur die Dinge offenlegen, die der Benutzer ändern kann (Zum Beispiel das tatsächlich ausgewählte Hintergrundbild). Themen oder Plugins können auch mithilfe ihres Stylesheets Schnörkel hinzufügen, um Abschnittsarten anzugeben. Theoretisch könnten theoretisch alle meine Inspektorfelder ignoriert, alle Inspektorfenster vor dem Benutzer ausgeblendet und Dinge vollständig mit ihrem Blatt formatiert werden. Dies beseitigt jedoch die Möglichkeit für Benutzer, einen Themenwechsel mit intakten Abschnitten zu überleben.

Benutzerüberlegungen
Angenommen, das Thema hat gut gespielt und die verschiedenen Pfade in meinem Block verwendet, um einen Abschnitt und seine Attribute "richtig" zu definieren. Wenn das Thema geändert wird, bleiben alle diese Attribute erhalten, und wenn das Thema sie bisher vor dem Benutzer versteckt hat, wieder ausgesetzt. Dies liegt daran, dass die oberste Auswahl in der Auswahl "Vorgestalteter Abschnitt" "Benutzerdefiniert" ist, mit der der Benutzer alles ändern kann und die der Block standardmäßig verwendet, wenn der zuvor ausgewählte Stil nicht mehr verfügbar ist. Alle Einstellungen des Themas, die NICHT direkt als Stylesheet ausgewählt wurden, bleiben erhalten.

Dies garantiert nicht, dass Ihr Abschnitt auf eine Weise überlebt, die gut aussieht (möglicherweise hatten Sie ein Thema mit einem sehr breiten Layout und wechseln zu einem mit einem schmalen Layout, sodass ein Abschnitt mit sechs Spalten möglicherweise nicht mehr die beste Wahl ist ... aber es bleibt dort intakt. Benutzer können dieses Layout als wiederverwendbaren Block speichern.

Wenn Sie bei der Auswahl von Abschnittsstilen von einem vordefinierten Abschnitt zu einem benutzerdefinierten wechseln, folgen die Inspektorattribute des vordefinierten Abschnitts. Auf diese Weise können Benutzer einen vordefinierten Abschnitt ändern, ohne die Definition dieses Abschnitts im Thema oder ändern zu müssen Plugin.

Gutenberg-Probleme
Gutenberg macht also folgendes schlecht:

• Blöcke, die vertikal aneinander gestoßen werden müssen, die Sie manchmal abbilden können, müssen Abschnitte sein.
• Jede Art von Anruf, um etwas als Flex oder Grid anzuzeigen. Aufgrund der Div-Suppe des Editors müssen Sie Ihren CSS-Aufruf im Innerblocks-Wrapper auf grid oder flex deaktivieren und in einem der Editorblöcke zurücksetzen.
• Links ausrichten und rechts ausrichten. Ich habe einen Fehler gemeldet, aber da Gutenberg den Gleitkommawert eines linken oder rechten Blocks nicht nur auf das unmittelbare untergeordnete Element des Blocks mit dem Datenattribut links oder rechts (oder in der Mitte) beschränkt, werden alle nachfolgenden verschachtelten Blöcke nach links oder links verschoben Recht.
• Das Hinzufügen neuer Blöcke ist oft ein komplettes Rätsel, wo sie eingefügt werden. Sie denken, Sie befinden sich am Ende Ihres Abschnitts und möchten einen neuen internen Block. Stattdessen fügt der Editor einen am Ende Ihres Dokuments ein
• Das Gutenberg-Drag / Drop-Modell zum Verschieben von Blöcken funktioniert nicht zuverlässig mit Blöcken, die eine horizontale Position haben können

Probieren Sie es aus
Ich werde einen Link in diesem Thread posten, wenn ich eine Version auf Github ablege, die meiner Meinung nach einen Blick wert ist, wenn jemand interessiert ist. Ich habe ein paar Monate damit verbracht, und es ist wahrscheinlich immer noch nicht großartig, aber es ist etwas.

Ich sollte hinzufügen, dass ich fest davon überzeugt bin, dass Dinge wie Schriftarten, Überschriftengrößen usw. keine Dinge sind, über die der Abschnittsblock direkt etwas sagen sollte. Die Inspektorattribute, die ich einstelle, fühlen sich für mich wie die Grundlagen an, die erforderlich sind, um die "Big-Picture" -Attribute eines Abschnitts von Thema zu Thema beizubehalten oder um zu verhindern, dass das Entfernen eines Plugins das Erscheinungsbild einer Site vollständig beeinträchtigt.

@rogerlos Sie sollten sich Kadence Blocks ansehen. Sie scheinen mit den auf Flexbox basierenden Spalten ziemlich gut umzugehen.

Ich sollte hinzufügen, dass ich fest davon überzeugt bin, dass Dinge wie Schriftarten, Überschriftengrößen usw. keine Dinge sind, über die der Abschnittsblock direkt etwas sagen sollte.

Dem stimme ich voll und ganz zu. Die einzige Ausnahme wäre die Einstellung "Schriftfarbe" auf Abschnittsebene. Dies ist erforderlich, da eine Site, deren Schriftarten hauptsächlich dunkel sind, innerhalb eines Abschnitts mit einem dunklen Hintergrundbild / Overlay nicht ausreichend kontrastiert.

Hier ist eine Demo, wie der Zeilenlayoutblock von Kadence die "Ausrichtungsmodi" in der Blocksymbolleiste wiederverwendet, um drei verschiedene innere Inhaltsbreiten, einstellbare Spaltenbreiten, einstellbare obere / untere Zeilenränder sowie Hintergrund- und Textfarbeneinstellungen zu ermöglichen.

Diese Einstellungen für die maximale Breite des Inhaltsabschnitts sind fast die einzigen global wiederholten (und daher themendefinierten) Muster, die ein Abschnittsblock berücksichtigen muss (abgesehen von global vererbten Komponentenbeschränkungen wie zulässigen Schriftfarben, Spaltenrinnengrößen usw.). )

Aufgrund der Erfahrung mit Webagenturen gibt es in keinem Design, das ich erhalten habe, mehr als drei verschiedene Inhaltsbereichsbreiten. Alles außerhalb dieser drei Breiten ist in der Regel eine inhaltsspezifische Variation, die sich absichtlich und nicht wiederholend von den Entwurfsmustern des Themas löst.

Ein guter Abschnittsblock führt Benutzer zu themendefinierten Standardeinstellungen (gemäß den Mustern des ursprünglichen Entwurfs), ermöglicht ihnen jedoch gelegentlich, sich in angemessener Weise von diesen Mustern zu lösen.

Um ein konsistentes und vorhersehbares Layout über alle Bildschirmgrößen hinweg zu erzwingen, sind in unserem Setup auf Stammebene keine "textorientierten" Blöcke zulässig.

Alle Nicht-Bild- / Einbettungsblöcke müssen in einem "Abschnitt" (Kadence-Zeilenlayout) auf Stammebene enthalten sein, der die Inhaltsabschnittsbreiten unseres Themas erzwingt und dennoch vollständig anpassbare Zeilen mit einer beliebigen Anzahl von Spalten sowie Hintergrund mit voller Breite zulässt Optionen usw.

Containerelemente sollten auch Ebenenelemente zum Stapeln zulassen (Z-Index).
Dies ermöglicht beispielsweise ein Videoelement oder einen Schieberegler als Hintergrund oder einen Parallaxeeffekt.

@strarsis Gute Idee.

Im Idealfall würde ein Abschnittsblock den Z-Index verwenden, um einen umschaltbaren Vordergrund- / Hintergrundbearbeitungsmodus bereitzustellen.

Auf diese Weise erfindet der Abschnittsblock selbst das Hintergrundbild / Overlay-Material nicht neu, das alle im integrierten Cover Image-Block verfügbar ist.

Der Hintergrundinhalt würde nicht durch die Breite eingeschränkt, und daher sollten Themenentwickler die Möglichkeit haben, zu definieren, welche Blöcke in einen Abschnittshintergrund eingefügt werden können. Die Breite des Vordergrundinhalts wäre auf eine bestimmte Anzahl von maximalen Breiten beschränkt, die vom Thema bereitgestellt werden.

Sollte der Benutzer bei einem bestimmten Inhalt von einer Standardbreite abweichen müssen, kann er einen Abschnitt mit der nächstgrößeren Breite auswählen und die Seiten entsprechend auffüllen.

Fälle , in denen Vordergrund Inhalt Bedürfnisse visuell außerhalb eines Abschnitts des max-width brechen sollten als registriert seinen Stil Variation dass paßt eine negative Marge auf diesem bestimmten Block.

Der Grund dafür ist, dass Benutzer zwar die Auffüllwerte ziemlich sicher anpassen können, wir jedoch definitiv nicht möchten, dass negative Ränder benutzerdefiniert sind.

Das Zulassen der negativen Ränder der Definition im Editor wäre ein Chaos, wenn auf unterschiedliche Bildschirmgrößen, Seitenauffüllungen des Inhaltsbereichs, Rinnenbreiten an bestimmten Haltepunkten usw. reagiert wird, und sollte daher eng mit dem Thema / Code gekoppelt und als übergeordnete Abstraktionen angezeigt werden an den Endbenutzer.

In Bezug auf die Entwicklersteuerung: Es gibt das Mesh-Plugin , das "harte" Container bereitstellt.
was durch das Thema erzwungen werden sollte.
Ein Thema muss manchmal die verfügbaren Bereiche einschränken, z. B. nur die obere linke Ecke der gesamten Seite.
Gutenberg sollte einen Mechanismus für Themen bereitstellen, mit dem diese "harten" Container in seinem Seiteneditor festgelegt werden können.

@strarsis Meiner Meinung nach hat alles, was außerhalb des Bereichs the_content() passiert, im Gutenberg-Editor nichts zu suchen .

Diese „Bereiche“ sind ein Teil der Seitenvorlage und nicht der Inhalt der Seite und sollen an anderer Stelle behandelt werden.

Seiteninhalt vs. Seitenvorlage (/ Layout)

Die Inhalte / Abschnitte im Editor sollten davon ausgehen, dass das umgebende Layout (während der Bearbeitung) nicht vorhanden ist, und stattdessen so ausgestattet sein, dass sie angemessen reagieren, wenn sie in einem bestimmten Layout (am Frontend) platziert werden.

Ein Element ist Teil einer Seitenvorlage ( und nicht des Seiteninhalts ), wenn:

1. Das Element definiert oder hängt von der Strukturierung, den Grenzen oder der Positionierung des the_content() -Bereichs als Ganzes ab
2. Das Element ist Teil eines sich wiederholenden Musters (dh möglicherweise bei zwei oder mehr Permalinks zu sehen).

Einige erfahrungsbasierte Hintergründe

Wiederholte Vorlagen- / Layoutelemente sind normalerweise spezifisch für einen benutzerdefinierten Beitragstyp und umfassen Inhaltshelden, Inhaltsseitenleisten und Inhaltsfußzeilen.

In jedem einzelnen Fall habe ich festgestellt, dass der Inhalt dieser Layoutelemente ausreichend von Informationen abgeleitet ist, die sich in benutzerdefinierten Feldern, Taxonomien oder anderen Einstellungen auf Post-Ebene und nicht auf Blockebene befinden.

Und in jedem einzelnen Fall habe ich meine Überzeugung bekräftigt, dass es ein unglaubliches Unterfangen wäre, diese Abschnitte jemals in großen Mengen zu modifizieren oder neu zu gestalten, wenn sie als Blöcke im Gutenberg-Editor implementiert worden wären.

So endlich

Die Definition (und eventuelle Implementierung) eines Abschnitts sollte nur so weit reichen, dass die Anforderungen der Entwurfsmuster des Themas in Bezug auf the_content() berücksichtigt werden.

Alles, was unter "Vorlage" und nicht unter "Inhalt" fällt, sollte (vorerst) außerhalb eines Abschnittsblocks und außerhalb des Gutenberg-Editors behandelt werden.

Ich möchte, dass Gutenberg in der Lage ist, Vorlagen genauso wie alle anderen inline mit Inhalten zu erstellen, aber wir scheinen noch nicht da zu sein, und wir sollten diesen Abschnittsblock definitiv festnageln, bevor wir mit Vorlagen angemessen umgehen können.

Vor ein paar Tagen wollte ich ein grundlegendes Layout erstellen und brauchte dieses. Also habe ich Plugin A installiert, es ausprobiert und war fehlerhaft. Deinstalliert, Plugin B gefunden, installiert, seinen Abschnittsblock ausprobiert, es war baaad. Als nächstes Plugin C Buggy, Plugin D nannte es einen Container und es war meh. Nächstes Plugin E, F .........
Ich kann Ihnen versichern, dass das aktuelle Gutenberg- "Ökosystem" sehr, sehr frustrierend ist, wenn Sie eine Seite erstellen und Inhalte schreiben möchten.
Die Tatsache, dass die Leute hier immer wieder sagen "Schau dir Plugin X an", "Wenn du diese Funktion haben willst, installiere Plugin Y" usw., ist ein klarer Hinweis darauf, dass die Leute dies brauchen. Sie wollen es nicht, sie brauchen es. Im Moment gibt es ein Dutzend Plugins, die alle eine eigene Implementierung eines Containers / Abschnitts / wie auch immer Sie es nennen möchten.
Ich sage nicht, dass Gutenberg jedes Feature unter der Sonne hinzufügen sollte, aber dies ist ein grundlegendes. Es muss da sein. Es muss nicht jede erdenkliche Option haben, aber die Grundlagen sollten vorhanden sein und Entwickler können bei Bedarf erweitert werden.
Wir erreichen einen Punkt, an dem es 20 verschiedene Implementierungen für einen Basiscontainer geben wird und keine davon so funktioniert, wie sie sollten (persönliche Meinung natürlich).

Als einfache Alternative habe ich einfach einen Spaltenblock verwendet und die Anzahl der Spalten auf 1 gesetzt (der Schieberegler ist zwischen 2 und 6 begrenzt, aber Sie können 1 in das Eingabefeld eingeben). Danach müssen Sie CSS im Admin reparieren:

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

Und natürlich müssen Sie dasselbe auch in Ihrem Frontend festlegen, aber das ist ein Thema. Ich denke, ein einziges Spaltenlayout würde für eine grundlegende Containeroption ausreichen, die normalerweise sowieso für Stylingzwecke benötigt wird. Alles andere (wie das Einstellen eines Hintergrunds, eines Z-Index, einer Parallaxe usw.) sollte mit den Plugins imo erfolgen.

Und bitte fügen Sie dem Thema (Entwicklern) ein Mittel hinzu, um zu steuern, wie viele und welche Wrapper verwendet werden.
Einige Designs benötigen nur mehr als ein Element. Derzeit muss ich ein anderes Plugin für ein Containerelement verwenden und dann den gesamten Inhalt mit einem PHP-Parser analysieren, um den Containerinhalt in zusätzliche Wrapper-Elemente für das Styling zu verpacken.

@strarsis Dies ist definitiv etwas, das von Anfang an hätte getan werden sollen.

Um den Inhalt des Beitrags anständig zu gestalten, muss jedes untergeordnete Element auf Stammebene in einer konsistenten Zeile / einem konsistenten Abschnitt platziert werden.

Ohne jede Zeile zu umbrechen, ist es beispielsweise schwierig und schwierig, Abschnitte mit unterschiedlichen Breiten (insbesondere Abschnitte mit voller Breite) zu erstellen.

Ich habe auch die PHP-Analyseoption in Betracht gezogen, aber festgestellt, dass der Inhaltseditor dadurch keine Kontrolle darüber hat, in welcher Art von Abschnitt sich ein bestimmter Inhalt befindet.

Stattdessen erzwingen wir in unserem Setup alle Instanzen des Gutenberg-Editors, nur einen einzelnen Containerblock auf Stammebene für einen Beitrag / eine Seite / einen Beitragstyp zuzulassen.

Der Stammcontainerblock erzwingt eine begrenzte Teilmenge von Blöcken, die innerhalb hinzugefügt werden können.

Um Text oder Blöcke mit nicht voller Breite hinzuzufügen, müssen Sie zuerst ein Kadence-Zeilenlayout einfügen, das in diesem Fall als unser Hauptabschnitt-Wrapper-Element fungiert.

Ein einfacher erweiterbarer Containerblock ist alles, was innerhalb des Kerns erforderlich sein sollte. Das Erweitern dieses Blocks in Bezug auf das Styling sollte Plugin / Theme-Entwicklern überlassen bleiben. Es sollte auch einen Fallback-Transformationsstatus für Entwickler bereitstellen, die ihre eigenen Containerblöcke erstellen möchten.

Alle vorhandenen Plugins von Drittanbietern, die von mir getestete Container / Abschnitte / Zeilen bereitstellen, unterliegen einem erheblichen Problem hinsichtlich der Inhaltssperre. Nach Deaktivierung dieser Plugins ist der Inhalt des inneren Blocks im Editor nicht mehr zugänglich, und durch das Konvertieren wird der HTML-Code entfernt. Etwas, dessen sich Benutzer voll bewusst sein sollten.

Sehen:
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

In Ordnung. Ich habe Gutengerg getestet, es ist gut, aber ja, es fehlt definitiv die Abschnittssache.
Um wahr zu sein, haben viele Blöcke ihren Container, zu dem wir eine CSS-Klasse hinzufügen können, und sie formatieren. Der Hauptinhalt wird jedoch ohne Container geschrieben, also auch ohne Klasse, und daher können wir ihn nicht formatieren. Und da der Hauptinhalt in derselben Phase wie alle anderen Blöcke geschrieben wird, ist es äußerst schwierig, ihn anders als die anderen zu verpacken.

Mit anderen Worten, ich werde zum Klassiker zurückkehren und warten, bis Sie uns Abschnitte geben.

Vielen Dank, Grüße.

Ja, das ist absolut richtig. Ich denke, es ist noch wichtiger als alle anderen Blöcke, die derzeit entwickelt werden. @youknowriad Kannst du es nicht mehr Priorität geben?

Es ist bereits im Phase-2-Bereich https://github.com/WordPress/gutenberg/issues/13113. Wenn jemand bereit ist, es zu versuchen, tun Sie dies bitte.

@youknowriad Ich fürchte, ich bin kein Entwickler. Aber ich erinnere mich, dass die Entwicklung bereits im Gange war. Kurz vor der Veröffentlichung von Wordpress 5 gab es eine PR, die bereits sehr weit fortgeschritten war. Es waren noch Details zu klären, aber es war fast fertig. Leider kann ich die PR nicht mehr finden. Hat jemand eine Idee wo das ist?

Ja, mach dir keine Sorgen, ich verstehe.

Hier ist die PR. https://github.com/WordPress/gutenberg/pull/10562

Ich wollte klarstellen, dass es sich um ein Open-Source-Projekt handelt, das auf Freiwilligenarbeit basiert. Ich kann eine globale Richtung vorgeben, um Hilfe bitten, aber keine Leute zuweisen. Die Leute neigen dazu, anders zu denken.

Ich bekräftige, dass Entwickler, die dies schneller sehen und helfen möchten, zu den wöchentlichen Besprechungen im Core Slack # Core-Editor-Kanal (und den Besprechungen) eingeladen sind und diskutieren / zusammenarbeiten / um Hilfe bitten.

Ahhh ja das war's! Großartig! Du hast einen Überblick !!!

Ja, das stimmt und es sollte kein Vorwurf sein. Was ich mich einfach gefragt habe: Gibt es keine wichtigen und noch wichtigeren Aufgaben? Wenn 50 Personen einen RSS-Block benötigen, 1000 jedoch einen Containerblock, ist es sinnvoll, das Ganze genauer zu fokussieren. Der Containerblock ist jetzt nichts Exotisches. Ich denke, dies ist die Basis für jedes Design.

Bitte nicht falsch verstehen: Sie machen einen tollen Job. Und Sie als Phase-2-Leader leisten erstklassige Arbeit. Es geht nur um die Frage der Fokussierung. Ich werde das beim nächsten lockeren Chat anstoßen ... ;-)

Vielen Dank nochmal!

Vielen Dank und gerne zu klären. Ich gebe ihnen persönlich die gleiche Bedeutung. Ein Zwischenschritt für Phase 2 ist die Verwendung von Blöcken im Widgets-Bildschirm. Selbst wenn Benutzer nicht nach einem RSS-Block fragen, werden sie, sobald der Widgets-Bildschirm (was ein wichtiger Schritt für Phase 2 ist) Blöcke verwenden, das RSS-Widget, das sie verwenden, nicht finden beschwere dich darüber.

Diese beiden Aufgaben sind in Bezug auf die Komplexität "mittlere" Aufgaben. Sie sind in Bezug auf Funktionen wichtig, aber in Bezug auf das Framework nicht wichtig. Meine persönliche hohe Priorität im Moment sind die Rahmenbedingungen, die Phase-2-Ziele ermöglichen würden (Blöcke im Widgets-Bildschirm, Editor außerhalb von post_content), da diese kontextuellen Probleme eher früher als später zum Experimentieren und Klären wichtig sind.

In Ordnung. Ich habe Gutengerg getestet, es ist gut, aber ja, es fehlt definitiv die Abschnittssache.
Um wahr zu sein, haben viele Blöcke ihren Container, zu dem wir eine CSS-Klasse hinzufügen können, und sie formatieren. Der Hauptinhalt wird jedoch ohne Container geschrieben, also auch ohne Klasse, und daher können wir ihn nicht formatieren. Und da der Hauptinhalt in derselben Phase wie alle anderen Blöcke geschrieben wird, ist es äußerst schwierig, ihn anders als die anderen zu verpacken.

Mit anderen Worten, ich werde zum Klassiker zurückkehren und warten, bis Sie uns Abschnitte geben.

Vielen Dank, Grüße.

Dies ist die Haltung, die ich zu diesem und anderen Mängeln des neuen Blockeditors einnehme, bis er sich formt. Hoffentlich passiert dies, da der neue Editor einige nette Aspekte aufweist.

Ein Abschnittsblock wäre fantastisch. Was kann ich tun, um zu helfen, obwohl mir Backend-Entwicklungsfähigkeiten fehlen?

Es gibt jetzt eine Menge Block-Plugins, aber der einzige Block von ihnen, den ich möchte, ist ein Abschnitt oder ein Containerblock, daher würde ich gerne einen hinzufügen sehen.

Der WordPress-Kern muss eine eigene Implementierung einer Layoutstruktur für Abschnitte, Zeilen und Spalten für den Blockeditor enthalten, die Standard ist und von allen Plugins, Designs und Seitenerstellern von Drittanbietern verwendet werden kann. Wie ich schon oft erwähnt habe, sollte eine API bereitgestellt werden, damit diese ihre eigenen Schnittstellen, Schnickschnack hinzufügen können. Wenn Sie eine dieser Lösungen von Drittanbietern deaktivieren, bleibt Ihre Seitenstruktur erhalten.

Es gibt zwar Lösungen von Drittanbietern für Abschnitte / Zeilen, die aus allen Richtungen stammen. Sobald Sie jedoch native Kernblöcke und Blöcke von Drittanbietern einmischen, treten viele Inkonsistenzen und Blöcke auf, die abstürzen und behoben werden müssen. Nicht dass ich die Bemühungen derer kritisieren möchte, die diese Lösungen für das Layout anbieten, sie füllen eine dringend benötigte Funktion aus. Viele von ihnen sind gut, aber etwas stimmt nicht mit der Gesamterfahrung überein.

Ich bin alles dafür, den Kernblock-Editor einfach zu halten, damit Dritte zusätzliche Funktionen und Raffinesse hinzufügen können, aber er muss wirklich verbessert werden, da es sonst nicht einfach ist, eine gewisse Zugkraft bei seiner Akzeptanz zu erzielen.

Die große Frage hier ist, wer sich darum kümmert. Gibt es nicht einige Entwickler, die die Zeit und Energie haben, dies zu tun?

Ja Ja Ja! Ich glaube, dass ein flexibler Abschnittsblock das größte fehlende Merkmal von Gutenberg ist.

Ich kann nicht einmal glauben, dass es noch nicht existiert ...

Eine Alternative wäre, dem Spaltenblock zu erlauben, nur eine Spalte zu haben und Hintergrundfarben für Spalten festzulegen. TA-DA: Abschnittsblock.

Nun, wenn es jemandem hilft: Wir haben vor einiger Zeit einen Abschnitt Block für unsere Projekte geschrieben. Ich bin sicher, dass es an einigen Stellen schön sein kann, aber es könnte ein guter Ausgangspunkt sein:

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

Ich werde meine Hand heben, um daran zu arbeiten. Ich werde ab Mitte nächster Woche damit anfangen können

@chrisvanpatten - es sieht so aus, als hättest du vorher wirklich gute Fortschritte gemacht, wolltest nur überprüfen, ob ich damit

Ich habe einige Containerblöcke von Plugins verwendet. Ich denke, die Hauptanforderungen sind die Unterstützung einer breiten und vollständigen Ausrichtung, Floats und Steuerelemente zum Ändern des Hintergrunds des Containers. Das Ziel, dies in einer ersten Version zu versenden, bietet eine gute Grundlage für weitere Verbesserungen.

Ich denke, die erste Verbesserung besteht darin, mehr Wrapper außerhalb eines Blocks hinzuzufügen.

Zum Beispiel:

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

Im Moment werden viele Elemente direkt eingefügt. Verhindern Sie, dass wir das Styling anwenden, um einen Wrapper zu erstellen.

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

Kann Wrapper hinzufügen:

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

Dann können wir das Containerset anwenden, um die Übereinstimmung aufrechtzuerhalten:

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

@talldan Würde es Ihnen etwas werfen? Es wäre gut, wenn Sie Ihre Eingabe mit der Notwendigkeit eines Core Container-Blocks erhalten würden, um einen "
https://github.com/WordPress/gutenberg/issues/13391#issue -401130412

Abschnittsblöcke wären fantastisch, aber bitte machen Sie es nur als semantisches Markup! Wenn Sie die Dinge in einer semantischen HTML-Struktur belassen, wird die agnostischste Codebasis erstellt.
<section>, <article>, <header> ist viel besser <div class="wp-section"> oder was auch immer.

@talldan Entschuldigung, ich habe deinen Kommentar verpasst, aber ich bin zu 100% damit einverstanden, dass du das annimmst. Ich bin sicher, du wirst es rocken!

Es wäre auch großartig, den Schwerpunkt des Text- und Medienblocks Nr. 10925 verwenden zu können. Dies ist natürlich nur dann sinnvoll, wenn Sie einen Bildhintergrund haben.

Eine großartige Sache, die übrigens auch viele Seitenersteller haben. Oder zumindest so etwas:

Einverstanden, ein Schwerpunkt Picker wäre hier großartig. Es funktioniert wirklich gut im Abdeckblock!

In diesem Sinne habe ich meine früheren Modelle für einen Abschnittsblock aktualisiert. Es fungiert lediglich als Containerelement mit einer einstellbaren Hintergrundfarbe und einem einstellbaren Bild.

Vorschau :

Den Prototyp können Sie hier ansehen .

Einige zusätzliche Hinweise:

• Ich denke, wir sollten es ohne Hintergrundbild starten, nur Hintergrund- / Textfarbe. Sobald wir das herausbringen, können wir als nächstes ein Hintergrundbild einbauen. Dies bringt es schnell heraus, indem vorhandene Muster verwendet werden, und sollte dennoch eine große Anzahl von Anwendungsfällen abdecken.
  
  
  
  • Sobald wir die erste Version zusammenführen, werden möglicherweise Hintergrund- und Textfarben aus dem Textblock entfernt. Stattdessen könnten wir Inline-Farboptionen / Hervorhebungsoptionen im Absatzblock haben. Dies scheint ein insgesamt besseres Muster für Absätze zu sein.
  
  
• Dieser Block würde keine reaktionsfähigen Einstellungen enthalten, da es sich immer nur um einen Container handelt. Der Inhalt innerhalb des Containers (wie ein Spaltenblock) würde das Reaktionsverhalten liefern.

Ich bin damit einverstanden, dass das Hintergrundbild bei Bedarf vorerst mit CSS hinzugefügt werden kann: +1:

Sobald wir die erste Version zusammenführen, werden möglicherweise Hintergrund- und Textfarben aus dem Textblock entfernt. Stattdessen könnten wir Inline-Farboptionen / Hervorhebungsoptionen im Absatzblock haben. Dies scheint ein insgesamt besseres Muster für Absätze zu sein.

Einer der Gründe, den Abschnittsblock als die richtige Stelle für Farben auf Blockebene zu betrachten, besteht darin, dass wir ansonsten antworten müssen, warum die Liste, die Überschrift und andere grundlegende Textblöcke diese Farboptionen nicht haben. Und da diese auf Blockebene aufgeteilt werden, können Sie niemals ein Hintergrundbild erhalten, das alle diese Elemente kontinuierlich umfasst, während ein Abschnittsblock dies behebt.

Die Möglichkeit, diese Farben zu verwerfen, besteht möglicherweise darin, nur die Benutzeroberfläche zu entfernen, vorhandene Blöcke jedoch unverändert zu lassen.

Nett! Wäre nützlich, kleine / mittlere / große Klassen für die vertikale Polsterung zu haben.

Nett! Wäre nützlich, kleine / mittlere / große Klassen für die vertikale Polsterung zu haben.

Dies geht in die Themen- / Framework-Ebene über, und ich bin mir nicht sicher, ob der Kern Platz für etwas wie https://cdn.vaadin.com/vaadin-lumo-styles/1.4.1/demo/sizing-and-spacing hat .html

Ich denke, wir sollten es ohne Hintergrundbild starten, um zu beginnen

Konnte nicht mehr zustimmen. Holen Sie sich eine v1 heraus und dann kann v2 die komplexeren Funktionen hinzufügen.

Dieser Block würde keine reaktionsfähigen Einstellungen enthalten

Einverstanden - dieser Block sollte so einfach und unpopinioniert wie möglich sein.

Ich denke, wir sollten diese PR wenn möglich zusammenführen.

Ich habe einen Schlag auf so etwas gemacht ... als Plugin veröffentlicht:

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

Bitte keine Plugins mehr, die die Leute davon abhängig machen. Lass den verdammten Block einfach schon los.

@weddados Ich

Um die Arbeit von niemandem zu schmälern, aber wir brauchen dies wirklich, um auf einer bestimmten Ebene eingebaut zu werden.

Besonders in einer Welt, in der es dieses Problem gibt .

Sollte eine adäquate Lösung für # 13391 gefunden werden, wäre das Vorhandensein unzähliger Containerblock-Implementierungen wahrscheinlich in Ordnung.

Bis der neue Block Builder Risse mit einer Standardgrundlage für Layoutelemente (Container, Abschnitte, Zeilenspalten) hat, die Plugins von Drittanbietern erweitern können, ist er umsonst und verewigt das Durcheinander beim Ein- und Ausschalten von Blöcken, Themen und Buildern von Drittanbietern ( diejenigen, die versuchen, das Layoutproblem zu lösen) und am Ende Inhalt und Seitenlayout verlieren.

Wann können wir diese Funktion erwarten?

Sollte bereits in der neuesten Version sein:
https://github.com/WordPress/gutenberg/releases/tag/v5.5.0

@ksere : Das habe ich wahrscheinlich verpasst, weil das Changelog für v5.5.0 des Plugins leer ist .

Ich habe die Implementierung bisher wirklich ausgegraben. Ich verstehe, dass es gerade in 5.5 veröffentlicht wurde, aber ich frage mich, wann wir möglicherweise Ergänzungen für Hintergrundbilder (und deren Positionierung), Hintergrundfarbenopazität usw. erwarten. Ist dies etwas, das wir vor Ende 2019 erwarten sollten, oder sprechen wir länger -term als das?

@nathansnelgrove Danke für das Feedback. Es gibt definitiv einige Verbesserungen im Gruppenblock, hier sind zwei bereits in Arbeit:

• Hinzufügen eines inneren Containers zur Vereinfachung des Stylings - https://github.com/WordPress/gutenberg/pull/15210
• Hinzufügen von Editoroptionen zum Gruppieren / Aufheben der Gruppierung einer Auswahl von Blöcken - https://github.com/WordPress/gutenberg/pull/14908

Ich habe die von Ihnen erwähnten Probleme mit Hintergrundbildern und Deckkraft, die irgendwo verfolgt werden, nicht gesehen. Es könnte sich lohnen, ein separates Problem dafür zu erstellen, wenn Sie Zeit haben, da dieses Problem jetzt geschlossen ist.

Hintergrundbilder / Farben / Deckkraft stammen aus dem ursprünglichen Vorschlag - ich werde ein neues Problem für sie erstellen.

Ich habe gerade WordPress 5.2.4 installiert und kann keinen Block "Abschnitt" oder "Gruppe" finden. Was ist hier los?

@patrikhuber : Dies wird in WordPress 5.3 enthalten sein, das derzeit am 12. November veröffentlicht werden soll.

@noisysocks Ich